Go Down

Topic: Balancing robot for dummies (Read 154980 times) previous topic - next topic

kas

#135
Dec 09, 2010, 07:34 am Last Edit: Dec 09, 2010, 07:46 am by kas Reason: 1
Quote
The mechanics comes from http://www.technobotsonline.com
GuzZzt, are you using T2.5x6mm Timing Belts??
please be more specifific and let me have a direct link to the hardware you actually use (pulleys, belts, shafts, bearing housings)


kas

#137
Dec 11, 2010, 08:06 am Last Edit: Dec 11, 2010, 10:10 am by kas Reason: 1
While my bot is sitting on the shelf, waiting for a new leg, I re read the all thread.  :o :o

Let me thank all the contributors:
  zalo, novice, haha97, thinkaneer, cr0sh, josev, Onions,
  Gibby623, Ro-Bot-X, granyte, killersquirel11, WanaGo,
  Patrik, wowmir, gbm, hoyeungl, T.J.L., pramlie, Jon D.,
  uncle_tom, RWehner, GuzZzt

Some have been rather silent recently, please stop by and share your new positive/negative experience.

For the silent others who helped generating the 28,000 read pages in the 2 threads, please introduce your project (with photos  :)).
Let's establish this thread as a reference for others to find both inspiration and technical information.

psychoul

Hi there kas, last week I was searching around for kalman filtering for balancing robot and I came across your thread. I found it very useful and I am gearing up for my own balancing robot.

I am not interested the details so much (i.e. the code) but I found the high-level description REALLY useful. So now that with your help I identified the building blocks of the procedure (data acquisition, smoothing, filtering, control) I am going to start developing.

Personally I lack of the mechanical potential. Not much hardware stores in my country, so everything has to be ordered through the internet which delays the whole procedure a lot!

I should let you know that I am mainly a PIC user, so I will develop for that platform :)

Anyway. Thanks for the info. I will try to be active in the discussion here.

kas

#139
Dec 12, 2010, 08:57 am Last Edit: Dec 12, 2010, 09:45 am by kas Reason: 1
Hi psychoul

thanks for joining us

You are right, the processor itself is not the main part of the project.
My initial intention was to describe the process using pseudo code only.
I wanted to avoid people to just "copy/paste" code, and make sure they understand what they are doing  ;).

You are welcome back with questions , and to share your development.

Quote
Not much hardware stores in my country, so everything has to be ordered through the internet which delays the whole procedure a lot!
Short of getting local convenient sources, most of us, in Europe, purchase in the USA (Sparkfun, Adafruit, Pololu...)
Out of curiosity, where are you from ??

psychoul

hey kas,

thanks for welcoming me :D

I am from Cyprus (where the temperature dropped under 20 degrees just yesterday...oof)

So you all guys practice the skill of patience when ordering stuff huh!? Its a very bad feeling. I am waiting for 20 days now, for some fast diodes to arrive to build the h-bridge of my robot.

I have already build the brain platform on a breadboard, and some general structure for the algorithm which allows wireless debugging and settings changes through Xbee.

For the chassis, I really liked your idea and I was able to find the materials from a local store :D. The only problem is my motors. I have these http://www.pololu.com/catalog/product/1123 cheap motors. I believe they will be able to balance the bot for tiny angle errors but not if I push the robot. What do you think?


novice

Hi psychoul,

with Arduino compatible boards being so affordable ($24) it would be much easier for you to replicate 'exactly' what kas did.

psychoul

hey novice, well I am not looking into replicating the code. After all the purpose is not to just have a balancing robot but the procedure. The "problem" that I am facing is on the mechanical part of the project, being the delays from the hardware stores. Thanks.

kas

#143
Dec 12, 2010, 06:15 pm Last Edit: Dec 12, 2010, 06:17 pm by kas Reason: 1
Quote
I am from Cyprus (where the temperature dropped under 20 degrees just yesterday...oof)
I'am jealous  >:(


Quote
The only problem is my motors. I have these http://www.pololu.com/catalog/product/1123 cheap motors. I believe they will be able to balance the bot for tiny angle errors but not if I push the robot. What do you think?
:-? :-? :-?

120:1 Mini Plastic Gearmotor:  120RPM, 80mA @4.5V (0.36W) 20 oz.in
29:1 Metal Gearmotor:  350RPM, 300mA @12V (3.6W) 110 oz.in

I am affraid it's a bit short (been there, done that with Solarbotics GM9's)
120RPM is borderline
Motors may not have enough torque for rapid Forward/backward transitions

Make your boot as light as possible (<500g)
use big wheels (>80mm)
and... let us know ;)

psychoul

Don't be jealous! Quite the opposite! We are (or I am at least!) quite bored of all the sunlight and the heat since June. Its Xmas! it should be snowing and be cold :D

Yes you are right about the motors but I am bit short on money currently so I would like to test the motors before upgrading.

Personally I am very interested in control (control theory) implementations. I found the balancing robot to be an ideal objective to play around with different control ideas, PID, fuzzy logic, adaptive etc etc. But I need to establish a good platform first before digging into those areas.

How about you. It seems you are interested about control as well. Any other interesting projects or something?

Ro-Bot-X

I have tried to use these motors: http://www.solarbotics.com/products/gm12a/ which have 169RPM free spinning and believe me they are not fast enough to balance the robot. I will get faster motors and try again. The idea was that I have built a Compact Arduino robot and wanted to see if it can balance. Perhaps using faster Pololu micro motors (40:1 has like 440 RPM) could make it work. I was extremely busy with work lately and did not make any improvements on my bot. I'll make a test bed for some a little faster motors (still not fast enough) that I already have and see how that's going to work. All my money went for other projects at the moment (multi servo robot) so this will have to wait.

psychoul

I have seen balancing robots using simple servo motors which are pretty slow compared to other DC motors. Is the motor choice so important afterall?

Onions

I am planning on building a similar robot soon, so I was wondering
where you got the wheels? (A UK supplier would be nice!)

(sorry for posting this on the wrong thread!)
My website: http://www.harryrabbit.co.uk/electronics/home.html Up and running now! (Feel free to look round!) :D

kas

Quote
How about you. It seems you are interested about control as well. Any other interesting projects or something?

I worked for a process control company for many years. We used to produce and sell DCS (Distributed Control Systems) and Plant Automation sensors with 4-20mA interface.
I started a new exciting :o :o :o project also based on control/balance.
I wont talk about it now to avoid polluting this thread  ;)


Quote
I have seen balancing robots using simple servo motors which are pretty slow compared to other DC motors. Is the motor choice so important afterall?
My first balancing robot was based upon servo motors, using a Parallax Basic Stamp processor.


http://forums.parallax.com/showthread.php?103850-Yet-another-balancing-robot&daysprune=-1

Could balance for minutes only; couldn't recover from a slight push.
I tried to adapt an IMU 5DOF sensor on this same design, but never succeeded to make it balance. :(

Look at beautifulsmall or RoObi design to understand what stability reallly means  :P
(also this  and this)

Jon D.

(Last post #115)

Allright, I'm done with my exams, and ready to make that robot balance :D

@kas
Yes, we're(me and my group members)is building the robot at school. It's a part of a "real time computer science" class. Even though it became almost more of a cybernetics project rather than a programming one. As the class is now finished, I decides I wanted to continue with the robot at home, as I would love to see it balance:)

The reason we built it so high is that it is easier to make a matheatical model of a pendulum with a high center of gravity. In theory it is also easier to balance a high center of gravity rather than a low one, as it will get a bigger momentum of inertia around the pivot point(and then fall slower). The drawback comes when the robot is out of equalibrium with a small angle. The wheels will have to travel a longer distance faster to compansate for the error, compared to if the center of gravity had been low(Think pythagoras and you will see it). This implies that the angle measurement must be accurate and fast, and this is where we believe our(now mine :P ) problem lies.

I have by the way abandonened the Fez Domino, as we had lot of problems with Visual Studio freezing when downloading the program to the Fez, and a lack of some liberary classes for byte-level operations. Pluss, my computer wouldn't download programs to the Fez at all..:P So I swappped it for an Arduino, and I'm back on track :)

However, my gyro problem continues on, as I'm trying to integrate the angle to verify that the gyro and real(accelrometer) angle got the same scale. Still, the integrated angle is about 33 - 50% of what it should be. I have connected the supply for the IMU to the 3.3V "pin" on the arduino, and also jumped it to the aref. I use the NOT op-amped output from the gyro. I use the factor 1.6(as suggested by kas in post #8) to get the read value in deg/sec.  

I attach the program I use to integrate the gyro at the end of this post, so if anyone is interested it would be great to get some feedback! I use analogpin 5 for the gyro, and the autozero is attached to analogpin 2. Just change this to match your setup. The accelromteres is not used. If you use the op-amped gyrooutput, "gyroSensitivity" should be chenged to 9.1.

I ain't got anywhere to host the files for download, so this post becomes a bit long :/

If you want to try the program, you will have to paste the different modules into different files.

Great work on your robots out there folks! :)

Jon, Norway



The "loop". This is where the integration is done:

Code: [Select]
#include "IMU.h"

IMU imu;
float angle = 0;


void setup()
{
 Serial.begin(9600);
 imu.autoZero();
 imu.getGyroOffset();
}



void loop()
{
 
 float gyro = imu.getGyro();
 angle += gyro * (112.0F/1000.0F); //The sampletime was measured with millis(), and then hardcoded.
 
 Serial.println(angle);
 delay(100);
}


The headerfile for the IMU class:

Code: [Select]
class IMU
{
 public:
 IMU();
 void autoZero();
 void getGyroOffset();
 float getGyro();
 int getAccX();
 int getAccZ();
 
 private:
 int gyroPIN;
 int accxPIN;
 int acczPIN;
 int azPIN;
 int gyroOffset;
 int accXOffset;
 int accZOffset;
 float gyroSensitivity;
 float toDegrees;
};


And the implementation for the IMU class. This is where the gyro is read, and then scaled to deg/sec:

Code: [Select]
#include "IMU.h"
#include <WProgram.h>

 
IMU::IMU()
 {
   gyroPIN = 5;
   accxPIN = 2;
   acczPIN = 4;
   azPIN = 2;
   gyroSensitivity = 2.0F;
   gyroOffset;
   accXOffset = 0;
   accZOffset = 0;
   toDegrees = 3.22F / gyroSensitivity;
   analogReference(EXTERNAL);
 }
 
 void IMU::autoZero()
 {
   digitalWrite(azPIN,LOW);
   delay(1);
   digitalWrite(azPIN,HIGH);
   delay(1);
   digitalWrite(azPIN,LOW);
   delay(1);
 }
 
 void IMU::getGyroOffset()
 {
    long biases = 0;
    for (int i = 0; i < 1000; i++)
     {
         biases += analogRead(gyroPIN);
         delay(5);
     }
     gyroOffset = (int)(biases / 1000);
   }
   
   
   float IMU::getGyro()
   {
       float gyro = (float)(analogRead(gyroPIN) - gyroOffset);
       //if ((gyro <= 2) && (gyro >= -2)) gyro = 0;
       return gyro * toDegrees;
   }

       
   int IMU::getAccX()
   {
       return (analogRead(accxPIN) - accXOffset);
   }

   int IMU::getAccZ()
   {
       return (analogRead(acczPIN) - accZOffset);
   }






Go Up