|
|
# **Lab Notebook 9**
|
|
|
|
|
|
**Date:** 12th and 13th of May 2016
|
|
|
|
|
|
**Group number:** Group 14
|
|
|
|
|
|
**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
|
|
|
|
|
|
## **Goal**
|
|
|
|
|
|
Our goal is to get experience with behavior based programming and use this knowledge to make a sumo wrestling robot that drives all others off the track and wins the tournament.
|
|
|
|
|
|
## **Plan**
|
|
|
|
|
|
Start by reading the leJOS tutorial on behavior programming [1].
|
|
|
Other than that we plan to follow the [9th lesson plan](http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson9.dir/Lesson.html) and start by implementing a BumperCar followed by a sumo wrestling car.
|
|
|
|
|
|
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’.
|
|
|
|
|
|
## **Results**
|
|
|
|
|
|
Robot was rebuild as base car + bumper + ultrasonic sensor
|
|
|
|
|
|
### Intro
|
|
|
|
|
|
The implementations for the Bumper Car exercises and for the exercises on motivation functions can be found in BumperCar.java and MotivatedBumperCar.java, respectively. For the sumo wrestling exercise we have added behaviors to MotivatedBumperCar.java.
|
|
|
|
|
|
### Preliminary exercises
|
|
|
|
|
|
#### BumperCar
|
|
|
|
|
|
##### Arbiter investigation
|
|
|
|
|
|
Press the touch sensor and keep it pressed. What happends ? Explain.
|
|
|
|
|
|
It drives backwards a bit and turns left (backs up the right wheel) to get clear of the obstacle
|
|
|
|
|
|
This happens as soon as we press the touch sensor -> the arbiter changes behaviors emidiately (properbly calls supress method of basic drive farward behavior)
|
|
|
|
|
|
Note: Only 1 touch sensor is implemented in code
|
|
|
|
|
|
Implement a third behavior, Exit. Is the Exit behavior activated immediately when pressed during other behaviors?
|
|
|
|
|
|
We did exit, created new class Exit, implementing behavior
|
|
|
|
|
|
[Insert code example]
|
|
|
|
|
|
We didn’t implement suppress, because it should never be suppressed. We also put its suppress trigger into DetectWall, as it should be able to suppress all other behaviors
|
|
|
|
|
|
The action() method of DetectWall was changed to accommodate immediate return when suppressed. This seems correct, as the higher priority is exit and therefore it is not desired that the robot ends its backwards turn, but that it stops immediately.
|
|
|
|
|
|
DetectWall.action() will abort as this method is constantly called again when bumper is pressed and will terminate after only two short statements if it is suppressed.
|
|
|
|
|
|
After implementing Exit, the DetectWall behavior behaved strangely. It would only drive backwards when the bumper was pressed continuously, and would immediately return to driving forward when releasing the bumper, as opposed to finishing a backwards turn.
|
|
|
|
|
|
We fixed this by locking the backwards turn in a loop that breaks only when the turn is done, or when the behavior has been suppressed. This way, the drive is not interrupted by DriveForward, but will still be stopped if a higher priority behavior, like Exit, is triggered.
|
|
|
|
|
|
Is takeControl of DriveForward called when the triggering condition of DetectWall is true?
|
|
|
|
|
|
It is not, as the Arbiter has a separate thread, that runs backwards through the given list of behaviors and breaks if one behavior want controls. Thereby the DriveForward.takecontrol() will not be called when the DetectWall.takecontrol() returns true;
|
|
|
|
|
|
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!!!)
|
|
|
|
|
|
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
|
|
|
|
|
|
DetectWall interrupting when touch sensor pressed during turn
|
|
|
|
|
|
We tried a solution where our blocking while loop [Insert !supressed code] also checks whether the touch sensor is pressed, and in that case, breaks. This implementation relies on the Arbitrator happening to call takeControl after the loop breaks, and before the touch sensor is no longer pressed.
|
|
|
|
|
|
Using beep sound to know when the ation method of DetectWall has been called, so that we can check that our implementation works as intended.
|
|
|
|
|
|
It doesn’t work D:
|
|
|
|
|
|
[TODO: Emil talk about potential thread solution]
|
|
|
|
|
|
#### Motivation functions
|
|
|
|
|
|
Split the work - Camilla & Ida on motivation functions, Nicolai and Emil on sumo
|
|
|
|
|
|
If the touch sensor is pressed again while the robot is turning, it should reactivate its action() method, i.e. start over on its evasive behavior.
|
|
|
|
|
|
overvejelser:
|
|
|
|
|
|
* difference from priorities to motivation: we can incorporate state (e.g. "performing evasive turn") into mapping function
|
|
|
|
|
|
* how to be able to stop action and start over: run action in separate thread and wait for it to return, unless…?
|
|
|
|
|
|
* issue: we can’t interrupt an ongoing action
|
|
|
|
|
|
do:
|
|
|
|
|
|
* make interface Bheavior of our own ("first")
|
|
|
|
|
|
* motivation as "percentage" (0 to 100) (noted in Behavior, as part of “first”)
|
|
|
|
|
|
In Arbitrator ("second"):
|
|
|
|
|
|
We loop from the highest priority behavior and check if its motivation (currentMovation) is greater than the one currently registered as highest (highestMotivation). If yes, we update the value of highestMotivation and set the highestMotivated variable to the behavior currently being checked. Since we begin from the behavior with the highest priority and only update it if the value currently being checked is greater (not equal), we are also ensured that ties between behaviors are resolved so that the highest prioritized wins.
|
|
|
|
|
|
"Third":
|
|
|
|
|
|
Class names are prefixed with "motivated"
|
|
|
|
|
|
DetectWall:
|
|
|
|
|
|
* for ultrasonic sensor: map from 0-255 range to 0-100 range - distance 255 corresponds to 0 motivation, distance 0 corresponds to 100 motivation (we will never get here as the bumper is further in front - might consider making 100 motivation correspond to the distance from the bumper end to the ultrasonic sensor end)
|
|
|
|
|
|
overvejelser:
|
|
|
|
|
|
* move mapping calculations to separate class (like old Update class)
|
|
|
|
|
|
→ DONE (SensorContact)
|
|
|
|
|
|
* active-variable is set if evasive action is in progress
|
|
|
|
|
|
* if active is set and motivation is less than 50 |new touch is registered|, set motivation to 50. The variable active makes sure that if the sensor is still pressed, the likelihood that the evasive behavior is overruled is less than if it was not still pressed (understood by looking at Ole’s implementation).
|
|
|
|
|
|
NOTE: Because the other half of the group was still working on the robot (rebuilding and testing tiny code things), we did not test the things implemented in the exercises on motivation. We expect to use them in the sumo robot though, so it will be tested there.
|
|
|
|
|
|
TODO: Discuss choices of motivation values
|
|
|
|
|
|
### Sumo wrestler
|
|
|
|
|
|
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
|
|
|
|
|
|
Nicolai’s additional idea (with regards from Ida): try to flip robot in front; but if we register that we accidentally lifted the other robot, we will instead try to drive it to the edge
|
|
|
|
|
|
Side/rear guards - Big plates mounted to the side near the floor, to guard against opposing forklifts from sides or rear.
|
|
|
|
|
|
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!
|
|
|
|
|
|
* implement remaining behavior (NB: Perhaps lowest behavior should not be a simple cruise behavior, but a waiting behavior, or a more sophisticated cruise behavior - going straight doesn’t seem to be the most clever choice)
|
|
|
|
|
|
COULD BE NICE:
|
|
|
|
|
|
* use bumper to sense if being pushed from behind; could then react by either pushing back or evading, perhaps depending on how close to edge (theoretical note: would make use of the ability to include additional behaviors)
|
|
|
|
|
|
* implement alternative Eye of The Tiger kamikaze bot
|
|
|
|
|
|
## **Conclusion**
|
|
|
|
|
|
## **References**
|
|
|
|
|
|
[1] [LeJOS tutorual on behavior programming ](http://www.lejos.org/nxt/nxj/tutorial/Behaviors/BehaviorProgramming.htm)
|
|
|
|
|
|
TODO: ref. til Krink og måske til lecture slides med diagram?
|
|
|
|
|
|
[TODO-nummer] [BumperCar.java]([https://gitlab.au.dk/LEGO/lego-kode/blob/master/src/Lesson9programs/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 |