Protobot - First robot project

Let's Make Robots Robots
1

Updated with a 2nd video! Code is now uptodate and can be found at: code.google.com/protobot.

Introduction

This project is all about details. If you think its a waste of time to sit all night debugging a sensor to get that correct reading you want. Well, then this project just isn't for you. I began working on my two wheeled balance robot in the beginning of June – and the 14th of August was the first time I managed to make my robot balance on its own for a time over 10seconds. If I had to guess I'd say I've used around 150 hours on the project, but that estimate is probably completely wrong. During the time I've worked on the robot I've also had other things to do and I've waited for parts ordered online, so the timespan isn't representative for how long it takes to build one of these things. Nevertheless, on a project where details matter its extremely important to understand fully what is going on, to understand why the robot behaves in a certain way. Otherwise debugging will prove to be very difficult and time consuming. Therefore, I'm certain of that taking your time will prove to be more meaningful, rather then rushing ahead and skipping the basics. Eventually, this has certainly proved to be one damn learning full process and I'm proud to say my first robot was a two-wheeled-balance-bot.

Parts & Construction

This is a list elementary the parts I've used for making my bot and some commenting on how.

  • Arduino is the Microcontoller I've used. If I had been more experienced I'd probably just have programmed an AVR-chip, but since this was my first physical computing project the Arduino proved to be a very good developing platform.The Arduino IDE is abit simple and may lack some common futures, but it makes a good starting point. Changing to something different can prove difficult and confusing.

  • Sparkfun's IMU Board - ADXL320/ADXRS401 board including the ADXRS401 gyroscope and the ADXL320 from Analog Devices work as sensors on my robot. The gyroscope measures angular velocity while the accelerometer is able to very accurately detect tilt to a fraction of a degree. It is very important to pay close attention to these sensors. 1° degree is enough to make your robot tip over and loose balance. With the help of TeleFox I was able to learn how to use this hardware.

  • 35:1 Mini Metal Gearmotor from Pololu are used to drive my robot. These are very good 6v motors. They are stable, quick and built with a quality gear. In v.2 of my balance bot I will change for bigger motors, though. As they are just barely strong/fast enough to do the job. This is of course due to the size and weight of the robot, not due to the motors.

  • Battery;

    • 1000 m:Ah 7.4V Flightmax high discharge Li-Po battery is currently used to fuel the motors. I plan to use a 2200 m:Ah version, but I don't have the correct plug yet. Until recently I did use a 6.0V 2300 m:Ah Ni-Mh pack, but the extra volt and amp was needed to give the motors enough punch.

    • 2300 m:Ah 6.0V Ni-Mh's are used to power the board and sensors. This is of course not good solution as the Arduino should have around 9V.

  • Pololu Qik 2s9v1 Dual Serial Motor Controller was used until recently when I by a mistake sent some high volt in the wrong channel and partly destroyed the chip. As a result I built a simple motor driver(from memory :p) using two SN754410NE H-bridge connected in parallel. This is providing bidirectional control over two motors using four PWM Pins on the Arduino and the combined chips have a 2A rating.

  • Wheels consist of two very light foam wheels used on RC airplanes. These have 7cm diameter and replaced some smaller Pololu wheels I was using earlier. The bigger diameter gives me a nice balance between force-at-wheels and speed.

  • Other parts: A decent amount of basic electronic components; potentiometers, resistors, capacitors, LEDs and lot of wires. A breadboard and some Polymorph also came in handy. Construction was made of thin sheets of Plexiglas and some nuts & bolts.

Future upgrades/v2 include: 19v Pittman Motors, 2x packs of 11.1v Li-Po batteries, new motor controller, remove Arduino and replace with ATmel chip to create a more permanent solution. Also; distance sensors(Maxbotix LV-EZ1 and a Sharp short range IR sensor.), xbee modules for remote control are in the planning.

Theory

The theory of balance is both simple and advanced. The idea is that we get some input from a sensor, we then run the input through a formula which calculates the tilt. Based on amount of tilt we send a amount of volt to the motors.

Knowing the angle of the robot lets us calculate torque applied by gravity using the following formula; mass * length * gravity * sin(degree) = Torque in Newton meters. Knowing this gives an indication of what kind of torque we need to counter the falling robot. So torque applied [Force at wheels * length * cos(degrees)] has to be bigger than the torque applied by gravity to overcome it [mass * gravity * length * sin(degrees)].

That was the simple part. What makes this process of balancing all hard and time consuming is the problem with reality and our model in general. Getting an exact point of balance using one sensor might not be as easy as first thought, and therefor there is no simple way of knowing the tilt. Combining several sensors to get exact readings of the robots position relative to earth is essential. This adds more theory or mathematics to the project through the use of filters. Filters combine two or more sensors, remove spikes caused by electronic noise, and as a result you'll get an estimate on a angle. The correctness of the estimate is on one side affected by the hardware in use – and on the other of the filter. One common and relatively advanced way of doing this is by the use of the Kalman filter. Already used on the in the 1960's on the Apollo, the Kalman filter has proven to be good both for space shuttles and balancing robots. You could also combine a couple sensors and calculate the average and call it a filter. This would probably be better then just relaying on one input, but not as good as more advanced options. As a final result is the stability of your platform.

On my robot I've implemented one version of the Kalman filter, which resulted in a very stable platform with an awful drift. I've used a large extent of time trying to find the cause of this without luck. So in the current codebase I'm using one part of the Kalman predictions for my angular velocity sensor and a unfiltered accelerometer for tilt calculations. These inputs are then combined in a PID, resulting in a platform which in its current state can balance for around 3 minutes. After that time irregularity in voltage will cause the platform to start drift. But that is in reality a hardware issue.



Issues and progress

  • I've tested my sensors and learned how to use them.
  • I've tested DC motors and learned how not to use them. Result gave alot of new knowledge made me order some different motors.
  • I've tested the IMU board and learned slowly how to use it. I've realized that this is the place where I lack the most knowledge and where I'll have to invest the most of my time for understanding how it works.
  • I've built a small robot while testing sensors and motors using polymorph as a chassie, but it reminds me of the ugly duckling so I wasn't very interested creating a robot project for it. It didn't really deserve the attention. I'll add a photo just for the fun of it, though. Robot is now taken apart for parts (22/6-09).
  • I've built the chassie for my first robot. Added about 50% of the parts - and 20% of the wires :p
  1. Do more research related to the filtering the data from the accelerometer and the gyroscope. I'll create a list of links for people interested in reading more at the end of this post.
  2. Find a easy way to build the robot platform. I've seen its popular to use a simple Plexiglas solution which indeed look pretty nice as well. DONE (22/6-09)
  3. Update this page with my progress on the robot.
  4. Test the motor controller with my new motors (22/6-09)
  5. Fix drifting error. This is probably created due to acceleration and no velocity checks.

  • 14th of August was the first time the robot balanced for more then 10 sec. Shortly after it broke the 1-2-3min mark.

  • 16th of August; found issues related to power supply. Irregularity in volt due to long power cables and dropping volt after time of use causes the robot to drift. One problem is that the zero gravity spot on the accelerometer will fall. Solution is to rework the cables and use bigger batteries to be able to provide a stable volt over time. And try to update those kind of sensor related details dynamically and not hardcoded.

UPDATE Monday June 22:

This is more of picture update. I havent had much time lately to do build. work work work ... boring. But yesterday I had a few hours to create some parts and this morning i was able to assemble a prototype. I decided to go with the plexiglas solution. Found some fairly cheap A4 sized plates at a local store. My general idea is that the plates are assembled in layers - and adjusted with nuts. This makes it fairly flexible and easy to take apart if needed. Lets look at some pictures:

plexiplates_01.jpg345×500

This is after the first time I assembled the structure just to see if the parts fit. As you can see I have it all put together in a very simple way.

Here is after i polished the parts with some sandpaper to get a smooth surface. Adds a cool effect to it instead of the glossy Plexiglas which will get scratched sooner or later anyway. On the left side you can also see my custom motor mounts made out of Polymorph. And the right corner shows my morning coffee .. mhm :)

protobot_with_toys.jpg332×500

The assembled protobot with with its parts in front.

Just a close up of the sensor and potentiometer. Will be interesting to start testing the sensor when assembled on the robot. But still got some things that have to be done first. Thanks for watching.

UPDATE Tuesday June 23:

Small update this time. Just adding a few photos with the assembled bot and all the wiring. Put the batteries at the bottom of the bot so the motors get a easier job adjusting the balance. Now its time to start the programming :)

assembled_ii.jpg1793×2669

UPDATE 16. July

God, almost a month has passed since the last update here. Not good. I've been busy finding a new apartment, enjoying the norwegian summer, and working of course. Neither the less I've done some progress on this robot. It's going forward, slowly, maybe, but still - forward.

This time I've decided to add a very bad video. I think it's probably a good idea to show something in live motion. Since I dont have a video camera I've used the built in webcam from my MSI Wind. Now that is crappy, but wanted to add this video to show some drifting issue I've had on my robot.

Anyway, lets see what I've done since last time I published here.

  • I've programmed the robot a few times with different codes, approaches, solutions. The code I'm using now, and which I will continue to work on, is heavily borrowed of open source implementation of similar projects - and especially when it comes to the Kalman filter. This is commented in detail in the source code of the project avilible at code.googel.com/protobot. I've tried to add easy to read comments the source where needed so it should be fairly understandable even for the the beginner, but its all still abit messy.
  • I've used alot of time to understand how the different concepts of physics relate to each other to be able to create a stable platform. Yes, I know its drifting and falling over after a few seconds, but the robot seems pretty stable. And I'm sure, once I get a good balance algorithm going, it will be stable.
  • There have also been some hardware changes. Due to the small wheels I had earlier, and the rather low RPM from the motors, I was having a hard time gaining enough speed to adjust my balance. So yesterday I bought some RC flight wheels with a bigger diameter and glued them on some pololu wheels so mounting them to the mounting axel should be easier. Bigger radius on wheels give me more speed (thus less force). As the motors I got had a good torque(0.002548 kilogram meter torque, to be exact). It was no problem to add bigger wheels.

So, thats about it. Think I add some more details and comments tomorrow, as now I'm to tired to think or wright anything sensible.

Reference and general links to similar projects and resources for the theory.

17th of August

Tried to update this post abit, will add another video once its uploaded. One month without internet and counting is forcing me to use internet cafees for this. Slow uploading ...

18th of August

Faster uploading at the University let me add another video. This one is abit longer and you can see the robot keep balance for good over a minute before it drives into my sofa :p I did also update the codebase on Googlecode for those of you who are interested. It's really nothing special to see, but gives an idea what lies behind(link: code.google.com/protobot).

19th of August

Added a high resolution photo showing the robot from new angles. I have also ordered a great deal of parts from a sweedish supplier(electrokit.se) for version nr.2. I did do some late night research regarding sensors for my second bot, but have not come to a final conclusion. I was thinking of buying latest ADXRS614 with 50'degrees/s maximum rate gyro together with a ADXL213AE +/-1.2g accelerometer. Both sensors focus on high precision, rather then wide range. The question is if they are too sensetive for a robot like this. Suggestions are very welcome.

Theory

Similar projects

Balance

  • Actuators / output devices: 35:1 Mini Metal Gearmotor
  • Control method: autonomous
  • CPU: Arduino Duemilanove
  • Operating system: Linux
  • Power source: 7.4 Li-Po and 6.0V Ni-Mh
  • Programming language: C
  • Sensors / input devices: IMU Board - ADXL320/ADXRS401
  • Target environment: indoor
This is a companion discussion topic for the original entry at https://community.robotshop.com/robots/show/protobot-first-robot-project
2

Now things are starting to
Now things are starting to get real interesting.
Kalman filters seem to be a good all-round choice for balancing bots and the like. A 4th year team in my engineering classes at uni used the Kalman method to great effect; their bot was pretty average, but the software was quite impressive.

3

There are different filters

There are different filters to chose from and the Kalman method probably isn’t the lightest for the processor, but it seems to be a popular choice for predicting the outcome of our sensors. The complementary filter seems to have a lighter footprint for example, but I haven’t really looked into it. Kalman prediction’s seems to give rather good results so I’ll try to implement that first - and if I’m not happy I’ll look elsewhere.

Sadly I’m working much these days and don’t have much spare time for robotics, but I’m trying to get a hour here and there. And hopefully I’ll get a working copy of this little guy soon™. But I’m also still waiting for motors and wheels to arrive and you never know how long thats going to take, shipping overseas

4

Plexiglass is ok. For rigity
Plexiglass is ok. For rigity and strength you can get cutting board material [Plastic of course]. The best is ABS plastic. Most large cities have an industrial park and you can find a plastic shop and buy scraps cheap. My plastic cost me only 25 USD for the scraps. I lucked out. Someone commissioned a box of ABS and never picked it up so it was on the scrap pile.

5

I’ve started working on a

I’ve started working on a Plexiglas solution. Got some A4 sized plates at a local Clas Ohlson store. Its easy to saw in and drill holes for nuts & bolts. I’m also using some polymorph to molder parts. I love polymorph, It’s so easy to work with. My design will be quiet straight forward; could call it a staircase design connected together with four 20cm long bolts. It will then be possible to adjust the width between each staircase simply by adjusting the nuts. Atm it looks like this will work out fine so I think i’ll stick with this plan. Thanks for the tips on the ABS material, though.

||
||
-|____|-

 

6

i love sandwitch plexygrass

i love sandwitch plexygrass robots

in the past i have tryed a cheap balancing robot, it was made with picaxe 08 and ir diode/photodiode to detect angle…

of course it become the ultimate abort :slight_smile:

you knowledge base is ok, i am sure you robot will work perfectly, have fun!!!

7

Im not sure about the

Im not sure about the picaxe. Have seen some code from those microcontrollers and after that i totoally ignored them. Probably easier for people without programming skills, but in it didnt appeal to me.

There is a very smart and cheap way to make a balancing robot if you are interested. But in the end you’ll have to add some money to get a good result on this kind of project i think. Of course I dont know since I havent finished it yet, but thats what I assume at least.

Thanks for the nice comment and heads up. You’re robots are very innovativ btw. Like the simple and fun design.

8

Pretty cool
I think balancing robots are pretty cool. Not yet ambitious enough to build one myself, though.

9

Hi, Ericski

Hi again, Eric.

Today I’ve come to the point where I tested your Arduino library for the Qik Motor Controller. You’ve done some nice work there and it has made the job of controlling the motors very easy. Find it strange you havent received more comments on it. I did see Pololu linked it on their website - so people will probably start using it with this combination of microcontroller and motor controllers.

Of course I managed to waste a good hour because of a small misunderstanding. Wasnt able to find the mistake 'couse I had done everything right after my own logic. Then I read this on the Pololu forums:

On the qik, the serial pins are labeled from the qik’s perspective, so RX on the qik is the line on which it expects its serial input. Therefore, you should connect TX on your serial adapter to RX on the qik and RX on your serial adapter to TX on the qik.

When I realised the simplicity of my mistake I had to laugh a bit. Almost as much as when I, earlier today, plugged + against + on two battery packs by mistake, but thats a different story :slight_smile:

Enough rambling. Just wanted to say thanks for the work on the library and for sharing it. I’m not sure if it will balance in the end, but it will give me something to do for this summer.

10

Thanks

I Made the same mistake so I’ll document that better. It is an easy mistake to make. I might try to better encapsulate the NewSoftSerial library for what I think will be the standard deployment (only one NewSoftSerial in use.)

Glad it is working for you. The code base has a few more of the controller’s features implemented but I’m not sure how useful they are (such as changing the PWM frequency.)

Looking forward to watching your progress.

11

With regard to the drifting

With regard to the drifting issue, are the motors running at full power? When the bot is tilted at an angle and drifting along, the lower half of the platform needs to be able to ‘overtake’ the upper half in order to regain balance. If the motors can’t be driven any harder then you’ll need either:
• More ground speed (faster motors or larger wheels).
• A faster control response, so the bot can correct the tilt before the angle becomes too great.

If you’re feeling like a challenge it could be time to try to master the gyro module, the data from that would allow you to speed up the controller response somewhat.

It doesn’t look like you’re far off having it running smoothly, nice work man!

12

Hello, Telefox.I dont think

Hello, Telefox.

I dont think its an issue of running at full power, or not the main issue. I believe its an issue of the following; the robot knows how to adjust balance when standing still, but once it gains speed(acceleration) it adjusts to little compared to velocity. Of course you would suggest to just add rate of gyro(angular velocity) to the balanace torque calculations, but I havent managed to get a stable version. What happens is my robot doesnt know it goes at high speed, nor does it always know its not adjusted. If I had a better cam I could have shown exacly how it is. Would make thing kind of easier.

If we look at the code we can see that I’m using the Kalman filter to combine the sensors; accelerometer x-axis and gyroscope. As a byproduct of computing the angle, we also have an ubiased angular rate available. With these readings, theoretically, I should be able to balance my platform. You can look at the balance torque calculations in the code if interested.

Regarding the comment on wheel size, I did some calculations and I think i’m roughly at the maximum diameter related to weight and torque now. If I add bigger wheels my motor torque will be to low compared to what is needed at the force on lever arm(force at wheels). You can look at some of my notes regarding to this, here.

I think I’ll try to figure out a better balance torque calculation, and if that doesnt work out I’ll look at the alternative of getting bigger motors(more rpm and torque) and some wheel encoders to simplify the job. The latter I’m planning on getting sooner or later anyway.

Looking forward to see you build something nice and shiny soon, Telefox :slight_smile:

13

Ah, my bad, thought you were

Ah, my bad, thought you were just using deadband motor control instead of PWM. Thanks for posting the code, that clears up a lot (like where the pot comes in =D).
Does the platform always tend to drift in the same direction?
In your torque/force calcs, what does 0.22L correspond to?

Hopefully I’ll have a robot worth posting soon, I’ve been working on a bit of an obscure project since I moved house but I keep getting distracted with requests. Once I finish project “stungun suitcase” with one of my friends it’s back on the robot train for me.

14

This comes out a very cool

This comes out a very cool project! Very well documented and nice to follow the progress. I learned a lot!

Hope you figure out how to stabilize it :wink:

15

Thanks for the comment,

Thanks for the comment, guibot.

I think learning is often a process of collaborating or at least expressing what you do. It’s easier to understand something yourself if you can explain it. That might sound stupid, but for me its often essential. So documenting the progress is in this case also a part of my learning experience. Which is nice :slight_smile: Of course, sharing will help others as well. I’m very glad to hear you learned a lot. That makes me happy!

16

My link to the code in the

My link to the code in the update I wrote was probably a bit hard to notice. So i’ll take a note on that and try to structurize my updates better next time. The pot is used different plazes all the time. So mostly for tuning the constantants for debugging. It’s very primitive, but I dont have a 11 pins spare to hook up my LCD - and I dont have the breakboard to connect it via serial.

My platform drifts in the direction its falling. If gravity for some reason adds up on the left side, it will slowly drift that way. When the platform gains some speed that adds to my accelerometer and it thinks its aligned, even though it might tilt at 1 degree. This will cause the robot to drift more and speed up more, and eventually fall over. I’ll try to post a more detailed update before i go to work today.

0.22L is just referring to 22Cm or 0.22 meters. 0.22L is probably not the right way to express this. This isnt used in the current calculations anyway. To be honest, i could have compromized the entire program down to 50~ lines, its just due to ALOT of commenting and also alot of commenting on things I’m not using in its current state, which makes the code big. This makes it easier for myself to work on problems - as I have much of my reference material all in the comments. But I see it can be confusing for you to read.

Not sure what you want with a stungun suitcase, but well, thats your problem :stuck_out_tongue:

17

That is not stupid at all,

That is not stupid at all, documenting the process is good for the one who creates it and for the others.
I feel that some of my projects would be more rich if I have documented them as you did… sometimes I’m lazy I guess :slight_smile:

18

thats one well built
thats one well built balancing robot!

19

Hey Simon, great to see the
Hey Simon, great to see the progress you’ve made since the last big update! Protobot’s motion is a lot smoother than the average DIY balance bot, well done.
So it was the power cable resistance voltage drop that was throwing some of your readings off? Go figure, the simplest problems are always the easiest to overlook.

20

Hello, Telefox.I’m sorry

Hello, Telefox.

I’m sorry about the lack of updates, but I just havent had the possibility to run down to the public library or local coffee shop each time I found something new. In addition I did move to a new appartment as well. Otherwise I would have kept the public abit more up to date :slight_smile:

Recently I noticed the power cables are causing an awful drop - so I will need to find a better way of providing sensors with fuel. The problem is for example if my 3.3v reference drops to 3.2v or i my 5v drops to 4.65v.This helped me explain drift after a certain amount of time, but wasnt the cause of my troubles getting the platform up balance. That was more of a combination of code/batteries/weigth distribution. Nevertheless, I’m still looking for a way of understanding how to fix the drift I have when soley using the Kalman predictions for my point of balance, since the final platform using the Kalman filter will be 3x times more stable then what i have now(I think).

Kalman or not, my first plan will be to build version nr.2 within a month maybe. Depends on how quick parts arrive etc. and how much trouble i have programming my AVR. Its abit limited what I can improve on my current bot without building a new frame.