dLights, some cool LEDs for your NXT robot

Today Dexter Industries launched their latest product, an all-color LED called the dLight. I was involved in the development of the dLights so I got them early. I can also give away one set of dLights to one of my readers. More on that later. Let’s take a look at the dLights firs in this video.

I mounted three dLights underneath Agilis, one under each leg pointing to the wheel. I programmed the dLights to give a color that corresponds to the wheel speed of the particular leg. I think the result looks cool.

If you look closely to the sensor ports in the video, you’ll notice that only one is in use. This is one of the great benefits of the dLights, you can daisy chain them. So one free port is all you need to give a robot multiple lights. One set contains four dLights plus the cables to chain them.

As said, I can give away one set of dLights. If you want this set you just have to reply to this message before the first of April.

You’ll find more info about the dLights on the website of Dexter Industries.

Agilis, Speed and accuracy

In case you might wonder how fast or accurate Agilis is, here are some numbers.

Setup

• The gear ratio of the motors to the wheels is 1:2, making the wheels rotate twice as fast as the motors. (It is possible to change the gear ratio to 1:3).
• Prototype orange Rotacaster wheels. This is the hard compound. There isalso a medium compound (gray) and soft compound (black) available.
• The batteries were rechargeable NiMH, 2500 mAh batteries. These were not fully charged.
• The test surface was a clean linoleum floor.

Speed

• Reliable top speed is about 60 cm/sec, equivalent to 2.16 km/h or 1.35 mph. At this speed the robot is still accurate as there is ample margin for the PID controllers of the motors.
• Unreliable top speed is about 75 cm/sec, equivalent to 2.7 kmh or 1.68 mph. At this speed the robot is not very accurate, especially the heading.

Accuracy

• The test track is a square with sides of one meter each. During each run the test track is traveled 4 times. Making the total distance of the test track 16 meters.
• The robot finishes the test track on average within 10 cm of its starting position. Expressed as a percentage of the total distance the error is about 0.6%.
• The movement error is systematic. The robot always ends up above and to the right of the starting position.
• The robot is more accurate at slower speed and acceleration settings.

The images shows the result of the accuracy testing. For each test the robot was placed exactly on the origin (bottom left in the picture). It then traveled a square with sides of one meter for four times, making the total distance traveled 16 meters. The finish location of the robot was then marked on the floor. This test was repeated three times for a single set of settings of speed and acceleration. Three different dynamic sets were used,  speed: 50 cm/sec and  acceleration at 100 cm/sec^2, speed 50 cm/sec and acceleration at 750 cm/sec^2 and speed 30 cm/sec and acceleration 60 cm/sec^2.

 

I want to repeat the tests with a 1:3 gear ratio and also with the black Rotacaster wheels.

 

Ballbot

Remember my plan to make a ball balancing robot? Last year I set myself the goal to make a ball balancing robot. I even build the robot. Since then I wondered off my original goal and made a guardbot, Koios, from this platform. Now I am having another shot at making a balancing robot.

Programming a balancing robot is easy in theory. You just need a sensor that tells you how much the robot is tilted, most often people use a gyro for this. I use my IMU for this, so that I do not suffer from gyro drift. The tilt angle is then feeded to a PID-controller that transformes tilt to motor speed. The hard part is to tune the PID controller, it has to translate tilt into just the right amount of motor speed, too little and the robot falls of the ball, too much and the robot goes over the top and falls of on the other side of the ball. Falling of the ball damages the robot. So I had a problem, how to tune the PID controller without damaging the robot?

To be able to tune the PID-controller without damaging the robot I made a special platform. It is a large disk with a small pole in the middle pointing down Due to the pole the disk will always be tilted when lying on the ground, only when it balances perfectly on the pole it is level. Therefore this disk can be used to tune the controller.  The robot can ride off the disk, but it doesn’t fall then, it just comes on the floor with one or two wheels.  

When I tested this setup I discovered that the disk whas too smooth, the wheels didn’t have enough grip and slipped. To increase the friction I coated the surface of the disk with sillicon rubber, It is the light blue surface you see in the picture. Now I have a very “slick” surface.I only hope it lasts under the forces the NXT motors generate.But for the moment this problem is solved.

But there are other problems. One is the fact that these holonomic wheels make the robot vibrate, this affects the IMU filter, there is still some drift although it stays within certain limits. I do have prototype rotacaster wheels. The manufacturer told me that the production wheels are more round and generate less vibrations. If you are ever going to by these wheels, and they are a lot of fun, I advice you to take the black ones. They have the best grip. Anyway, I will have to tune the IMU as well.

Tuning PID controllers is difficult and very, very time consuming. There is some theory around tuning PID controllers but in the end it is mostly trial and error. Everytime I want to try a new set of parameters I’ll have to modify the program, download it to the brick, run the program and evaluate the results by watching the robot. It is hard to understand what goes wrong when you see the robot ride of the disk and make a run for the door to the staircase.

But not anymore. Kirk, one of the developers of Lejos made a very nice program that allows you to tune a running PID controller during over bluetooth. The tool is still under development so you won’t find it in Lejos 0.9.1 yet. This program is an add-on to the charting logger I often use to evaluate internals of the robot on the PC. So basicly, this program shows me what is going on in my robot and allows me to modify PID parameters on the fly. I think this is a great tool. Below is a screen shot of it.

So, now I have the robot, a test platform and a efficient tuning tool. That must mean immediate succes! Well, to be honest I don´t think so. I´m still not sure if I can get this robot to work as there are problem with weight and inertia as well. The robot weigths 998 grams. This is quite heavy, even for three powerful NXT motors. The robot is quite stiff, but there it still bends a bit under weight. This affects the IMU sensor. And I´m working on other projects as well. So in the end I think there is a bigger chance to fail than to succeed.

To be continued.

Koios, the guardbot

This time I want to introduce you to Koios the guard bot. Koios guards my house, it detects intruders and scares them away.

To perform this complicated task I have split Koios’ behavior into different subtasks and put these in a subsumption architecture.

The first task of Koios is to map its surrounding using two range sensors. These are an ultrasonic sensor for long range (<200 cm) and a Mindsensors dist sensor for accuracy on the short range (<80 cm). To map the surrounding Koios makes a full turn in place while scanning. The resulting map is what I call a circular range map. This means that the map stores the distance to the nearest obstacle for all directions (I recognize 24 directions, each 15 degrees wide). The map looks like a radar scan when plotted. This map is not permanent, it will be thrown away when Koios moves. As Koios does not try to build and maintain a more permanent map of its surrounding I did not have to deal with uncertainties about its absolute position. Therefore the mapping algorithm could be kept simple.

The second task of Koios is to find a safe spot on the map and then to move to this spot. A safe spot for Koios is a spot where Koios is surrounded by objects. A place next to a wall is good, a place in a corner is better. Koios finds a safe spot by examining the map for a place between obstacles. When the safest spot on the map is found Koios travels to this place in a straight line.
Once arrived at the new location Koios again makes a map of the surrounding. If, at second glance, the current location is safe enough then Koios will stay there. If not, it will try to find an even safer spot. This process is repeated until a location is found that is safe enough for Koios.
The video below shows Koios scanning the area and finding a safe spot. I actually had some trouble shooting the video. At first I had placed my webcam on a chair to shoot the video. But to my surprise Koios hid itself under the chair. This indeed is a very safe spot, but it was outside the frame of the video. In the end I placed the camero on my desk to shoot the clip.

When Koios has found a really safe spot it will start guarding the area. It will slowly turn in place while scanning the area again. If an obstacle is detected its location will be compared to the map. When the obstacle is already on the map it will be regarded as a part of the surrounding and ignored. If on the other hand it isn’t on the map then it must be something new and it will be treated as an intruder.
The task of guarding is rather complicated as there is always some uncertainty in both the map and the range sensor data. Suppose the map tells Koios that there is an obstacle at 150 cm and the range sensor detects an object at 145. Is this an intruder or part of the surrounding? The choice Koios makes is based on statistics. To support this kind of decision making a range map stores more information than just the range to the nearest object. It also stores statistical quantities like the number of measurements taken at the direction and the variance in measured ranges. This makes it possible to calculate the probability of an obstacle being new, an intruder, or old, part of the surrounding. If part of the surrounding the measurement is used to improve the map even further.

But if the object is an intruder Koios will home in on it! Koios will quickly run to the intruder until it is very close. I haven’t written this part of Koios’ behavior yet. So everything you read from now on is just on the drawing board.
For one thing I have not decided yet if Koios just runs blindly to the location where the intruder was detected or that it tries to maintain a lock on the intruder while homing in on it. It would be nice if Koios was able to maintain a lock. But it will also be complicated. Mayby I could use a heat sensor like some air-to-air missiles do to maintain a lock on the intruder.

Anyway, once close to the intruder Koios will scare it away using both light and sound. First it will mimic some kind of scary animal with eyes that glow in the dark while making scary noises. Then it will mimic the police using flash lights and and a siren. Then it will map its surrounding again to find a save spot and make a hasty retreat.

A new holonomic design

Last week I spent my evenings redesigning my holonomic platform. It had te be wider in order to get the center of gravity (relatively) lower. I also wanted to gear it up to make it more agile. And I wanted the brick to be better accessible, especially the USB port. Two other demands remained from Sidbot, the wheel angle should be adjustable so that the robot can be used both on a flat surface and on top of a large ball. It also had to be sturdy.

 

As it had to be sturdy I decided that the motors should be fixed to the frame. Sidbot had its motors adjustable to make the wheel angles adjustable. The wheels have to be adjustable on the new robot as well, this meant that the hinge point had to be between motor and wheels somewhere in the gear train. I tried different designs and gears but I always ended up with grinding gears. At last I ended up using a 5×7 liftarm to house part of the gear train. This effectively stopped the grinding but resulted in a very wide wheel housing as well. This is not so pretty so I’m still trying to improve this part. However, I now got a 2:1 gear ratio. With a motor speed of 120 RPM and a wheel diameter of 48 mm this gives the robot a top speed of 30 cm per second.

The frame of the robot consists of two triangles stacked vertically. The triangles are made of three 11 stud liftarms connected at the ends with 3 and 4 stud liftarms. This makes a very rigid frame, the brick lies on top of it making it easy accessible. The motors are mounted horizontally with the flat side down. This gives the robot width and also the ground space that is needed when riding on a ball. To prevent torsion between motor and frame I made a housing with L-shaped for the motors.
I used light bluish gray and dark bluish gray for the color scheme as these are the colors the motors and brick are made from. The result is a bit dull but still rather nice looking. It resembles a Starwars like vehicle. Maybe I should mount some laser guns on top.

The resulting robot does meet all my design specifications. But I have not been able to test it yet as I’m one 40 teeth gear short. I hope to get it this week.

The robot still needs a name. If you have a good suggestion you can post it in the remarks. There is a nice price for the winner a second hand Hitechnic gyro sensor. Submit your entry before November 2011.

Working on a balancing robot

As you might know from a previous post I want to put Sidbot on a ball. It must be able to balance on top of it without falling of. If it knows how to do that it must also learn to wander around. There are a number of things I must accomplish to reach this ultimate goal. Here I’ll describe what has been done and what must be done. In later posts I might zoom in on some of the tasks.

The platform

Sidbot has been built. You can see photo’s of it on previous posts. I am able to change the angle of the wheels, this enables me to adapt Sidbot to different ball sizes. I also made a spreadsheet that calculates the exact ball size needed for a given setup.

The ball

I bought a fitness ball with a diameter of 65 cm. My guess is that the bigger the ball the easier it is to balance it. Bigger balls will also be heavier and more difficult to get in motion, having more inertia. The ball also has a flat sticky surface that give grip to the wheels. It is a bit bouncy though.

The sensor

To balance on a ball Sidbot must know what is up and when it is tilting over. A lot of NXT based balancing bots measure the distance to the ground for tilt information. This technique cannot be used for Sidbot, it is a long way from the ground and the ball is in the way when looking at the ground. Therefore I will use gyro sensors to get tilt information.
I need at least two gyro’s, one to detect tilt in the y direction
(rear to front) and one to detect tilt in the x direction (left to
right). I also want to measure the rate of turn around the z axis (down to up) . This is not needed for balancing but for keeping a fixed heading when it is moving. Currently I just have the Hitechnic gyro sensor. This measures rate of turn in just one direction. Instead of buying two more of these I will built my own sensor that takes care of all three axes. This occupies less space and sensor ports, has a higher sampling rate, might be more accurate and also includes a 3 axis accelerometer. It is the IMU digital combo board from Sparkfun.
By chance this sensor fits exactly into the slide on the inside of the lego sensors. I will sacrifice my (never used) sound sensor to house it. Thus far my attempts to use this sensor with the NXT have been unsuccessful. The problem is the different voltage level of the sensor (3.3V) and the odd pull ups required by the NXT. I also lack experience with electronics. But I won’t give up that easy.

The PID controller

To balance on the ball Sidbot needs to adjust its position constantly. To do so sensory information from the gyro’s has to be translated into motor commands. For this I will use a PID controller. PID controllers are
very easy to program (that goes for number two and later) but they are hard to tune. And every time the controller fails Sidbot will hit the deck quite hard. So I want a quick way to find the optimal settings for the PID controller. My idea is to use a genetic algorithm to find the best settings. The algorithm works like this:

1. Generate 10 random PID parameters.
2. Try each of the PID parameters and measure how long
   Sidbot stays on the ball.
3. Throw away the 5 least successful parameters.
4. Duplicate the other 5 parameters but change them a little bit when duplicating.
5. Start over at point 2.

This algorithm should run until a successful set of parameters is found. During Christmas holidays I developed as small function library that implement the steps mentioned above. I tested this library to find PID values for another controller that Sidbot uses. This PID is used to keep and adjust the heading of Sidbot. In the end this worked surprisingly well. But I also found out that it is not easy to quantify the success of a PID controller. Does it have to be fast, can it overshoot the desired position or not, etc?
I expect some difficulties with this in the future. However, now I got myself a good set of PID parameters for maintaining/adjusting the heading of Sidbot.

That’s my progress thus far.

Rotacaster bot, revision 2

This time I will present some photo’s and a video of revision 2 of my rotacaster bot.  I also gave it a name: Sidbot.

There are some small changes to the first model I made. These changes all serve one purpose, I want to be able to control the vertical angle between wheel and surface. This is in preparation of my NeXT project, more on that later.

The top of the platform has been modified, it now has the same triangular shape as the base. This more regular shape gives a better platform to expand and allows for better access to the NXT buttons and screen. The motor frames no longer are fixed to the platform. They are mounted with a hinge to the bottom of the platform, on top they are attached via shock absorbers. The shock absorbers diminish vibrations. But the real reason for this setup is that it allows me to modify the length of the top mount of the motors and thus to change the between wheel and surface.

Here’s some images of the robot and a video of the robot in action.

So, why on earth do I want to change the angle between wheels and surface. Well, I want this robot to be able to balance on a ball and move around. Just as the dog in the video below. For this the rotacaster wheels need to ride the surface of the ball, and this, as we all know, is round and the wheels must be perpendicular to the surface of the ball.

 

Rotacastor bot is finished

This weekend I finished programming the Rotacaster bot. It now is a remote controlled bot that can be driven in two modes.
The first mode I call “drive” mode. In this mode the robot always faces forward while driving. When it corners the robot keeps facing in the direction of driving, just like a normal robot or car would do. In this mode the holonomic wheels don’t do much special. The only thing is that it can make very tight corners, as a matter of fact it can turn in place.
The second mode I call “strife” mode. In this mode the robot keeps facing in the same direction, no matter what direction it is going to. In this mode one can really see the holonomic drive in action. The direction the robot is facing is controlled by a gyro sensor. The driver toggles between the two modes with a joystick button.

The joystick is attached to the pc. I wrote a small program that sends joystick commands over Bluetooth to the NXT. Thanks to the fast Bluetooth implementation of robotc there is no lag that could make driving difficult. It is surprising how well the control works and how easy it is to master.

There are a few things I noticed regarding the holonomic drive. The wheels are not perfectly round, this makes the robot vibrate during movements. Also, and this I haven’t seen mentioned before, the robot is faster then a robot with normal wheels of the same diameter. This is due to the fact that the wheels are not (well not always) exactly in the driving direction. The speed of the wheels equal the y component of the speed of the robot, when there is an angle between the wheels and the driving direction this y component is less than the total speed. The principle is very much like that of a sailing vessel, it can also go faster than the wind when having a crosswind. In drive mode my robot is about 15% quicker than a comparable robot with normal wheels.

Building instructions for a rotacaster platform

In this post I’ll give some instructions and pictures that should allow you to build a compact rotacaster platform like the one you see on the picture below.

The base of the platform is made out of 3 15 M beams. They are connected in a triangular shape using 3M and 4M levers on each corner. The 3M cross axles will stick out on top. They allow you to attach a sensor to the corners when the platform is finished.

This triangle is enforced from below with a smaller triangle made of 11M beams.
As you can see from this picture there is a 9M beam placed on the smaller triangle, these are actually 2 beams placed on top of each other. When the platform is finished these beams will hold the NXT brick. You can ignore the 3M beams, they are used to hold my port splitter.

Each of the motors is held by a frame. Two are equal, but one is mirrored. Although the frames are simple it is hard for me to explain how the frames are made, but I think the pictures below will give you enough guidance.

each of the three motor frames is attached to the platform by the four connectors, the blue ones go into the corners of the smaller triangle, the black one go into the bigger triangle.

The platform is made rigid by a A-frame that interconnects the three motors on the top of the robot. This A-frame also serves as a base for sensors. The top of the A-frame is made of a 3×3 T-beam, its two sides are 13M beams and the bottom of 2 5M beams and one 9M beam. The bottom might seem overcomplicated but this way you’ll have more room to press the NXT buttons.

The last step is to add the brick to the robot. Make sure you get two connectors in the top back side of the brick. Shove the brick in from the front of the robot and connect it to the rim of two beams that rest on the smaller triangle. If all goes well the bottom of the brick will fall nicely over the 2 3M axles that make the front sensor connector.

Rotacaster wheels

For my birthday I got the Rotacaster wheels, four of them!

They are nice! A bit smaller than I expected, but the size is perfect. It gave me some new challenges. I never built a triangular robot before.
Below are the first picturesof my triangular robot. For prototype I’m rather pleased with it, it is compact, lightweight and sturdy. The only real issue with the robot is that I cannot replace the batteries without removing the NXT from the chassis.

The robot features a US-sensor, giving it a face and a front side, a Mindsensors medium range distance sensor, a Hitechnic gyro sensor and a Mindsensors accelerometer. There is a Mindsensors sensor port splitter on the bottom of the robot that it is out of view. Currently only the gyro is functional, it helps the robot to keep its orientation.

There is not much programming done yet. The only new stuff I wrote thus far deals with driving. The robot can drive in any direction. It can spin around its vertical axis and it can orientate itself in a certain direction. It can do all off this at the same time. It is really funny to look at the robot performing some of the patterns that I used for testing.
I’m not sure what kind of behaviour I will give this robot. My son wants to control it with a joystick. So that might be the first thing to implement.

The robot does not have a name yet. Any suggestions?