Propeller robot framework
I have mentioned in a couple of other threads that I often bring up a new robot base in a basic RC controller setup, get the sensors going and then work from there.
The attachment contains a set of files I use. These are all for propeller. There are a number of files that might be on interest
*bot.spin - these are the main spin file for a number of robots
omnibot - 4 wheel omni
servo diff drive
4 wheel diff drive
2 wheel diff drive
2 motor track
These top level files, describe the bot, where you can get the main parts (if COTS). Note: It may not be where I got the part from.
motor*.spin - high level interface to motors, for various pwm drivers (l298/l293d/tb6612/mc33887), servos, dual serial micro controller (parallax/pololu)
Joy*.spin - high level interface to RC controller - ir remote, vex, PS2
imu6.spin - 6DOF imu
various sensors - compass, ir, etc.
I can post most details of the types of robots or the objects if there is interest.
The attachment contains a set of files I use. These are all for propeller. There are a number of files that might be on interest
*bot.spin - these are the main spin file for a number of robots
omnibot - 4 wheel omni
servo diff drive
4 wheel diff drive
2 wheel diff drive
2 motor track
These top level files, describe the bot, where you can get the main parts (if COTS). Note: It may not be where I got the part from.
motor*.spin - high level interface to motors, for various pwm drivers (l298/l293d/tb6612/mc33887), servos, dual serial micro controller (parallax/pololu)
Joy*.spin - high level interface to RC controller - ir remote, vex, PS2
imu6.spin - 6DOF imu
various sensors - compass, ir, etc.
I can post most details of the types of robots or the objects if there is interest.
Comments
It would be great if instead of having a variety of *bot files you have one bot file that load cogs based on the pin configuration or whatever other data you need to read to set the robot configuration. That way all the different robots are supported by different data, not different code. You could have the data be read off the EEPROM instead of a DAT block. Then add the ability to change the configuration through a terminal, to either set the pins, or choose from a list of layouts.
At that point you are starting to have a robot operating system. Users could set the hardware configuration without rewriting the program. Algorithms that run on the program could support a variety of hardware layouts.
I need to look at this some more. I don't know what each part does yet. But it is inspiring.
Interesting idea about the Robot OS, I will think about. The way I work is the top file contains the hardware config of the robot and that pulls the files for the hardware.
e.g. you pick the radio driver, the motor driver, etc.
I think you are talking about generalizing the top level file as well.
One think I can think of, is a single top level file that uses #ifdef for driver selection.
So you select a bunch of #defines, set the pin config table, the gyro/accel gains, etc. and build
though its going to be a in progress think for a while. Each time I try it on a different robot I find something that needs generalizing out. e.g. mapping a single joystick to left/right diferential drive I have a very simple +- system which works fine for very small bots but the larger one I am working on doesn't turn well without a different joystick merge algorithm
Thoughts?
PS. This will only build in my build environment at the moment, I tried bst and it didn't like it.
By the way-- I am seeing a lot of nice bits of code in here-- are you adding any of this to the object library? Just wondering, because it seems like you have written support routines for sensors that may not be otherwise supported.
I think this is really cool. I'm trying to squeeze in time to digest this so sorry for the delay.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Robots
Thanks for the great resource and the your comments regarding the MC33887 Dual motor driver carrier. I planning to use the MC33887 Dual motor driver carrier in a bigger robot.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James Ronald
MyRobots
Post Edited (James Ronald) : 7/12/2009 6:05:02 PM GMT
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Robots
In terms of platforms there are a fair number out there, though most i have not used as intended, using different motors, etc. as I got something cheap, etc. The bases that I built from scratch I can probably dig out the cad files if anyone is interested.
@James Ronald, I found the MC33887 very easy to use, better than the L298 which I used later with the same motors. I found I got more control over the motors with a higher PWM (high enough I dont hear the whine) than with the L298.
James Ronald
MyRobots
I still think I will experiment with a config loader, and see if I can get your files to work on a bot here.
G
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Robots
Robert
The next step would be to have a little interface to optionally configure the pins, particularly if they are not configured at runtime. I use tv_text and a serial keypad for debugging. Whatever problems I would have with memory for the objects would probably be worse with the tv_text object.
Just to keep a mnemonic string for each possible key value would take a lot of space. So that's another reason why I couldn't support all those choices. It would have to be a subset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Robots
Doesn't the LMD18200 require min 12VDC.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
James Ronald
MyRobots
Why yes it does. That has worked out well since most of my larger robots are using either 12V or 24V for the drive. If you are using less than 12V then you'll probably want to use one of the other drivers or roll your own.
Robert