March 6, 2011

Tron Update: Engineering Journal

This is a multi-robot communication project, inspired by the Sci-fi movie Tron and the online Java game BM-Tron. The project will incorporate the Light-Cycle Battle game from the movie, which is similar in concept to Cat and Mouse.
Check out the following links for videos on the Light Cycle Battle from the movie:
For our initial project, one robot will be programmed while the other robot will be remote controlled by a user (perhaps by using a Playstation3 Bluetooth controller).

In theme with the movie, I will refer to the remote controlled robot as the “User” and the programmed robot as the “Program” (:
For our hardware, we are using Lego's Mindstorms NXTs and Dexter Industries NXT Xbee radios, both of which will be programmed using the ROBOTC programming language.
My Initial Thoughts
Below are problems I found with the online Java game, BM-Tron, which is based on the LightCycle battle from the movie:
Above all, the Programs from the game only mimic intelligence. For example, in the game the moves of the programs are random, which is caused by the program not recognizing the difference between its own trail and that of the users. This can be seen when the program (rather stupidly) traps itself
Check it out for yourself, to see what I mean at
The “Grid”
The environment I envision (at least for this initial project) is a White-board where each "Cycle" is equipped with a dry erase marker to mark where they are and where they have been. Additionally, I was thinking I could have a couple of White-board eraser robots that clean up the markings at the end of each round :D
Sensors and Communication
Mike Ornstein from Carnegie Mellon's Robotics Club advised me to have a high quality sensor (a camera and computer) because the way people often go about determining where robots are relative to each other (especially indoors where GPS does not work) is to use an overhead camera and little beacons on each robot for ID purposes. Thus, having an overhead camera would be ideal also because it could read the drawn lines as well, which would also make the autonomous erasers more efficient at detecting and erasing the trail markings the Cycles make.
Start the following video at 11:00 minutes to see what Mike was talking about:
Carnegie Mellon’s Multi-Robot Lab and CORAL researchers did something quite similar with their robot soccer project:
For the communication between robots, we are using Dexter Industries amazing NXTBee radios. And for detecting the speed and direction of both robots, I believe I will need additional sensors. Two of them being the High Technic Accelerometer and the High Technic Compass, which together will track the speed and direction of each robot.
Below are diagrams illustrating the communication between the robots and the sensors:
Communication for the User consist of a remote control, which is wirelessly connected to the robot, illustrated below:
Remote Control—>Robot
On the other hand, communication for the Program begins with a camera system whose images are sent to the computer, which are then relayed wirelessly to the, robot, illustrated below:
Camera—> Computer—>Robot
Sensor Inputs and Behavior Outputs
· User’s Velocity (i.e. Speed and Direction)
· Program’s Velocity
· Trail of the “User” (i.e. Previously traveled areas and marked lines)
· Trail of the “Program”
· Board boundaries
· Continue forward (Go Straight)
· Left (-90˚ Point turn)
· Right (90˚ Point turn
After the project is completed and the fun is had, I plan to apply the technologies and concepts learned the future of autonomous driving. Specifically, autonomous driving and high speed traveling with auto motives, where a grid system and communication networks between vehicles will be imperative, and will be used to reduce traffic while increasing the travelling speed of the vehicles!
More Project TRON: Posts | Pictures |  


dimastero said...

are we talking NXT here, or something else?

Smalls said...

Yes, for our hardware, we are using Lego's Mindstorms NXTs and Dexter Industries NXT Xbee radios, both of which will be programmed using the ROBOTC programming language.

dimastero said...

cool! robotc is great

Mike Ornstein said...

Hey Eric,

Looking good, start prototyping!

I think you will find that the inclusion of accelerometers and magnetometers (compasses) will not give you additional information on top of the data that can be provided by the camera. It is possible to extract both velocity and orientation of the 'bots given a good ID for the camera to pick up. You'll notice how there are 5 colored dots on top of the CMU soccer bots... those dots indicate orientation, position and identity.

If you know position over time you will also know velocity (and acceleration) making an accelerometer on board each bot potentially unnecessary. The only reason I can think an accelerometer (or wheel encoders) might be useful is if there is a significant lag-time in processing and relaying commands wirelessly to the bots.