For a winter project I’ve decided to build a robot for the robomagellan competition next summer (summer 2012).
My project from the winter of 2010 was a cnc router which i actually use quite a bit and have been using to fabricate parts for my robomagellan entry: http://www.youtube.com/watch?v=pKNNdKDVfdE
I’ve come up with what I think is a pretty good design but building a robot from the robomagellan competition presents some pretty stiff challenges involving autonomous navigation and machine vision on top of weight and size restrictions. Were talking hard core hardware and software work here. Sounds like big fun to me.
I will be documenting the build here.
I’m ahead of schedule on the hardware:
high level control and vision: mini itx mb, 65w core 2 duo, 2.4Ghz, 2GB ram. I have linux (ubuntu) running on a 8GB compact flash drive with this rig. Hopefully i can stuff everything i need on the 8GB CF card, if not I’ll get a ssd. This setup gives me a pretty good amount of processing capability at a reasonable level of power consumption.
low level hardware control and sensors: arduino mega 2560 (the arduino duemilanove in the photo is used for testing the platform with a rc controller)
I am using ROS http://www.ros.org running on linux for high level control, navigation and vision (openCV) since its python friendly (I already have vision code running).
GPS (I’m getting 10 to 20 ft accuracy reading 7 to 10 sats INDOORS. I wouldn’t have believed it if I hadn’t seen it with my own eyes.)
Digital Compass. I’m getting about 3 degrees of jitter in testing, if that hold up real world I will be very happy.
Ultrasonic rangefinders (maybe, i’m not impressed with their reliability), maybe something else as a collision avoidance sensor.
USB camera (works well with ROS/openCV)
H bridge motor drive: built from the ground up. It seems to work pretty well using a rc controller (the rc receiver is connected to an arduino that provides PWM to the bridges).
power: 2-9ah 12v sla in series for 24v to the bridges. 200w 24v to 12v converter for the mini itx and arduino.
Low level sensors and control: reading the GPS
Since I’m using an arduino for reading several sensors plus motor control no one sensor can hog the arduino’s program loop. When I started testing the gps module my intention was to use the arduino tinygps library but i found that it caused some pretty big holes in the loop. I ended up just using the softserial librarys read() and sending the raw NEMA strings to the “pc” where i can parse it using python. Since read() is getting an already buffered character and immediately print() ing it to the pc getting gps data has essentially no impact on the arduino program loop.
A word about ROS http://www.ros.org
ROS can be intimidating at first glance but once you get the “concept” it becomes a lot easier to deal with.
The simplest description of what ROS does: ROS sends messages between modules called “nodes”.
For example. you have some python or c code that needs to process video from a usb camera. You would “run” a “node” from a ROS “package” (a functional group of nodes) let’s call it “camnode” that handles getting video frames from the camera AND “publishing” each frame as a message. Lets call the published message “cammessage”. Those “published” messages are sent to addressees (“subscribers” which in general are other packages). Within your video processing code you would “subscribe” to “cammessage” so that every time a video frame is sent from the camera you get it for processing. Note that published messages can have multiple subscribers.
The operating system part of ROS comes from the fact that you can “run” any number of nodes with ROS that do any number of things. ROS allows you to “publish” the messages (information) nodes produce and also allows nodes to receive (“subscribe”) to messages from other nodes.
This allows a lot of things to happen in parallel. For example, you can have a “brain” node that subscribes to “visionprocessing” which in turn subscribes to “cammessage”. “brain” also subscribes to “sensorinputs” and “navigationstuff”. “brain” in turn publishes “moveplatform” which is subscribed to by “platform”. Your video processing code could be the node that publishes “visionprocessing”.
Nodes are grouped into units called packages, packages are grouped into units called stacks:
Node: executable code modules (think function within a program)
Package: a package of nodes (think program)
Stack: a stack of packages (think a functional group of programs, for example, vision, mapping)
ROS has a large number of “stacks” that can do pretty much anything you might need to do in the way of robot control. And if it doesn’t have what you need you can create or modify stacks and packages.
This description is very bare bones and simplified version of what ROS does but it gives you the basic concept.
Note: the earlier versions of this were written with simplicity in mind after further reflection I decided to go with clarity.
H Bridge dc motor controller
Each H bridge basically consists of a hip4082 H bridge FET driver driving 4-75A 100V mosfets. I have three signal going into each bridge forward PWM, reverse PWM and disable. Note that the hip4082 does not allow any control input that would create “illegal” situations like a short. I also found out (the hard way) that you never send a hip4082 a PWM duty cycle of more than 95% (never go to 100%) you also want the PWM frequency to be relatively high.
So much for the CF
I had been testing ROS/openCV on a separate pc and running a bare bones installation of Ubuntu on “Conestoga” from a 8GB compact flash card in a CF to sata adapter. I started loading the development stuff (eclipse, pydev, ROS etc) on to the cf card and quickly found that I had used up the 8 GB and was no where near finished loading what I needed. Not being one to ignore the obvious I dumped the cf card hooked up a 500GB drive re-installed ubuntu and installed the development software. It’s probably all for the best because i will probably be “recording” a lot of test info. At some point i will switch to a ssd because I have doubts about the reliability of a hard drive spinning in 90 degree heat on a vibrating platform next summer.
The drive assembly
The drive assembly is from a robomow RL500 that I bought about ten years ago. It gave me about three years of cutting the back yard before the motherboard went out. It’s a bit slow (about 2-3 mph) so i may modify it or replace it. Conestoga is pretty modular in that everything attaches to a central aluminum extrusion so i could replace the drive assembly and not have to do much more than plug the new drive assembly’s motors into the h bridge.
I’ve been doing a lot of wiring on conestoga and there’s a lot of it to be done. It’s not just running wire from one point to another it’s wire sizing (high current, signal, sensors), fuses (safety), connectors (I have to be able to take conestoga apart for modification or repairs AND be able to easily put it back together), switches (is it off, operating or charging etc). I also have to document the wiring (hmm, where does that wire that is capable of handling 24 volts at 100 amps for a second or two go – maybe I should check the documentation before I connect it!).
Pretty much all of the wiring has to be done and verified before conestoga rolls an inch on it’s own. The wiring takes a while to do and is not the most exciting part of the project but it has to be done and it has to be done right. Wiring mistakes can both undermine your efforts and get real expensive quick. I have an old habit when it comes to wiring, I check everything three times.
Patience pays off at this stage of the game.
I set up the front bumpers to trigger on switch released rather than switch pressed (automotive brake lights work this way). The bumper triggering is stable (no false triggering) but also pretty sensitive and the switches are immune from damage due to collisions.
Sensors and vision test
The vision code is processing frames at about 15 fps. The arduino is reading and processing information from the GPS, compass, wheel encoders (pulse count and velocity), front bumpers, voltage and current sensors. It’s also sending a count of times through the arduino’s program loop between reads of the sensors (gives me an idea of how much “horsepower” I have left on the arduino and helps with timing issues). The arduino gets information from the GPS once per second and the other sensors every 130 milliseconds and sends the information to the Python communications module. Processor utilization is pretty low considering whats going on (two python modules are running in eclipse as ros nodes plus roscore and a couple of other ros nodes).
The wheel velocity code on the arduino still needs work and I haven’t connected the voltage and current sensors yet. At this stage I’m using a pc power supply for testing (no point in using battery power for this type of work. Also, the h-bridge motor controller is not being powered). I still need to add front collision sensors to supplement the bumpers.
The python module for listening to the arduino seems to work pretty well, next comes the python code for talking to the arduino (motor control etc).
A word about Sealed Lead Acid (SLA) batteries
Downside they are heavy, upside they are cheap:
12v 9ah SLA batteries are about 15.00 each (I use 2 in conestoga)
LiPo equivalent would cost about 60.00 – 70.00 (or 120.00 – 140.00 for my needs)
Not a hard decision for me.
If you don’t take care of SLA batteries you can kill them quickly:
Rule 1: do not deeply discharge them. If the voltage goes below 10.7v (for a 12v battery) you risk damaging the battery. Also, use a charger that will not overcharge the battery, overcharging will also damage SLA batteries.
Rule 2: see rule 1.
I put a voltage sensor on conestoga (along with a current sensor) so that the software can keep an eye on the battery voltage.
Back from work 24/7 land
I had a couple of consulting projects come in that didn’t allow for much mindshare going to conestoga over the last several weeks but the projects are starting to “tail off” so i can give conestoga more time. In the mean time I have gone back to using arduino duemilanove’s for drive control and sensors. I found the mega 2560 to have reliability issues that I did not want to deal with plus I believe in having spares and duemilanove’s/uno’s are cheap. Expect more info and photos over the next few weeks.
Ubuntu And ROS
I finally got around to moving Ubuntu from a hard drive to a ssd:
I had to move conestoga’s ubuntu setup from a 500GB hard drive to a 64GB SSD (smaller drive).
This is what I did for those who are interested:
I backed up the drive with tar and copied the backup to an external hard drive.
I shut down ubuntu attached the ssd restarted the computer went into the bios and enabled ahci (a sata setting)
I then booted into ubuntu using the ubuntu 10.04 live cd (I’ve got everything running fine on 10.04 and if it ain’t broke don’t fix it).
When given the choice of installing or trying ubuntu I chose try.
After reaching the ubuntu desktop I connected to my wifi so that I could download drivers while installing (I had a usb wifi adapter plugged in)
After connecting to wifi I started the ubuntu install by double clicking the install icon on the desktop.
After ubuntu finished installing I rebooted into the new install exited and rebooted into ubuntu again (this is just something I do. It’s probably not necessary but I do it anyway).
I made a backup copy of the fstab file from the new install (/etc/fstab)
I restored the original ubuntu installation from the tar backup.
I copied the new installs fstab back to it’s original location in case the tar install over wrote it (which it probably did).
On the first attempt to reboot ubuntu failed to start. Looking at the boot error indicated a problem with the grub bootloader so I downloaded the Linux Boot-Repair iso and burned a dvd of it. I booted conestoga with Boot-Repair and followed the directions for repairing grub then rebooted successfully into ubuntu. Everything was there and working.
This was the easiest and most problem free way I found to move an ubuntu installation from a large hard drive to a smaller one.
I will probably do some additional tweaking of ubuntu for the ssd (trim, swap etc.)
Ubuntu boots in less than 20 seconds and everything seems faster more responsive with the ssd.
The ssd I used was a Microcenter house brand 64GB ssd.
Design Change (If I had a boss and he/she told me to do this I’d be mad, however…)
A couple of weeks ago I finally fired up everything on conestoga all at the same time (mini-itx, drive, arduinos) while checking the battery voltage. It became quickly apparent that the 24V to 12v converter that was powering the mini-itx was a major power hog and it was going to cause me grief in the form of run time and possibly system stability. It didn’t take me long to realize that I needed to change conestoga over to an all 12v system. Basically this meant new motors, new or rebuilt motor control electronics and a major rewiring. No problem, time to harness the power of ebay and the internet. I found a couple of new power wheels motors on ebay, the gears I needed from SDP and shaft adapters from a rc supplier. I didn’t think I had the time to rework the motor controller that I had built for 12 volts so I ordered a sabertooth 2×25 controller.
The rewiring was actually no big deal it was basic drudge work wiring. I had to make new motor mounts which involved removing the wheels and gearing taking measurements designing the mounts and cutting them out on the cnc router. I also had to come up with new wheel encoders (the encoders went with the old motors). Luckily when I bought parts for the cnc router I bought 6 or 8 high quality proximity sensor at a steal of a price and I used them and a metal “flag” on the end of the motor shaft for wheel encoding (90 encoder ticks = 1 wheel revolution). I installed the motors, gears, wheels mounted the proximity sensors and fed their outputs into the arduinos through a couple of idc5 input modules. I wired in the sabertooth controller and hooked it into the rc receiver for testing. After a final check of the wiring I fired everything up, no sparks or drama, time to test.
Your’e going to want to read this paragraph
I fired up the rc controller while conestoga was still on the stand that I use to work on it and gave it a little gas, the wheels accelerated fast, ok that’s cool, it’s on the stand under no load it would accelerate like that. I had to move a couple of connectors to make the wheels turn in the right direction (forward is forward right turn turns right etc). Time to take it off the stand and see how it rolls. I fired it back up and give it a little gas (I’m using a rc car type controller) and it takes off across the basement floor at about
20mph 10mph, I reflexively released the trigger and overshoot the dead zone putting it in reverse, it stops on a dime and goes into reverse, not just any kind of reverse, it pops a wheelie and not just any wheelie were talking a 30 to 40 degree wheelie for about 3 or 4 feet (the front bumper assembly was acting as a wheelie bar). I finally got the trigger into the dead zone and stopped it. Now consider this, conestoga weighs about 40lbs with most of the weight between the front wheels (large) and the rear wheels (casters). After that test it makes me wonder if I should enter it into robomagellan or take it over to thunder road on saturday nights and drag race it for money.
When I purchased the power wheels motors my main concern was that they would be under powered, they are considerably smaller than the motors that they replaced and ran on half the voltage. The fact that they were motors used in power wheels cars (picture a bunch of kids in a plastic jeep) and that the stall current for these motors was 40 amps should have told me something. I thought that before I did any more testing that I should look at the rc controller documentation and find out how to limit the rc controller output. I found the information and cranked all three channels down to 25% output max. When I fired conestoga up again and began testing it was totally controllable with the new rc settings. I was impressed with the sabertooth controller, I had set it for differential steering so that trigger forward or reverse moves conestoga straight forward or backward, but it also steers smoothly when you turn the steering wheel on the rc controller. And get this, if you turn the steering wheel with no forward or backward acceleration conestoga rotates in place. I spun it around both right and left about 10 times and it did not drift out of the circle it was making. That’s a whole lot of programming I don’t have to do. During testing (admittedly in the basement on a smooth floor) the motors seemed to use surprisingly little power and ran cool. We’ll see what the power consumption is going to be on grass but the wheels and drive assembly are from a lawnmower so it likes rolling in grass so I think it is going to run pretty efficiently.
At this point it’s time to start integrating the software so that all of the bits I have been working on separately begin to work together. Time is getting tight.
All of the hardware and software for conestoga are falling together pretty well. I will have an update later in the week when I have more time.
In the mean time, for those who are interested, here’s some information on how to make a housing for your robot FAST, CHEAP and LIGHTWEIGHT. Items needed: foamcore (foam board), fiberglass fabric, water based polyurethane (the stuff used on furniture and floors, I used minwax polycrylic) and brushes, an old credit card or similar card, a sharp utility Knife, a hot melt glue gun, box tape, scotch tape (or similar), a straightedge and something to cut the foamboard on (i use a thick sheet of glass), latex or similar gloves and plastic drop cloth. Pretty much all of this stuff can be picked up at any home improvement store, the foam board is available anywhere that sells school supplies.
The quick and dirty: Figure out what you want your housing to look like, cut the pieces out of foam board and tape the pieces together initially with scotch tape. Tweak it until you have it the way you want it. Tape the seams together with box tape (you could probably use any wide tape for this but clear box tape worked for me), this will close the gaps and smooth the seams somewhat. Use additional pieces of foam board for stiffening. attach the stiffeners using hot melt glue. Attach your housing to something that will not interfere with the application of the fiberglass (I used an old 3 foot ladder, screws and tape). Spread your drop cloth under your work area, you are going to need it. Cut a piece of the fiberglass fabric large enough to cover the housing with a decent amount of overhang, set it to the side. Open the polyurethane and mix it. Brush a thin layer of poly on your housing and let it sit for about 10 minutes until tacky (this will keep the fiberglass fabric from sliding around too much). Take the fiberglass fabric and apply it to your housing. “Paint” the fiberglass liberally with polyurethane allowing the fabric to form itself to the contours of your housing. Use the credit card to squeegee the housing so that the fiberglass is smooth and there are no bubbles or excess polyurethane. Let it sit for however long the polyurethane instruction say before re-coating, two or three coats should do it. The fiberglass that overhangs the edges are easily cut with a utility knife or scissors. That’s it, two or three hours max and most of that time is waiting to re-coat.
The housing for conestoga is more of a sun shade than a full housing but it serves several purposes. It’s a sunshade (it’s going to be hot if last years robomagellan was any indication). The large hole is for a slow turning fan that moves a decent amount of air, the housing channels that air over the motor drive, motors and motherboard and out the back (that hole will have a shade of its own). It will also serve as a rfi shield (more on this later).
Issues this time around.
The main issue for me was great hardware running software that was pretty raw and unfinished. The software is almost as big a job as the hardware (currently about 2500 lines of python plus 450 lines of arduino code) and I was unable to finish a stable version by the time of this years competition. I also found that for my purposes ROS was more trouble than it’s worth (too many black boxes each with it’s own learning curve) so I have rewritten conestoga’s software without it.
I found an issue with pythons serial communication with the arduino. If I run the serial routine that reads sensor and status information from the arduino (which is the hardware controller for conestoga) in the same python module as the vision routines the data received from the arduino would slowly fall behind “realtime”. The problem wasn’t lack of processor horsepower (even with 2 cameras running some very compute intensive routines the processor cores generally only show about 30-40 percent utilization. I eventually came to the conclusion that the video routines were “bigfooting” serial communications somehow. I decided I wasn’t going to waste my time [fill in you favorite expletive here] with it so I put the serial routine in a separate module and used pythons multiprocessing library for communications between the modules. Long story short, problem solved. I am able to receive and process serial data as fast as the arduino can send it. I also decided to also use the multiprocessing library with the camera routines and I found that the processor cores are being used more efficiently.
I found that I need a wifi router on conestoga so i can talk to it with my tablet/phone where ever it’s at (if conestoga is too far away from it’s router I can stop it with the kill switch but I can’t program it or manually drive it). I have a linksys wrt54gs that runs on 12v that i will probably use.
The software looks pretty good so far. This coming Robomagellan I suspect I will have both hat and cattle.
ps. conestoga makes a perfectly good pc when it’s not rolling around (I am editing this page with it) I think of it as an extreme case mod.
TP-Link Nano Router (Model TL-WR702N):
Most of conestoga’s life is spent being a ubuntu based pc that looks like a robot (23″ monitor, keyboard, mouse, speakers, wifi, pc power supply, the whole 9) it is occasionally a robot that runs off of a pc. That being said:
I needed a router for conestoga so that i could manage it over wifi (enter gps waypoints, modify settings etc.) using a remote desktop client on a laptop or tablet while running/testing conestoga away from the house (ubuntu can be set up to accept connections from remote desktop clients). I was going to use a linksys router which I would probably have had to mount on top of conestoga’s housing because of it’s size. The linksys router in addition to being large is also power hungry because it’s also a 4 port switch (1A @ 12v). While knocking around online I came across the tp-link router that from the specs. seemed like it would do what i needed in a very small package while at the same time using very little power. It’s usb powered which means it draws less than 500ma @ 5v, it was also inexpensive. I ordered one and it came in today. I was able to set it up and install it on conestoga in about an hour and a half and it works perfectly for my purposes. It’s set it up as a wifi access point that is also a dhcp server (it hands out ip addresses to devices that connect to it). It has 1 ethernet port which is connected to conestogas PC ethernet port. Conestoga now has it’s own wifi network that goes wherever it goes. I am able to connect to conestoga via the tp-link (conestoga wifi) for remote access or via conestogas usb wifi adapter (house wifi) for internet, system backups, remote access etc.
Notes: if you are using both a usb wifi adapter and the tp-link (or other router) they must be on different “networks”, for example, conestoga’s usb wifi adapters ip address is 192.168.15.136, conestoga’s ethernet port address is 10.10.0.10 and the tp-links address is 10.10.0.254. (192.168.15.xxx is the house network, 10.10.0.xxx is conestoga’s network. note: xxx means 0-255). This means you will have to change the tp-links default address if your current wifi uses 192.168.xxx.xxx addresses (out of the box the tp-link’s address is 192.168.1.254 which would cause problems). It is also best if the network adapters (usb wifi and ethernet) ip addresses are static. When you setup the static address for the ethernet port also click on the “Routes” button and check “Use this connection only for resources on it’s network” this will keep the tp-link from becoming the default gateway and blocking the internet connection (if used) on the usb wifi adapter (this for ubuntu, for windows i suspect you would just not give the ethernet port a default gateway).
More notes: I’m basically a windows guy for work and personal stuff because I think it’s better for most normal situations (bring on the hate, I can take it). My main pc: sabertooth 990fx/amd fx6100 (I know, core Ix’s are better but I’m an amd loyalist), 16 gb ram, 750 watt ps,, windows 8, two monitors (I had three, but I found that I had gone too far, I didn’t have anywhere to put the tv). However, for “utility” pc’s ubuntu is the way to go: data recovery, cnc, “robots” etc. I like it because ubuntu is a great os and you can get open source software for just about any purpose if you are willing to deal with sparse documentation (in some cases).
The photos below give an idea of the size difference between the linksys router and the tp-link.
Out with the old in with the new (not robot related):
I finally got tired of paying my “satellite tv provider” 90.00 a month for the privilege of watching a few good shows and not looking at tons of crap. My solution was to put together a “media center pc” (it’s just a quiet pc running windows 7), purchasing a Roku (google it) and a “home theater receiver”. I wish I knew what I know now a couple of thousand dollars ago, the setup I have now is better than what I had before. The roku with netflix, hulu plus and vudu among others plus the streams I can get on the pc give me both live (mostly news) and on demand viewing of pretty much anything I want to look at.
Return of the mega
I broke down and put an arduino mega back on conestoga for low level platform control and reading sensors. I need three serial ports plus wire (compass) plus the ability to read the rc receiver plus everything else. I was doing the serial ports using softserial on a duemilanove and it was working pretty well but I was getting occasional glitchiness with the rc which was probably caused by the overhead from the serial port routines. I would get a bad reading occasionally and occasionally was too much for me. I installed the mega modified the software and now everything runs as solid as a rock (the Mega has 4 hardware serial ports).
While I’m replacing stuff:
I use a 12v to atx power supply for the PC parts of conestoga (when it’s setup as a robot rather than a PC). I noticed early on that I was getting a lot of noise out of the power supply I was using, so much in fact that the noise was strongly visible on the LCD monitor I connect to Conestoga for testing and programming. A power supply generating that kind of noise could not be good and continuing to use it was asking for it (most of the time when a power supply fails you can replace it and move on but sometimes they go and they take the computer with them). I’m not exactly squeamish about changing things I don’t like and I didn’t like that power supply so I ordered a new one (different from the one I had). I installed it this weekend and the noise is gone plus the new power supply has a very nice blue led.
New power supply