My Propeller-based robot won!
acantostega
Posts: 105
1st place! I'm a computer engineering student at the Pontificia Universidad Catolica de Chile (PUC), which has just finished hosting the IEEE Latin American RoboCup (LARC). Me and a friend, a mechanical engineering student participated in a category called "Cowbots". As described in the competition website, www.robopuc.cl/larc:
[noparse][[/noparse]quote]
Cowbots duel: Involves custom-built (free-style) cowbots (COWboy-roBOTS) that must fight a duel between them, using a revolver and a melee weapon. Like in the free category, the robots must be fully autonomous (i.e. no external processing is allowed).
As far as I know, it's a local invention. It's pretty exciting. The robots must find their opponent, possibly using some sort of beacon (the most popular choice is an infrared emitting beacon, although a couple of robots using color vision have participated), and fire ping pong balls at it. The first bot to get hit by a ping pong ball loses.
While I was planning how to build the bot, I read about the Propeller chip and knew right away it was just what I needed. Having used other MCUs like PICs and AVRs, I found it pretty hard to combine all the I/O and AI processing in just one chip while keeping the response time of the 'bot low. I also wanted to avoid multi-chip solutions since I wouldn't to keep the complexity of the electronics as low as possible.
The bot's program was written in Spin and loosely inspired in Brooks' Subsumption architecture. I used 3 cogs to execute independent behaviors in a parallel fashion: Escape, Navigate, and Hunt. These behaviors did most of their own sensory processing (e.g., the "escape" behavior polled/debounced the whiskers to detect if they were pressed), save for a couple of more cpu-intensive sensory tasks, like analyzing the frequency of modulated IR from an array of IR sensors, which were delegated to their own cogs. Each behavior wrote their motor outputs to shared memory, and an "arbiter" cog chose the output from the behavior with the highest priority and sent it to the effectors. The rest of the cogs were devoted to servo controlling and serial i/o.
While some of the mechanical aspects of my robot need work, and the sensors definitely could've used more tuning, the robot overall worked great and it easily beat opponents with what seemed like a lot more money behind them. In particular, the robot that placed second used 2 AVR Atmega 128s, a Gumstix 400-MHz ARM based SBC running Linux, an IP camera and a holonomic drive train, among other luxuries!
I'd like to thank the people of Parallax for their excellent chip, as well as all those who have posted useful info and advice here in the forum, like Chip, Mike Green and Beau Schwabe.
I attach some of the photographs of the robot and the event. As you can see I'm using the Propeller Robot Controller, which is a great board. I'm the guy with the black shirt picking up the robot after a victorious duel. I may post some video as well, if I find out how to make them smaller.
Post Edited (acantostega) : 10/27/2006 7:54:26 AM GMT
400 x 300 - 62K
640 x 480 - 82K
300 x 400 - 53K
637 x 347 - 55K
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I just noticed that the price is now 50% lower.
The competition must wonder what exactly having 8 parallel processors really means.
Ping pong ball shooter is a great idea!!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········
Post Edited (Kramer) : 10/27/2006 9:56:36 AM GMT
[noparse][[/noparse]quote]
The propulsion method of the bulletbots may
be chosen freely, as long as no explosives, chemical or nuclear reactions are employed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Don't visit my new website...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"any small object, accidentally dropped, goes and hides behind a larger object."
ALIBE - Artificial LIfe BEing. In search of building autonoumous land robot
http://ALIBE.crosscity.com/
·
to know how you did it.
The Propeller really encourages the KISS philosophy, both in software and
hardware; no need to add yet another peripheral controller to handle this other
sensor here.
It was interesting to see al the different approaches to this. I started out using a weird solenoid with a spring I found in Electronics Goldmine. This was mechanically and electronically trivial (I just interfaced it with a transistor) but the resulting shot was rather weak. (According to the rules merely making the ball roll is enough.) I actually lost one round where both bots shot each other at the same time -- but the rival's ball hit me first (the judges used video to verify it). So I replaced the middle cannon with a mechanically more complex cannon my friend had devised earlier. It would be hard to explain without drawings, but it uses a servo to trigger a linearly moving mechanism that is loaded with a spring. It has the overhead of having to control the servo, but since I was using the servo32 object and just two modded servoes for the wheels I could afford it.
The team that placed second had a very nice cannon which was based on the same idea those tennis ball shooters use: there's two wheels spinning in the same direction between which the ball is placed to be launched. It threw the ball pretty hard, but it was mechanically rather complex and used custom parts.
True -- I had developed some robot software using a PIC16F877 using a similar set of sensors. I'm no expert on this chip, so it's possible what I did could've been done much better, but the point is that the software wass rather messy and had some bugs I still haven't figured out. I used a complex system of time-slicing for processing the more urgent sensory needs with timer based interrupts, and a (big) state machine for the main thread of execution. Still, I found the IR pulse processing was too hard to fit in with the rest of the program, so I ended up putting that in a PIC16F628 I had.
But with the Prop, I just dedicated a cog to IR proecssing and that was it.
It's interesting to note that Brooks' first behavior based robots actually ran on just one processor, with Lisp (or his own Lisp-based language, the behavior language) based multitasking. Then one of his students, Connell implemented a truly parallel robot with various processors communicated among them with a low bandwidth link.
The propeller based robot is a more convenient way of doing something similar, though the "arbiter" cog is not really in the spirit of the original subsumption architecture, since it centralizes the decision making.
It seems that the contest was Muti-tasking versus Parallel-tasking.
I suspect the parallel will always be less buggy to deploy.
Of course, the Propeller has a huge speed advantage too.
One doesn't really need more RAM and more ROM.
I have doubts that 'pure subsumption architecture' reflects a real world application. It just looks very neat in presentation and expands into a huge complexity.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"If you want more fiber, eat the package.· Not enough?· Eat the manual."········