In this essay I write about robotics from the viewpoint of my current robot car project: How I got interested in learning to build it? How it was designed? And pretty much about anything that comes up on my mind and has some relation with robotics, including some thoughts about Lego NXT.
I scheduled the robot project strategically mostly to the end of the year, as my girlfriend is on a vacation for the christmas holiday with her grandma and I’ve been able to mess up the apartment as much as I like.
Im in a point where I have the robot moving around the apartment autonomously. There are still lots of improvements to be made, mostly in code, and I’ll talk about them in upcoming chapters. First I’m going to write how I got interested on building it.
In the end last summer I decided to start playing little bit with hardware. One of my friends had told me about his robotic projects with Arduino and recommended it as a learning platform. I bought an starter kit as it seemed to provide a nice documented introduction to electronics and micro controllers.
During the autumn I started collecting parts and tutorials and making notes of learned things and ideas.
So then the course came and Lego NXT was introduced with RobotC and it’s virtual learning environment, I was not really into it (although the course was awesome as a whole), as I could do the same physically with parts I mostly already had.
I started the robot project with girlfriends cell phones sell packaging as a body and lego’s as other parts, all connected with hotglue. One servo glued to the front to provide steering. The first version had one motor (from dead Canon printer) with a rubber band belt drive, that didn’t work well at all. Rear axle had too much friction because of the bending lego’s that the band broke up all the time. The packaging was also very tight, I could have fitted an Arduino mini with small battery and motor driver in the body, but I decided to remake the whole body.
I tend to save almost all product packages for reuse and Apple devices tend to have very good packagins, so I used a one size bigger box instead. Other new design detail was that I decided to change bend drive to a “semi-differential” drive, meaning that it has capability to differential steering, but I’m not yet properly using it that way. Using 2 motors with wheels attached straight to shafts was also much simpler and more durable.
For some time I had an idea of running a single small motor with current that the micro controller could supply, but with two motors I really needed a better way to run my motors. I bought an 2A motor driver shield addon for the Arduino, as I now had space to pile boards on top of each other.
Next major problems were bad battery performance and poor rear wheel attachment. Loosely attached wheels made a lot of resistance to the motor and Li-Ion cells I had laying around were not giving enough current for the robot.
Then the robot project almost stayed still for over a month as I was on a vacation for one week (did read Robotics Primer almost halfway through on a sunny beach) and then I had loads of other coursework until the christmas-break.
I had done some quick research on different battery technologies suited for small hobby projects and ordered a 5Ah 2-cell LiPo battery from eBay. LiPo is currently the greatest battery technology for RC-cars, -helicopters and all other electrical portable things. The downside is that it needs to be handled properly, or it would lose it’s lifetime or blow up.
Currently I have a simple voltage halving circuit ready, so I could power the robot off automatically at low battery voltage to prevent damage. I just have to write the code for it, but I decided to make it later as I realised that the battery drains so slowly that I can monitor it manually with multimeter.
Rubbery lego-wheels got replaced with harder ones stolen from a toy car that fit perfectly. At body testing phases I had a small joystick connected to the micro controller so that I could drive the thing manually. I spent several hours on bluetooth remote control from Android phone, but I still need some time to get it. I’m trying to do a python program that reads phone orientation sensor values and throws them to Arduino through bluetooth serial port and Arduino tells back what is going on. That would be handy in debugging the robot navigation too.
First I thought of just mimicking Braitenberg’s photophilic device, but I found the proximity sensor more interesting, so I used it first. I used another servo for rotating a column made of a plastic bottle that holds the proximity sensor. I also added a bumper sensor, but it is currently disabled as I don’t yet have a clear idea how and where the bump should be processed. It will really come handy when it works, as the proximity sensor can’t see low objects that robot just runs at.
The current navigation algorithm is my first one and there are lots of things to improve. Basically the robot uses it’s proximity sensor to scan it’s surroundings. It get’s 6 readings from different angles and after that decides what to do. Currently it first checks the 2 sectors right in front of it and if either one of those two distances is less than 20cm (which happens in case the robot is driving towards a wall) and if so, robot drives backwards and turns 180 degrees. If there is no obstacle in front, robot looks for the longest distance, turns that way and drives 50cm forward. The movement is pretty slow this way and I’m going to experiment with driving forward to an “empty” direction until the wall is coming too close, or bumper sensor hits to an obstacle.
Here are a couple videos of the robot in action (there is a slow version of movement algorithm in the start of the long video that is fastened to 400%):
There comes some problems with the proximity sensor when it won’t get a proper reading. Most often it happens in directions where there is still free space for the robot to move, and I made the robot follow those 0cm-directions if possible. The 180 degree turn activates too often currently and makes the robot go back to places where it just had encountered a wall. The rotation direction should also be decided according to the side that has most free space around the robot, as it currently rotates always clockwise.
First I was going to use a couple functions that would pass an array of direction-distance readings to each other so that code would be formatted more nicely, but I remembered that you can’t do that in C, which is sad. I’m going to learn passing the references around the functions someday in the future.
I’m using standard high torque DC motors without any sensory equipment reporting their rotations for the micro controller, and that makes driving very inaccurate. I did a quick drive-function that takes a centimetre value and converts that to a time the motor spins, so it made the code more readable for myself. The magical constant indicating how much time every centimetre takes is calculated by testing the robot on the floor with it’s full weight load. It can be clearly seen that the robot moves much smaller distances when a video camera is mounted on top of it.
Turning function uses differential steering capability of the two motors. The front servo must be rotated first to a position where it rotates freely as the back wheels start turning the robot in place.
I think the whole front servo is a bit stupid idea. I don’t see any proper uses for it and it complicates the differential steering implementation. One answer would be splitting a plastic ball in half and glue the ball on the bottom of the car and get rid of the servo. A small office chair wheel-like wheel would probably work too. Making a Seqway-like self balancing 2-wheel robot would be a nice task too, but maybe I’ll think of doing that in a later moment.
There is also problem in moving forward so that the robot would drive with a static speed. There is a possibility that the motor driver I use has a load monitor that I could read during using the motors. That would make decreasing voltage possible as the speed has increased enough and sensing rough terrains or obstacles when the motors constantly eat all current they can get.
Implementing a proper acceleration algorithm would do good for the motors, as currently they are pretty stressed as voltage is jumping to the maximum right away.
The code: https://gist.github.com/jasalt/6064368
Thougths on Lego NXT2.0
For christmas I bought an Lego NXT2.0 set. I had lots of fun playing with the stock IDE and its tutorials with my brother and cousin during christmas time. I also salvaged all Technic Legos that were still left from since I was playing with them 10 years ago.
I’ve thought that I should learn the stock IDE just for that I could teach it to people new to programming. Otherwise it is pretty hard and frustrating for me to learn, as I have never really used a visual programming tool like it. What I’ve read and heard, the RobotC seems to offer the best tools for programming NXT, but I don’t think that I’m going to buy it, so I’m going to first try NXC.
I’ve already got a NXT robot built that resembles the robot car built with Arduino. I’m going to write the same code for it for comparing how they both behave differently.
The Lego robotics kit is really great, as it is fully compatible with other Legos. Building robots in different forms is really fast and fun. However there are some downsides to it compared to building some robots with Arduino. The NXT brick takes a lot of space and the consumer version I have eats AA batteries (without hacking), which is not nice in my opinion. The additional sensors also cost pretty much compared to generic sensors you can connect to Arduino and use with libraries found online.
There is a nice thing about both of these platforms, they’re open source (not probably completely on the low processor level). That makes it possible to build custom made sensors for NXT-brick. I’ve seen some tutorials where people build accelerometer-sensors for NXT brick with help of Arduino that are half price of the original sold by lego. Will see if I try to do one myself some time. Off course mimicking the physical form factor of a Lego-compatible accelerometer-sensor would be hard, but I’ll see how good is the print from Rostock Delta Bot 3D printer that’s being built in local Hacklab.