... | ... | @@ -6,7 +6,7 @@ |
|
|
|
|
|
**Group members participating:** Camilla M. V. Frederiksen, Ida Larsen-Ledet, Nicolai Nibe and Emil Platz
|
|
|
|
|
|
**Activity duration:** 8.5 hours on Thursday the 12th of May, [TODO: fra kl. 9] hours on Friday the 13th of May
|
|
|
**Activity duration:** 8.5 hours on Thursday the 12th of May, 6 hours on Friday the 13th of May
|
|
|
|
|
|
## **Goal**
|
|
|
|
... | ... | @@ -19,7 +19,9 @@ Other than that we plan to follow the [9th lesson plan](http://legolab.cs.au.dk/ |
|
|
|
|
|
As this week’s lesson plan looks pretty structured, we plan to have fairly specific roles. [TODO indsæt roller]
|
|
|
|
|
|
May 12: Camilla a’ codin’, Nicola ‘a notin’.
|
|
|
May 12: Camilla a’ codin’, Nicola ‘a notin’. Hvad lavede Ida og Emil?
|
|
|
|
|
|
May 13: Nicolai bygger og re-inforcer, Nicolai og Ida programmerer og eksperimenterer sammen, Ida tager noter, Emil programmerer og eksperimenterer (og tager vist også noter)
|
|
|
|
|
|
## **Results**
|
|
|
|
... | ... | @@ -67,6 +69,10 @@ Make variable with updating thread for ultrasonic sensor |
|
|
|
|
|
We made a local thread which constantly updates the ultrasonicsensor variable and stores it in a variable. The DetectWall then asks the thread for the newest variable in its takeControl() (of BODY AND SOUL!!!)
|
|
|
|
|
|
NB: Der står "To avoid the pause in the takeControl method of DetectWall **a local thread in DetectWall** could be implemented that sample the ultrasonic sensor e.g. every 20 msec and stores the result in a variable distance accessible to takeControl."
|
|
|
|
|
|
… men vi har lavet en klasse, der gør det. Det skal enten ændres eller bemærkes og begrundes i rapporten.
|
|
|
|
|
|
DetectWall moving backwwards 1 second before turning
|
|
|
|
|
|
We changed the rotations of 180/360 degrees of the two wheels using tacho counter to instead drive backwards for 1 second with a while loop using system.currenttimemilis
|
... | ... | @@ -81,6 +87,10 @@ It doesn’t work D: |
|
|
|
|
|
[TODO: Emil talk about potential thread solution]
|
|
|
|
|
|
NOTES til det:
|
|
|
|
|
|
Tried putting all the ultrasounds sensor functionality in a thread shared by the PursuitEnemy behavior and the FlipEnemy behavior, where they both call getDistance. Initially it was meant for only the FlipEnemy behavior where it should sample distances over a set time (eg. 1 second) and then take the minimal distance in the array, but this didn’t work. When it was extracted from FlipEnemy it seemed obvious to give it to PursuitEnemy, but this behavior didn’t need the sampling. This wouldn’t be too bad though, since that behavior doesn’t need to look for an enemy more than a few times every second. We never got to the point where the sampling worked, but we made a solution that continuously ran over 50 elements in an FIFO array and took the minimal distance. The ultrasound sensor has a downtime of around 15-20 ms for every ping and 50 elements would [TODO Nicolai and Ida didnt consider the downtime, and called Thread.sleep(20) as another sampling time - to investigate: What happens if you call a method on a sleeping thread? The thread that calls the method aren’t sleeping, so it can process the method even if the runnable is sleeping?] be taking the minimum of the distances the last 1 second. This would make it lift the fork more than once at a sighting of an enemy (which is still a problem since we need to lift our enemy and keep it high and not raise it further (or what??)).
|
|
|
|
|
|
#### Motivation functions
|
|
|
|
|
|
Split the work - Camilla & Ida on motivation functions, Nicolai and Emil on sumo
|
... | ... | @@ -129,6 +139,10 @@ TODO: Discuss choices of motivation values |
|
|
|
|
|
### Sumo wrestler
|
|
|
|
|
|
TODO: (kort) intro
|
|
|
|
|
|
#### Construction
|
|
|
|
|
|
We thought of several ideas to enhance our sumo bot.
|
|
|
|
|
|
Forklift - Vertical third motor attached with a forklift, that combined with the ultrasonic or touch sensor can lift the other robot when we detect they are in front of us
|
... | ... | @@ -137,12 +151,16 @@ Nicolai’s additional idea (with regards from Ida): try to flip robot in front; |
|
|
|
|
|
Side/rear guards - Big plates mounted to the side near the floor, to guard against opposing forklifts from sides or rear.
|
|
|
|
|
|
We considered using the third motor for a third motorized back wheel, to give us more pushing power, but we figured this would be against the rules as the robot had to be based on the Express bot.
|
|
|
|
|
|
![sumo build](https://gitlab.au.dk/LEGO/lego-kode/raw/master/week12/img/build.PNG)
|
|
|
|
|
|
*Figure TODO: The robot rebuilt with a third motor for a fork and with side and rear guards to protect from being swept up by other robots*
|
|
|
|
|
|
TODO fredag:
|
|
|
|
|
|
* make robot work as it is when we leave on Thursday:
|
|
|
|
|
|
* REMEMBER: import sensors in top and check that ports are correct (Camilla)
|
|
|
|
|
|
* test durability of side/rear guards
|
|
|
|
|
|
* test ability to stay within lines; make difficult tests!
|
... | ... | @@ -155,16 +173,95 @@ COULD BE NICE: |
|
|
|
|
|
* implement alternative Eye of The Tiger kamikaze bot
|
|
|
|
|
|
#### Implementation
|
|
|
|
|
|
Done:
|
|
|
|
|
|
* implemented AvoidEdge behavior (motivation 100 on detection of edge)
|
|
|
|
|
|
* our own arbitrator and motivatedcar do not work - we use Ole’s and see if we have time to figure out what’s wrong with our own implementation later
|
|
|
|
|
|
* robot turns too much (values -360 for one wheel, -1300 for other wheel); sometimes drives backwards off edge
|
|
|
|
|
|
* → implementation that turns on the spot. Works OK. Will optimize later if desired.
|
|
|
|
|
|
* Next: Implement detection of other robot and go to it. After that: Implement detection of other robot and try to flip it.
|
|
|
|
|
|
* On detection and following of other robot:
|
|
|
|
|
|
* How to test? Make robot go faster if it sees an enemy - that way we can tell that it has detected its enemy. Implement behavior Drive that only drives with speed 60 - makes it very obvious when the robot switches to PursueEnemy (where we set speed to 400)
|
|
|
|
|
|
* Don’t try to make it follow the enemy - simply go faster straight ahead if enemy is within vision
|
|
|
|
|
|
* Overvejelse: We let avoiding the edge outweigh enemy detection, as crossing of the edge leads to losing the match with much higher certainty than not pursuing an enemy. Perhaps we should even stop for a second when losing track of the enemy, so as to minimize the risk of being lured to the edge (or would stopping make us more vulnerable to attacks?).
|
|
|
|
|
|
* Using distance 30 cm for detection; have not tested other distances
|
|
|
|
|
|
* On detection and flipping other robot
|
|
|
|
|
|
* Change base speed to 200
|
|
|
|
|
|
* Use tacho counter to make sure that we don’t flip forklift "all over the place" like when Frej was almost strangled in a previous lesson
|
|
|
|
|
|
* Make test program for testing flip: FlipTest
|
|
|
|
|
|
* NB: Robot must not begin to chase because it is seeing its own forklift (should not happen, as pursue has lower priority)
|
|
|
|
|
|
* First test: -30 rotation on flip motor (motorport A, FlipMotor). Looks okay.
|
|
|
|
|
|
* Note: Use of motivation functions would be nice: Could lower motivation for flipping after a flip has been performed, such that the robot would rather push the other robot by running into it again
|
|
|
|
|
|
* Implement so that on suppress or loss of sight of enemy makes the forklift go back down
|
|
|
|
|
|
* Sometimes robot sees (bogus?) far distances even if something is very close in front of it → forklift flips out [VIDEO]
|
|
|
|
|
|
* → make update thread to keep track of distance over a timeslice
|
|
|
DIT NOT WORK OUT!
|
|
|
|
|
|
* Note: Can FlipEnemy be suppressed in between setting ForkLifted to true and flipping the fork? What happens then?
|
|
|
|
|
|
TODO: Video fra Nicolai (fucked up fork reactions)
|
|
|
|
|
|
#### Further ideas
|
|
|
|
|
|
IDEAS
|
|
|
|
|
|
* If registrering push (i.e. if using touch sensors) while reading white, back fast away from white.
|
|
|
|
|
|
* Incorporate random movement in drive (perhaps by using motivational functions and having a turn behavior that randomly gets high motivation) so that we don’t go so much towards the edge
|
|
|
|
|
|
* Implement search for enemy
|
|
|
|
|
|
Note: The strategy that we initially discussed was to make a purely defensive robot (with two bumpers), which would perhaps push aggressively back if it registered running into something.
|
|
|
|
|
|
Note (regarding sepearate thread for vision): if sampling over an entire second, we would get a perhaps undersirable delay (shorter sampling timeslices would help with this)
|
|
|
|
|
|
#### Insights from the sumo tournaments
|
|
|
|
|
|
Note: From the tournament, we saw that it might be useful to include a "this is taking too long"-behavior that changes strategy to avoid a draw (on the other hand, we would need to make sure not to risk
|
|
|
|
|
|
Note: Our forklift didn’t work as intended, but helped to disrupt the driving of the others + it also helped by getting stuck in the floor, enabling the robot to stand firm in pushing battles
|
|
|
|
|
|
TODO: Videoer fra Nicolai (kampe)
|
|
|
|
|
|
## **Conclusion**
|
|
|
|
|
|
TODO:
|
|
|
|
|
|
* hvad fik vi ud af de indledende øvelser?
|
|
|
|
|
|
* konklusion på sumoarbejdet
|
|
|
|
|
|
* indsigter fra sumoturnering
|
|
|
|
|
|
## **References**
|
|
|
|
|
|
[1] [LeJOS tutorual on behavior programming ](http://www.lejos.org/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm)
|
|
|
|
|
|
TODO: Skal vi have en ref. til kilde [2] i lesson plan?
|
|
|
|
|
|
[2] Thiemo Krink(in prep.), [Motivation Networks - A Biological Model for Autonomous Agent Control](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson9.dir/Krink.pdf)
|
|
|
|
|
|
NB! Lav ikke nedenstående om til links - det fucker op!
|
|
|
|
|
|
[TODO-nummer] [BumperCar.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson9programs/BumperCar.java) containing classes for the Bumper Car exercises
|
|
|
|
|
|
[TODO-nummer] MotivatedBumperCar.java](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson9programs/MotivatedBumperCar.java) containing classes for the sumo exercise, and for the exercises on motivational functions
|
... | ... | @@ -173,5 +270,3 @@ TODO: Skal vi have en ref. til kilde [2] i lesson plan? |
|
|
|
|
|
[TODO-nummer] Our implementation of the [Behavior](https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson9programs/Behavior.java) interface, using motivational functions
|
|
|
|
|
|
NB! Lav ikke ovenstående om til Links - det fucker op!
|
|
|
|