Did you just buy a Wii-mote for a robotics project and you can’t wait to use it? If you have a 15-tonne hydraulic grappling arm at your disposal, you could do what these guys did.
I am sure this beats the crap out of whatever you had in mind of controlling with that Wii-mote. Feeling inadequate yet? [Source: Entity Crisis via Gizmodo]
“Subsumption?” I hear you say, “What’s that?” Subsumption is a form of behaviour based robotics where multiple behaviours can control a robot using a hierarchical system. However, don’t take my word for it! Check out Thom Roach’s great new blog. He’s written some really ace articles on the subject without reverting to dry stuffy theory like you see in most research papers. Using clear text and simple diagrams he shows us how you could make a simple robot that uses subsumption to get around. Be sure to read them in reverse chronological order!
Several months ago I saw on the Mindsensors website that they were looking for beta testers for their upcoming Line Leader sensor. I applied and shortly thereafter I was contacted by one of the guys there named Deepak. He told me they were still in Alpha testing phase but that they’d get back to me when they were ready to send out beta sensors. True to their word, a few weeks later, I was the lucky recipient of one of their beta sensors.
The Line Leader sensor is not just an array of LEDs and receivers but can actually take care of a lot of the heavy lifting usually done on your NXT. It has a built-in PID controller that can return a value that can be used almost directly to control the speeds of your motors! The sensor is not *just* suitable for line following, of course. You can get all the raw data from the sensor through I2C. That includes the average weighted value of the sensor, but also which of the 8 sensors is currently detecting something. This makes it possible for you to use your own PID controller or use the data to navigate your robot along a line maze.
I set out to line following build a robot that could handle tight turns, so a low center of gravity was a must. I gave it extra large wheels to be able to get a bit of extra speed. I think the result is quite good. Tammy took some awesome pictures of it and the sensor.
A track had to built to test the sensor, so I got some large thick paper sheets, white for the background and black for the lines. I affixed the background paper to plywood for extra strength. The program I wrote is a modified version of the one supplied by Mindsensors. Mine allows you to tweak all the parameters (Kp, Ki, Kd and motor speed) without needing to recompile through a menu driven configuration tool. The settings are saved when you change something and when you exit the program.
Here’s a video of the robot on the track:
The batteries were a bit flat, so I can probably make it go faster, stay tuned for more videos!
Here is a link to the program, it requires RobotC 1.40+: [LINK].
It’s been a little while since my last article about adding peripherals to the NXT, but not due to the lack of experimenting and programming, let me tell you. In my quest to tame the Maxim MAX127, I ran into a few annoying bugs in RobotC. The first one involved not being able to use structs of bytes to send I2C commands to the sensor and the other involving automatic conversion of unsigned bytes to signed integers. RobotC does not really support unsigned variables, with the exception of bytes and chars. When you use an unsigned variable inadvertently you’re greeted with a nice warning:
Warning*:ROBOTC only supports ‘unsigned’ qualifier on ‘byte’ / ‘char’ sized variables. Ignored for other type.
I figured out a work-around for both bugs, so all is well now.
To the right you can see the fruits of my labour; a breadboard with a MAX127, a pot meter and a bunch of other components, as described in the table below.
| R1, R2 | 82 KOhm |
| R3, R4 | 1 KOhm |
| R5 | 1 KOhm pot |
| C1 | 4.7 uF |
| C2 | 0.01 uF |
| C3, C4, C5 | 0.1 uF |
| D1 | Red LED 10mA |
The LED is there merely as a status LED so you can see when power has been applied to the board. The connector is a home made one, as described in this article.
The schematic for this can be seen on the left. It would be very trivial to add more pot meters to this and tweak the program to make use of them. Of course, pot meters are not the only thing that can be read by an ADC such as the MAX127. You could connect IR photo-transistors, thermistors, LDRs, you name it! In a future article I will be hooking up various other sensors and use them as inputs for a robot. Stay tuned for more information.
The source code for this article can be found here: LINK.
Next Saturday (21 July 2008 ) I am giving a presentation on the Parallax Propeller microcontroller and I thought it would be a nice idea to demo some things with it. I have a Propeller Education Kit (PEK) and a Propeller Proto Board (PPB), kindly donated to me by Parallax. The PEK is awesome for learning how to use the Propeller as it comes complete with a veritable mountain of components, including the chip itself, of course and a very big breadboard. The PPB is great because it allows you to hook it up to any monitor using the accessory kit that comes with a VGA and 2xPS2 connectors.
From my days with the BoE Bot I remembered a lesson that taught a way to gauge the distance to an object using an IR sensor and LED. On a microcontroller without an Analogue-to-Digital Converter (DAC) built in this would only allow the a simple “object detected” and “no object detected’ state. That is not very useful in a real environment. The IR detectors are quite tricky little things. Most of them are sensitive only to a very limited wavelength of light, usually somewhere in the 950nm range. However, in order for them to be less influenced by regular light, especially fluorescent light, they are made to be sensitive only to light that hits them at a certain frequency. This frequency depends on the sensor make and model and usually is set to anywhere between 32KHz to 40KHz.
This bring us to the first method of object detection. Although the sensor is made to detect incoming IR signals at 36KHz, that does not mean it can’t detect signals at other frequencies. It can and will detect them, just not as well. We can exploit this property by varying the frequency we make the LED flash at. I used the TSOP2236 that is preset for, you guessed it, 36KHz. As can be seen from the graph to the left, the response is not quite linear, but it’s as close as it’s going to get. If we take 36KHz as our base frequency and sweep as high as 1.2 x base frequency then our top frequency will be 43.2KHz. We will ignore everything on the left side of the bell curve.
So how does it work? A non-optimal frequency makes the sensor a little more short-sighted. The less optimal the incoming signal is, the more short sighted the sensor will appear to be. We take the frequency range between 36 and 43.2KHz and chop it up into 100Hz parts. That gives us 73 possible readings. Instead of writing a whole bunch of code myself, I took the code from the PEK bot project on the Parallax site and modified it a little to make it a bit more flexible. 
I set up the circuit on the PEK and took readings from 5 to 30 cm in 5 cm intervals. There are no absolute frequency values, just frequency index numbers. In order to reduce the noise, I averaged 10 readings at each distance and repeated the experiment 3 times. The graph is pretty much what I expected; a somewhat non-linear response to the incoming frequency. It is a nice way to be able to tell roughly how close an object appears to be, rather than the binary “object detected”/”no object detected”. However, can we devise a better method?
This method does not depend on sweeping the incoming frequency to make the sensor short sighted. Instead we will merely reduce the amount of light the LED will emit at the base frequency. This method was discussed at the Stamps In Class forums. The project uses preset resistors set up in a parallel configuration, allowing for a wide variety of combinations resulting a large range of different resistances. One of the readers of the post suggested using a digital pot meter, in other words a DAC to vary the resistance. I picked up one of these DACs, an MCP41010, that has a range of 0 to 10KOhm with an 8bit resolution, giving it 256 steps. I picked it because it has an easy to use SPI interface.
Programming the code for the pot meter wasn’t terribly difficult in hind-sight but this was the first time I had used SPI. I managed to find some code that used SPI for some other device, I modified it to use the commands described in the MCP41010 datasheet. I was pleasantly surprised how easy it was to get working. To the right is the layout of the circuit I used. The controller has been left out for clarity. The tests were done by starting the MCP41010 in its maximum setting and slowly decreasing the resistance in steps of 5. I think going through each possible setting would’ve been overkill and this still gives us 52 steps.
The results were, well, a little less than overwhelming, to be honest. The curve is very similar to the previous one. For the amount of extra circuitry and code you don’t get a whole lot more performance. It was a fun experiment and perhaps there are some things you could do to improve this circuit. If you have any suggestions, please leave a comment.
The experiments were done with both circuits on the same PEK at the same time. This allowed me to test both circuits under the exact same circumstances. I secured the breadboard in place with some tape and drew lines at 5 cm intervals from the front of the PEK. I used a large non-IR transparent object (read: wooden box). I made sure the object was perpendicular to the sensors at all times. The button on the right side of the board is the trigger. Each time it is pressed, the first sensor is tested 10 times followed by the second sensor. This allows me to move the object without getting any readings.
Above right is a picture of the breadboard with everything on it. I hope you enjoyed this article as much as I enjoyed doing the experiment.
You can find the code for this project here: LINK.
My current project, well, the one I seem to be spending the most time on is a robot called A-Maze-Ing. It is based on a Lego Mindstorms NXT brick. This robot is, or rather, will be, a line-maze solving robot.
The first challenge in building this robot was its size. Rules dictate the robot should not exceed 15×15x15 cm at any time during the run. That might seem like a lot, but the brick’s size and the motors’ lengths make this quite a daunting task. It took quite a few iterations.
The robot on the left (above) is one of the first models. It was badly designed as it turned out because the light sensors were packed too closely together. I would get false positive readings on the side sensors even when no crossing or T-junction was present. The second model on the right (above) is the current model. The sensors are placed as far apart as possible and the swivel wheel on the back of the early model has been removed completely. The robot now makes use of two round bricks that it slides on as shown in the picture on the right. As of this moment he robot can’t do much yet. So far I have programmed the state engine frame work and the ability for it to turn right when it detects a… right turn. The other parts of the state engine do nothing.
Here is a quick, very short video I made of A-Maze-Ing’s ability to detect a right turn and turn. It will try to place itself correctly on the line once the turning is done.
More videos will follow as I progress. The first goal is to make a robot that can solve a maze without loops using the simple follow-the-right-wall method. Next generations will be able to solve mazes with loops and ultimately calculate both the shortest AND quickest paths.
It seems it’s been years since I last blogged anything. I used to run a blog at mightor.blogspot.com but I guess I ran out of ideas to post about. This blog’s title is a good summation of what I think about when I am at work or doing something I’m not really enjoying.
I’ve been building robots for a little while now and am now the proud owner of no less than 4 robots, in various state of assembly. I have two Lego Mindstorms NXT sets and two Parallax Propeller based robots. I will be posting more details about those later.
This blog will serve as a journal as my robot building progresses over the next while. There are some competitions coming soon and rest assured I will be posting about those as well.
