Mobile Robot Simulation
Due: XXX Hours, XXXX 2000

Each team is to write a mobile robot simulation and demonstrate it for the class on the due date.

Your choice of programming language is up to you, but we seriously recommend learning and using Matlab.

There should be Matlab manuals in the UG laboratory, and there are lots of books on the market.

If you want to use any other language or platform that's fine too, as long as you have a graphic display of the results.

Simulations always involve assumptions about the level at which you are simulating. For this assignment I'd like you to explore two levels. First, the logical level where the physical situation is simplified and idealized. Second, a closer look at the physical level without any complex logic. Ironically (get used to it in robotics), high-level, conceptual, "intelligent" aspects are much easier to simulate than the low-level physical aspects.

First you should implement a multi-behavior robot with multiple sensors. Here the physical level is simplified. The code pointed to above provides an adequate model of the physics: the robot acts like a point that moves in a given direction at a velocity given by its power setting. In the given code, the robot reacts to its sensors in reasonable ways. Your first simulation allows you to build more complex logic to control such a robot and to endow it with more interesting and complex sensors.

The instincts or behaviors mentioned below can obviously interact in more or less interesting ways. The "subsumption architecture" is designed to keep the interactions under control. You would be wise to use a subsumption architecture (cf. p. 8 and Ch. 9 of Jones and Flynn, early parts of Chapter 6 in Dudek and Jenkin, and the papers by Brooks to be provided I hope.)

You should have at least four behaviours. Ones that come to mind are the following, but in this world you're God and can give your robots all sorts of capabilities, like teleporting, seeing into the future, color and range vision, automagic friend or foe identification, whatever.

You can make up sensors you need: they don't need to be ``realistic''. For instance, you can sense the absolute location of prey or predators through obstacles, you can know your own location absolutely. More realistic is relative sensing, in which you might know direction and distance but don't know (x,y) locations.

You could model a static subsumption architecture with fixed priorities or you could have varying priorities: e.g. your hunger or sex drive could lead you to take chances with predators, etc.

Tip from the top: start simple and add things incrementally, or you'll never be able to debug your simulation or have any confidence that it is working correctly.

Word to the wise: save time for Part Two (see below)!

Next, I'd like to see a simulation of Tutebot: The goal is to predict as accurately as possible how the Tutebot control algorithm will work and how your physical robot will respond. For this you need to do two things.

  1. Simulate the controller.
  2. Simulate the physics.

For the controller, you actually could simulate the circuit! That would be sort of cool and I'd love to see would involve you in some sort of implementation of differential equation solutions, but that is actually pretty easy to do approximately. It's going on in a disguised way in the sample code where it says:

pos = pos + power*[cos(theta);sin(theta)];

However I recommend you not do that (at least initially); you could start with the behavior as it's explained in Jones and Flynn. As I recall it goes something like this: go forward until you hit something. If you hit something, reverse, turning as you do so, for a short time and then go forward again. (Check this but it's something like that). The point here is to get the time constants and other details correct so you can correctly simulate your actual circuit. Thus leave some parameters to set (for delay times, etc.) and produce output to be interpreted by the physics layer.

The main physics is simply simulating differential drive on a two-wheeled robot. This is taken up in Dudek and Jenkin, around page 17 through 21. Don't let the notation scare you, it's pretty simple but it is more complex than the "moving point" assumption in part I above. Basically you have to figure out where you go if you drive two wheels at different angular velocities. You can do everything from going forward (same velocity) to turning in place (opposite velocities), or some other circular path (different forward velocities). What happens depends on your wheel (or track?) configuration (distance apart, wheelbase if you have other wheels, etc. It's simple-minded geometry (and you shouldn't need Dudek and Jenkin to figure it out) but the point is to be able to get it as right as possible. Thus again you should have "configuration" variables you can configure to describe the physical robot you build. Note that the given code does not simulate differential drive: there are some sines and cosines in there but they are computing the position of the robot's corners (for collision calculation purposes).

Other nasty things you may want to anticipate: because of friction or other mechanical variation, one wheel often does not turn at the same velocity even when commanded to do so. Or because of physical construction your robot veers when it's commanded to go straight. Thus you may want some sort of tuning to account for these predictable errors.

Provide a brief write-up of your work, including the justification for your design decisions and observations about the behavior of your robots. For instance, it's quite possible to write controllers that get you stuck in a loop, stuck bashing an obstacle, or even get you consistently killed. If you can prove that your controller doesn't get you in these sorts of troubles that'd be wonderful.

When you build your Tutebot, you should go back and see how closely you can get your simulator to predict the behavior of your physical robot.

290 Home Page

This page is maintained by Nature Lover

Last update: 21.6.00.