Balancing robot for dummies

After some request I decided to start up a new topic to continue the two previous topics made by @Kas. Where the discussion and support of building balancing robots can continue..

Heres the previous topics that now are read only:
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1282384853/all
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1284738418/all

All information and some source code are hosted here: Prevas Parekring

Robots built using the guide or parts of it: Prevas Parekring

All initially information of the Balancing robot for dummies was provided by @Kas and I half to tank him to inspired me to finally start building a balancing robot that I had planed to do for so long.

Thanks to Patrik for getting this subject going again. I am in dire need of help......

Ok, so I've built a couple of balancing robots but have yet to achieve 'balance'. I'll post photos and video clips later (am at work), but for now I'd like to fish for advice given I get the same problem irrespective of code/hardware changes.

I've used code from a few sources, but am currently testing KbotV1.1 which I've managed to adapt to my setup.
I've used sparkfun IMU's, but am currently using the one from gadgetgangster.
I've used Pololu 300rpm motors, but have just switched to a couple of 300rpm planetary gear motors I sourced locally in the UK (E192.12.13

So, my problem seems to be that when I have the gain high enough so that it can pick itself up to the point of low freq oscillations (overshoot) I seem to get an additional high freq oscillation which I think seems to be caused by motor/gearbox backlash. It's like the robot is bouncing off the backlash points.
I have fitted an LED on my robot which basically will be on when driving forward and off when driving backwards......this LED will flash rapidly. I also scoped the PWM output and you can see the 'chatter' in the output.

It's almost as though the gyro/accel signal is noisy.

So, I raised the robot off the ground and have it sitting perfectly vertical and very stable/fixed. If I leave the main loop scan at 9mS then the chatter is noticeable, but the more I reduce it the better it gets.

So believe it or not I overclocked my Arduino to 28mHz and got the main loop down to less than 2mS and it's better but still there.

No matter what code I use (i've tried a good few from various sources and including writing my own) the problem is always the same. I've played with the PID settings, I've replaced the PID code with others I've found.

I've written my own interrupt routines to fix the scan time of all the subroutines not just the main loop.

I've tried different sized wheels, weighted the robot differently, moved the IMU central to the axle.....everything.

I guess a video will speak a million words, so I'll upload one tonight.....for now here's where my test code lives:-

http://www.ianjohnston.com/content/images/stories/IanJ/Segway/Code/

Ian.

Hi,

Here's some pictures and video clips of my Bot.

PID settings used to demonstrate 'chattering' problem:-

#define GUARD_GAIN 5.0
float K = 1.4;
int Kp = 6;
int Ki = 1;
int Kd = 1;

These motors are real quiet, so the chattering you are hearing is the problem.....and you can see the chattering is in sync with the LED on my bot that signifies motor direction. You can also see/hear that when I pick the bot up and move it back and forth and also completely still that there is no chattering, it's only when the bot is on the ground and the control loop is complete that it starts, and obviously the higher Kp the bigger the chattering.
I've tried other PID loops as well as all sorts of settings to no avail. It's also worse on a hard surface hence the large soft tyres and carpet test.

Any ideas?

PS. I haven't tried the encoders on the motors yet.

Update:.......Have been playing with the code and I'm beginning to think my Bot is too heavy for motors that don't like low voltages. Even without any load my motors, which have a range of 0 - 255 (127 is stop), need to see 122 or 123 before they really start to move and even then any load at all and they won't move. So, the net result is the oscillation I have been seeing.
Hmmmmmmm!!!

PHOTOS:-

VIDEOS:-

http://vimeo.com/23223786

http://vimeo.com/23226869

http://vimeo.com/23227180

http://vimeo.com/23227853

http://vimeo.com/23227763

Ian.

I haven't had the time to look at your code yet but it sounds like your having the same problems that I have..

I have no problem getting my robot to balance but it's shaking a lot and I think it's manly to the backlash.
You can see it in the video blow if you look closely you will see the shaking..

I have recently seen that I may have a problem with my IMU which the zero point is moving after a will and that I also think is do to the shaking and mess up the kalman filter..

My next step is to change the motors to the stepper motors below:
#1200 Stepper Motor: Unipolar/Bipolar, 200 Steps/Rev, 42x48mm, 4V, 1200mA
#1182 A4988 Stepper Motor Driver Carrier

Word of caution on stepper motors, they are significant power drains, essentially drawing peak current at all times (unless completely unpowered, in which case they have effectively zero holding torque). In a more stable rover-like platform where you could completely cut power when not moving, they may not be too bad, but in a balancing bot where the motors have to be driven constantly, battery life will be significantly diminished with stepper motors.

@jraskell
I agree that it will significantly lower the battery life but It would be nice to see the bot perform without the backlash that I currently have with my DC-motors..

Great to see another balancing project.
Mine is still a collection of pieces waiting for a useless Australian supplier of driver boards to even reply to an email....anyway.
Yes i know there are lots of other suppliers, but not for motor currents above 2 Amps, which if theu don't work out will be suitable for a second purpose.

If I recall correctly, I read somewhere (it might be from Kaz original postings, or a sedgway application) that someone had backlash issues, and it turned out to be the motor controller.
Not sure what the exact problem was (or if my memory is right), but my guess would be the amount of zero time, so that the driver devices didn't get fried when going from forward to reverse.
It could be that they went to faster motors (less gearing) with a better controller as well, and found the controller was the problem. :~

You should be able to measure the backlash by shorting the motor, and seeing how much rotation there is before you meet resistance.

I would agree with the stepper drain issue. A DC motor with a short across it, applies significant braking force, with no power drain.

Good luck and keep up the great topic.

Mark

Hi all,

Having played with it again, I think there is 1 significant issue which cause chatter and a failure to balance properly with my bot. Please also bear in mind I have 2off completely different software designs but which both give the same problems at the end of the day.

It seems to me that these DC motors don't have much torque at the very low voltages being applied around the balance point. This means it takes a good few counts to get the motor going, and when it does get going it flies off. Thats why when I pick my bot up and move it back and forth there is ZERO chatter......but give it even the slightest load and the low torque suppresses the motor movement.

To compound this, I remember my first bot used RC servos, and I had no chatter and it balanced much better.

So, I think I'll need to hook up the encoders on the motors, but in some intelligent kind of way, i.e. in some kind of feedback loop so that the Arduino applies motor power and will be able to tell when and if the correct speed/movement has been applied.
I have seen encoders used in some balancing robot PID loops, but I'm not sure that's good enough.......I need to get a better understanding..........

My ultimate goal is a home-built Segway.......and I'm always wondering whether the wheelchair motors etc that I plan to use will have the same low torque problem around the balance point.....or whether this problem is limited to my small bot only......hmmmmm!

Ian.

Hi all,

this is my bot...made using as a "trace" the Kas guide.. and spending a lot of time (more ore less 6 months).

on the third month the bot was running, then an inverse current from the motor driver burned Imu, Arduino and the sonar..

I am now using the 5dof Sparkfun analog Imu..anyway I also tried the Fabio Varesano digital FreeImu.

The last version uses a sonar that make the bot turn when an obstacle is <=25 cm close....

Motors are the Pololu 29:1 Metal Gearmotor 37Dx52L mm with 64 CPR Encoder (Pololu - 30:1 Metal Gearmotor 37Dx52L mm 12V with 64 CPR Encoder (No End Cap));

It works because:

  1. the new wheel ( http://www.robot-italy.com/product_info.php?cPath=7_158&products_id=1525) are much more heavvy than the previous (http://www.pololu.com/catalog/product/1435);

  2. the bot is much smoller than previous version (now 25 cm).

With our motors the bot has to be small and "not high" other wise you'll never correct a tilt with a K*velocity of motors, velocity of motors will only generate a translation of the bot that will compensate only partially the tilt.

With heavy wheel and a toll bot K*velocity will compensate the tilt.

My way:

  1. I did find (making 10 tries and then evaluating an average) the "zero" values of the 2 Acc and the Gyro. Then You have to use always this 3 zero values..your tuning will not depend any more on the starting position.

  2. I manually found the "real" setPoint (the one that makes the mass center cross the motor line).

  3. I used a potentiometer to find the right set of PID values;

4)You'll find Kp working with the potentiometer as the values that make the bot oscillating (it will jitter because of backslash...)

  1. Then I used a low Pi and found Kd using the potentiometer as the values that make the stop oscillating...be careful if you use a bigger Kd the bot will be "nervous"..

  2. Kpwheel will be set as enough to make to bot turn back, but it will create again oscillation (non on the tilt but on the position);

  3. Kdwheel will be set as the values that make the stop oscillating on the position.. be careful if you use a bigger value the bot will be "nervous"..

bye,

danilo

Great info......looks like I need to play with Kasbot V2 and the encoders.

Ian.

Ian
I'm interested in the wheelchair motors bit, as that's exactly what I had planned.
Only problem is the speed.
Mine are about 60rpm, but bigger wheel dia (not normal chair size)

I read here Trevor Blackwell he had issues until he went to a new controller, and bigger wheel.

prof_jazz
Now that yours balances, any chance you could give the wheel rotation, and diameter, so we can check the speed.?

cheers
Mark

My motors are Jazzy 1121 wheelchair motors (rated at 5mph with 14" wheels which I work out at 120rpm).

Probably gonna use a Sabertooth 25A Dual Motor Driver.......once I can get the proper spec for my motors.

Ian

Thanks Ian
I have ordered one of these controllers to try http://secure.oatleyelectronics.com//product_info.php?cPath=94&products_id=206, however getting across the water has been an exercise in frustration.

If they ever get here, It wil be interesting to see how they go, as they should be capable of 40Amps at 24v.

I've just checked mine again and the motor are english and the sticker says 113rpm 7.5 Amps 24v.
The wheels are 12.5 inches, so if my maths is right at 100% it should be 4.19mph.

in reality the segway and all balancers only drive at 80% full speed, so its more like 3.3mph for mine.
Since its a balancer, not a rideon, it should be okay.

I have riden one of the newer segeways. it had the offroad tyres, and you moved the handlebar sideways to steer left or right. It was very natural, and even the wife had the hang of it within a couple of minutes.

Mark

@prof_jazz

Nice progress I will also try with the bigger and heavier tiers. I'm currently rebuilding the frame to get It a little higher and get space for a 4x20 LCD and some potentiometers. Then I will remove all the the jumper cables and the breadboard..

I don't know if you had any musics in your youtube clip but it's blocked in Sweden do to Sony Music Entertainment (SME). If you have music in the clip could you post another without music?

@ MarkB:

i posted the links of my motors and my wheels, you should read all the tech. specifications...please tell me if you need something else..

Here is a link without music:

prof_jazz

Thanks for that. I hadn't quite followed the links for some reason, when I asked.

I'm playing a waiting game on my driver boards before even contemplating a start.

Mind you it allows me to finsih some of the other projects that are started, but not finished.

mark

@ IanJohnston

why don't You try to put the battery (that should be heavy) as close as possible to the ground?
Make the Bot lower as you can...

@ prof_jazz
I had read that weight should be at the top......however, worth another try down below I guess.

Made some progress tonight however. I tidied up my power wiring after scoping the signals/supply and noticed that my speed controller is inducing noise onto the 0vdc and thus affecting everything, including the IMU.
I'll probably fit an isolating DC-DC conv this weekend so I can run two independant batteries.....downside is they'll have to come together at the Arduino.......but it should help.

The other thing I did.......and wait till you hear this one.......was overclock the Arduino to 28mHz (from original 16), and it's a vast improvement at first testing.
Actually, it runs at 32mHz also, but crashes every now & then.

I was using Kasbot 1 code mainly up till now and have started to migrate the V2 code over so I can get the encoders hooked up.....however, I'm not that convinced they are best placed in the PID calcs. I'm thinking maybe they could be used elsewhere, or possibly additionally elsewhere covering a new function. Hmmmmm!

My current test code is here:-
http://www.ianjohnston.com/content/images/stories/IanJ/Segway/Code/Segway_K_BotV2_IJ_1/

To do:-

  • Play with 10-bit PWM rather than 8-bit.
  • Optimize for 28mHz Arduino.
  • Encoders
  • DC-DC conv.
  • Vref.

So, I'm a lot closer to achieving successful balancing............I think most of my problem all along was noise!

Ian.

Check out the new maple out Maple - DEV-10664 - SparkFun Electronics.

12-bit ADC resolution (ADC)
15 PWM pins at 16-bit resolution (PWM)

Should improve the resolution of the angle reading and the motor output a lot..

PWM on pins 9 and 10 (Timer1) is 16 bit, I see no problem from the resolution there, just make sure the code writes an int not a byte. SparkFun also sells a Digital 6DOF IMU unit that has a 3 axis gyro with a built in 16 bit analog converter and a 3 axis accelerometer with a built in 13 bit analog converter and uses a fast I2C interface (400kHz). I got one, but I have no time to work on this until fall.

On the other hand, the Maple brings out more computing power, but I'm not sure the bot really needs it, unless you're trying to do all in one balancing, driving, mapping, obstacle avoiding and other stuff. I would use one Arduino (or compatible) for balancing and another one (or more) for the rest of the stuff. Why? Because these micros don't have multitasking capabilities and multiple things need to run at the same time, so having multiple micros running different code at the same time solves this problem without programming tricks that might or might not work. The I2C interface is perfect for communications between modules themselves and with the sensors, plus, more modules can read data from the same sensor.