A SLAM Bot
This is robotics test platform I'm developing to experiment with a class of navigation algorithms called SLAM (Simultaneous Localization and Mapping). I'm adding new material at the bottom as I progress.
Click on images for bigger ones
This is what it looked like early on. There were three decks at this point. The upper deck has nothing on it here – will contain interface electronics boards soon. The middle deck holds the Intel miniITX board. The lowest deck — the engine room — contains the drive motors, the motor controller, and two sets of batteries, one for the motors, the other for the Intel board.
Part of the difficulty in developing a small bot like this is in making all the parts accessible, for it is as certain as rain that they will need to be repeatedly before development becomes stable. With this need in mind, I came up with a system which allows each of the upper decks to hinge up out of the way. Most of the wiring will then be routed back around the hinge region. This view shows the unoccupied interface deck hinged up exposing the cpu level.
It hinges over freely so it can be completely out of the way at this point.
Here is a view of the hinges on the cpu deck with the upper deck removed. Click on the image to see it up closer.
The aluminum chassis, hubs and wheels come from Lynxmotion. The chassis includes a couple black polycarbonate panels which I haven't found a use for yet — the top one would be in the way and the bottom one I swapped out for aluminum to provide a heat sink for the motor controller.
This view shows the underside of the cpu-board when it is hinged up and over, exposing the laptop drive underneath and the "engine room". The batteries and motor controller will all go in that cavity shortly.
Here's what the engine room looks like with the two sticks of NiMH batteries that power the motors. The motor controller is visible bolted down to the aluminum bottom panel. Above it is an automobile relay to enable/disable the motor drive system.
A close up view of the interface electronics deck before I've drilled it and made heat cutouts for the cpu board beneath. There are three sources of heat in this passively cooled design: the cpu (the least of the three), the Northbridge (big black heatsink), and the memory.
The board on the left is a Phidgets DIO board (wtdin-m). The one in the back is a custom parallel port enterface board for the motor encoders developed by my friend Mark. This backplane arrangement is an attempt to be able to access the batteries for charging without removing them. I'm not sure its going to work - its a very tight space and the Deans connectors are quite stiff.
The green batteries are two stacks of NimH used for the cpu-board and other electronics. It's really tight in there. I'm hoping heat won't be a problem with the motor controller.
Here's what it looked like with two of the interface boards mounted after the cuttouts are milled in the acrylic. The main purpose for the DIO board will be to read analog sensor data. The sensor deck has yet to be added.
Bench testing phase.
An astute viewer will have noticed the addition of a WiFi antenna. I added a micro-pci WiFi card to the board with a 5dB antenna. The idea is to set up anad hoc peer-to-peer network so I can program and control the bot away from my lab using my netbook. I have succeeded in setting it up but I'm having trouble maintaining the link once it starts running.
I've also completely rebuilt the connection system in the back (click for a close-up). This is my second attempt to make the power connectors reasonably accessible. The first proved to be too difficult to manipulate, and while this is an improvement, I'm still not happy with it. I need to be able to connect and disconnect the power connectors easily, w/o a lot of force or pulling on wires instead of connectors. My power wiring is designed to enable me to easily charge batteries and swap them one to the other, or switch to and from a wall power supply without shutting down the cpu. I can now successfully do this, but it is still too hard to work the connectors. In my next attempt I'm going to make the Deans connectors face back as well as the concoder connectors.
Hey, Mark — I figured out how to run the ports out of userland without special privileges. For the serial ports, you change the permissions like this:
sudo chown <username>:<username> /dev/ttyS0 /dev/ttyS1
For the Phidget board (uses a USB port via udev), you need to create the file /etc/udev/rules.d/60-phidget.rules and put the product:device id's in the proper places. Download my file for template:
Make sure your product/device numbers match what's in the rule by running lsusb with the Phidget board plugged in. Put the file in /etc/udev/rules.d/.
The last thing you need to do is make sure you are a member of the plugdev group.
I wrote some code to plot tracks as logged by the bot while running. Here is the track from one of the early runs made while I was still debugging the tracking loop and figuring out how to tune the PID parameters.
Check out bot bloopers for a sampling of behaviors while tuning.
Still not where I want it, but much better. It's using the derivative now to kick it around in heading very quickly when the waypoint changes. Perhaps too quickly - this is all still up on testbench blocks, and inertia will certainly change the behavior. Here is a set of graphs of some of the control loop variables corresponding to this run.
It will probably be a good idea to develop a turn-in-place mode to be used when the waypoint changes the heading dramatically. TBD.
Back again. The turn-in-place approach is implemented and works much better. I put together a LaTeX write-up of equations for the PID loop I'm implementing.
Coming up Next
Dismantling a Neato NV-11 to steal its laser rangefinder.
Here is my amazingly compact (okay — crowded) work room. Note the submariner "machine shop" under the bench.