Shop OBEX P1 Docs P2 Docs Learn Events
Propeller robot framework — Parallax Forums

Propeller robot framework

TimmooreTimmoore Posts: 1,031
edited 2009-07-21 18:02 in Robotics
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.

Comments

  • GeorgeCollinsGeorgeCollins Posts: 132
    edited 2009-07-09 05:40
    This is very cool. It would be nice if you had a readme to identify what the files are for, but the code seems pretty clear.

    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.
  • TimmooreTimmoore Posts: 1,031
    edited 2009-07-09 06:11
    I have some of the readme, I will work on it and add it when I update the package.

    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
  • TimmooreTimmoore Posts: 1,031
    edited 2009-07-09 20:49
    The attached has a couple of files containing my thoughts. There are 2 files for 2 robot configurations. They contain a bunch of #defines and some data structures for pin defintitions etc. The actual code for the robots is in other files and do not change. When you build the main robot config file, it uses the defines to decide what to use.
    Thoughts?

    PS. This will only build in my build environment at the moment, I tried bst and it didn't like it.
  • GeorgeCollinsGeorgeCollins Posts: 132
    edited 2009-07-12 14:49
    Yes-- this is exactly what I was thinking. You can get a variety of robots to run on the same code, the only difference being data definitions. You can move those definitions to the upper eeprom with a little terminal code. Then you have a configurable robot system that does not require someone to program. I think there are a lot of people that want to build robots, but do not want to program a lot, or want to program at an extremely symbolic level.

    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
  • JamesRonaldJamesRonald Posts: 39
    edited 2009-07-12 17:58
    Tim,

    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
  • GeorgeCollinsGeorgeCollins Posts: 132
    edited 2009-07-13 05:31
    Another really interesting thing-- as I go through the different bot files I am learning about robot chassis I didn't know existed.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    My Robots
  • TimmooreTimmoore Posts: 1,031
    edited 2009-07-13 16:58
    @GeorgeCollins, I will think about it a bit more. Making it a eeprom config system means all the drivers need to be included, that will mean its better than 32K so I will have to work out a system to overlay the correct drivers and require a 64K eeprom. The current system is a build time config so I dont have this problem. I will need to work out a better build config anyway - I use phil's Clean with the visual studio pre-processor which works but isn't particular user-friendly with error messages.

    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.
  • JamesRonaldJamesRonald Posts: 39
    edited 2009-07-14 01:48
    James Ronald said...
    Tim,

    Thanks for the great resource and the your comments regarding the MC33887 Dual motor driver carrier. I'm planning to use the MC33887 Dual motor driver carrier in a bigger robot.
    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James Ronald
    MyRobots
  • GeorgeCollinsGeorgeCollins Posts: 132
    edited 2009-07-14 04:14
    I didn't realize all of them would not fit into 32k. I probably have been compiling one of the smaller bot files, there seemed to be space but then you are supporting a heck of a lot of sensors.

    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
  • RobotWorkshopRobotWorkshop Posts: 2,307
    edited 2009-07-14 14:32
    If you need a good H-Bridge chip you should also look at the LMD18200 over the L298. I've used both and the LMD18200 is much more robust and seems easier to use. I have an L298 with a hole blown through the top which was later replaced by an LMD18200 which has been trouble free ever since. Both of these chips are good (one of my robots uses both) but the LMD18200 would be a better choice for bigger robot bases or something that may take more abuse without failing.

    Robert
  • GeorgeCollinsGeorgeCollins Posts: 132
    edited 2009-07-15 05:12
    Here's some code I was using to log the position of my robot in EEPROM. It keeps track of each of the moves (its a walking robot so every move is a sequence of steps: forward, backward, turn in place, etc.) and the theta from a compass. It lets me keep track of where the robot went and which way it faced. I added functions to read and write a word for each pin, to see if I could start using your config framework and store the pins.

    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
  • JamesRonaldJamesRonald Posts: 39
    edited 2009-07-16 03:00
    RobotWorkshop said...
    If you need a good H-Bridge chip you should also look at the LMD18200 over the L298. I've used both and the LMD18200 is much more robust and seems easier to use. I have an L298 with a hole blown through the top which was later replaced by an LMD18200 which has been trouble free ever since. Both of these chips are good (one of my robots uses both) but the LMD18200 would be a better choice for bigger robot bases or something that may take more abuse without failing.

    Robert
    Robert,

    Doesn't the LMD18200 require min 12VDC.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    James Ronald
    MyRobots
  • RobotWorkshopRobotWorkshop Posts: 2,307
    edited 2009-07-21 18:02
    James Ronald said...
    RobotWorkshop said...
    If you need a good H-Bridge chip you should also look at the LMD18200 over the L298. I've used both and the LMD18200 is much more robust and seems easier to use. I have an L298 with a hole blown through the top which was later replaced by an LMD18200 which has been trouble free ever since. Both of these chips are good (one of my robots uses both) but the LMD18200 would be a better choice for bigger robot bases or something that may take more abuse without failing.

    Robert
    Robert,

    Doesn't the LMD18200 require min 12VDC.

    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
Sign In or Register to comment.