Behaviour-Based Wall Follower in NXT-G
I’ve made a 45-minute-long tutorial video showing how to program a MINDSTORMS NXT Robot in a basic behaviour-based way — a great way to start with a simple robot program and work up to a complex-yet-still-manageable one. The video shows the concepts behind behaviour-based programming, and, in a step-by-step fashion, how to program the robot to do this in NXT-G, what the robot does, and how to debug the code to make the robot exhibit the desired behaviour.
Here are a couple of diagrams from the video:
We will indue Exo-Scout (the robot) with behaviours to drive forward, hug the wall, avoid the wall, and to escape when he crashes into something. It sounds contradictory, but it all works out.
Conceptually, the behaviours are organized into triggers, actions, and something called an arbiter. It sounds scary and looks daunting, but the video explains it all so you can use it in your own robots.
Download
Here are the following choices for downloading the video. Depending upon your web browser, you may be able to click on an option and stream it, or you may want to right-click on the file and save it.
| Format | Large (820×614) | Medium (512×384) |
|---|---|---|
| Quicktime | [312 MB] | [123 MB] |
| Ogg Theora | [325 MB] | [208 MB] |
(If you aren’t sure which video format to choose, you probably want to go with the Quicktime video.)
The NXT-G source code demonstrated in the video can be downloaded here. Note that you’ll need the NXT-G 2.0 software to use them.
Share and Remix
Behaviour-Based Wall Follower in NXT-G by Clinton Blackmore is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Canada License.
Leave Some Feedback
I’d love to know what you think. I believe the video explains some powerful principles that will help breath life into robots! Feel free to add a comment or send me an email.
Article History
2010-04-06 — Reworked a lot of the text, added pictures, added the CC license to the videos, and encoded and uploaded videos in ogg theora format.
2010-03-15 — I have placed the work under a creative commons license, granting you rights to redistribute, re-mix, translate, and adjust the work, so long as you give me credit for originally creating the work. (See above for details.)
2010-03-05 — Added a lower-quality version of the video, and added a .zip file containing the source files I worked on.
Happy March Friday, Clinton!
What an excellent “how to” video! I’d very much like to show this video to my FLL and FTC students. Your clear, concise descriptions, clean graphics, and excellent view of your coding process make this an easy to follow presentation of a complex, multi-process program. I’ve attempted for years to get my students past the linear “spaghetti” code you mentioned. Please let me know if it’s okay to use in my lab. I work in a school in Edmonds, Washington and support students in a hands-on lab. I’m happy to share the results and responses from students!~cw
— Cathy Webb · Mar 12, 02:33 PM · #
Cathy,
Please, go right ahead and make use of the video. That’s what I made it for. Indeed, I’ll probably put it under a creative commons license.
I hope your students find it to be useful.
Clinton
— Clinton Blackmore · Mar 12, 08:02 PM · #
Hi Clinton
Thank you soooo much for this video. It’s easy to understand and also educates the students along the way on how to use the interface effectively. It has helped me to understand how to use the variable blocks and data wires in a short space of time (vital for a busy teacher). Reading above I am going to let my small robotics club students watch and construct this next week. I’ll let you know how they get on. Love the robot too.
— Debra Wood · Apr 22, 06:12 PM · #
Debra,
Glad to hear it! Wish your young roboticists the best of luck!
Clinton
— Clinton Blackmore · Apr 22, 06:32 PM · #
Hello Clinton,
Thank you very much for creating this tutorial for NXT-G applications! It is amazing that I saw this on a very understandable and easy to follow tutorial.
May I have a few questions for it too?
- Does the arbiter loop always execute the selected state every iteration?
- What is an efficient way to make the other triggers to be queued when a behavior is still executing? (I think this applicable on, lets say an elevator where in I press the floors and then it would queue up the other actions first). Or is there a different approach (not behavior based) for this type of application?
Kind Regards,
Wendell
— Wendell · Jun 6, 08:44 PM · #
Wendell,
I’m glad you like the video.
I’m not entirely sure I understand your first question, but perhaps this will answer it:
You can write behaviour actions in two ways:
1. The behaviour is short and happens repeatedly. [This is how most of the behaviours in the wall-follower work. For example, as long as the robot finds that it is too close to the wall (and no higher-priority behaviour is in effect), it will run a short little command to steer away from the wall. It will likely go through this cycle dozens of times before it is done and away from the wall.]
2. The behaviour is long, and, when finished, the initial triggering condition is gone. [This is how the ‘Escape’ behaviour works. When the robot hits the wall, it triggers a series of events that last for a few seconds — it backs up and turns, and, when done, it is no longer hitting the wall. The behaviour action only happens once for every time the bumper is hit.]
One way you can queue up behaviours is to use a latch — or something that retains its state. Let us say that, when a button is pressed, you want the robot to do an action based on that whenever it is done doing things that are a higher priority. Instead of using a trigger that says (and, forgive me, NXT-G does not express itself well in text), “check if the button is pressed and store the value in button_action” use a trigger that says, “if the button is pressed, set button_action to true”. The first can only execute while the button is being depressed. The second will remember the button press until the corresponding action occurs — but you must ensure that when the behaviour action occurs, it sets button_action back to false.
I tried this technique and found that sometimes it will execute your action when it is no longer desirable to do so. (I think I did it for the “close to the wall” trigger/action. Whenever the robot went to escape, it would become close to the wall. The value would become latched. After the escape behaviour was done, even if it was far away from the wall now, it remembered that it had been close and initiated the behaviour to steer away from the wall.)
— Clinton Blackmore · Jun 7, 07:59 AM · #
Hello Clinton,
Thanks for the recommendation you have given! I have applied them however I ended up in making a variable to detect if there is an action still performing and try not to trigger another action until after the arbiter is free. In my example, I have inputs 1 and 2 as buttons and B and C as motors. When 1 is bumped then it will run motor B slowly for 5 seconds, and same for input 2 that will run motor C for 5 seconds also. What happened was when input 1 was bumped then motor B will run but while it is doing so, even if input 2 is bumped motor C will not run. until after motor B will motor C run but it will require that input 2 is bumped again. I think I have made the arbiter to execute exclusively only 1 action and ignore all others. My is that did this defeat behavior based programming and in turn became a different concept altogether?
Regards,
Wendell
— Wendell · Jun 8, 12:20 AM · #
If I’m understanding you right, you want motor B to go when button 1 is pressed, and motor C to go when button 2 is pressed (regardless of what motor B is doing).
If that is all the program does, you can have two parallel sequences beams, and each beam looks something like this:
“loop { wait until button is pressed ; run the motor }”
If you do want a behaviour-based approach, consider using an arbiter for each independent output of the system. The robot in my video uses one arbiter to control one output — the whole robot. It is possible to use either one more complicated arbiter, or a series of simpler arbiters, that control outputs for different systems. One could control the output for Motor B. Another could control what happens to Motor C. A third could control what is displayed on screen, and a fourth could control what sounds are emitted. All can make use of the same triggers, but act on them differently.
Behaviour-based control is not always the appropriate answer. It works best when you want to add complexity by taking a base behaviour and adding additional behaviours to it.
— Clinton Blackmore · Jun 8, 06:40 AM · #
Now I get it! I can do with multiple arbiters too! Thanks for the amazing information you have provided Clinton, it would be a lot of help when I would be doing my projects. I see that the behavior based control is applicable on some stuff only but it would be an easier way to tackle on a robot that deals with a lot of sensors.
— Wendell · Jun 9, 01:17 AM · #
Glad to hear you’ve got the vision. Good luck, Wendell.
— Clinton · Jun 9, 06:49 AM · #