Self balancing robot. General novice questions

[mike_522]

Hello everyone! I'm mature electrical eng. student, trying to do my final year project. Hoping to turn this into hobby =) The task is to build autonomous self balancing robot (sonar sensors for avoiding obstacles). My budget is tight. I'd like to ask some experienced bot builders the following questions:

1. I'm planning to purchase Arduino microcontroller. I've read few forums and can't decide which one is most suitable for my project (mini, diecimila)?

2. what IMU to choose? what would be the best module to choose with regards to price/quality ratio?

3. I'd like to purchase 2 motors, but again .. which? most people who did such kind of projects had problems with backlash, i.e. their robot was oscillating all the time. some suggest to use stepper motor, but it is consuming a lot of power.

I've never done anything like it before, I would be very grateful if you could share some useful info regarding this project or simply give an advice. Thank you!

Cheers!

[Billy]

Ok you asked.  Disclaimer: I have never used a Arduino and only know about it by glancing at spec sheets.

1. I'm planning to purchase Arduino microcontroller. I've read few forums and can't decide which one is most suitable for my project (mini, diecimila)?

Choose your controller after you know what you need.  For this project you'll want enough power to do floating point math (effective PID control) and enough memory that you don't get stuck at the end having to choose which lines of code to include. You're only building one of these so don't shoot yourself in the foot by choosing a cheap one. You want to get the project completed, not write your code so cleanly that it will fit in 1k memory and use only 6 bytes of ram.

2. what IMU to choose? what would be the best module to choose with regards to price/quality ratio?

I've used servo loops with mid-resolution encoder feedback in my most of my projects so far. That means I need a way to count pulses up to about 100kHz per channel. You can get encoder decoder chips that will count for you. I have never used one though. I use CPLDs for high speed counting with a home brew SPI interface that allows true bi-directional communication and a single communication channel for all encoders.

Someday I'd like to use an eval board from Actel SmartFusion line: http://www.actel.com/products/smartfusion/default.aspx
These things seriously kick @ss. They have ARM M3 processor (32bit with plenty of flash and ram), PLD logic for high speed counting, and programmable analog sections.  Using a smart fusion eval board would be like cheating it would simplify your electronics so much. The learning curve will be steep but it will more than pay itself back with power and ease of use.  Changing your PLD logic connections are way easier than changing cabling if you need to change something. Full debug capability as well. Besides, you can put ARM experience on your resume (do you really want to spend your time getting familiar with the 8 bit platforms?). I actually have one of these eval boards but haven't used it because I have my code base built around am ARM7 from NXP. I did though take the 2 day training class. 

3. I'd like to purchase 2 motors, but again .. which? most people who did such kind of projects had problems with backlash, i.e. their robot was oscillating all the time. some suggest to use stepper motor, but it is consuming a lot of power.

You didn't say how large this was going to be, or how long it has to stay powered. You can buy very-low-backlash geared motors but you will pay through the nose for them. Probably better to get high torque (high quality) low speed DC brushed with no gearing. But I'm biased as I don't use steppers on my projects at home. At work, I only have experience with steppers in assemblies that have low positional accuracy and low bandwidth requirements. Someone else that has home experience with both types better to offer an opinion for this one. There is a real performance vs complexity issue.

[mike_522]

Thank you Billy for your reply, it's very kind of you. What I'm planning to do, is to use already made modules for my project - microcontroller, IMU (part of the project to familiarise myself with gyros, accelerometers), motor controller, etc. If I were to make an efficient microcontroller, it's a project on it's own. I want my robot to be simplistic and do the task (in style preferably  ). Now with arduino, I've read a few posts where people complain about IDE (integrated environment converts c code into avr c). I prefer AVR C. Also they overlock 16MHz standart chip for some strange reason (I refer to people who successfuly completed similar project). Do you really need higher speed for self balancing robot? Now the problem arises - which commercially available platform to choose? Where can I seek info with regards to that? Thank you very much!

[Billy]

Do you really need higher speed for self balancing robot?

You will be doing some pretty complex math. Your main filter will be using feed back on motor position, a rate sensor to detect speed of tipping, a gyro to detect angle from vertical, and input command on movement. All of that means if you limit yourself in processing power upfront, you end up with a poor filter and you're stuck with the oscillation you wanted to avoid.

But I've never done this type of project before.  Take a look that Kalman filter you will probably be using and see what it requires for processing power.

[mike_522]

You are definately right about the processing power. I've read about Kalman filter, it is complex, but I think it is possible to implement (with the help of some articles on the web of course). How to estimate how much processing power do you need?
I think it would be reasonable to break project into parts and leave Kalman filter implementation as a last stage of tuning. IMU's produce more or less noise in comparison to other modules, so I'll try to find smth with better reviews.

[Soeren]

Hi,

Have a look at these cheap but powerful (80MHz) Arduino compatible boards:
http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,892&Cat=18

[Billy]

Have a look at these cheap but powerful (80MHz) Arduino compatible boards:
http://www.digilentinc.com/Products/Catalog.cfm?NavPath=2,892&Cat=18

Those are definitely a step in the right direction. At a quick glance I don't see UARTs on the feature list. I am assuming the timers can all be configured as native PWM output with hardware match registers. The chipKIT Max32 is right one I think with USB.

[Soeren]

Hi,

[...] At a quick glance I don't see UARTs on the feature list.

I guess it's not mentioned because nobody can imagine a current controller above a ccertain size not having a serial port, but anyway, the smallest has got two HW UARTS and the largest has got six (and they can be so much more than EIA/TIA-232, they can even be used for IrDA.
Frankly, they're so brimful of peripheral features that it makes my head spin... And a regular Arduino looks crippled in comparison

I am assuming the timers can all be configured as native PWM output with hardware match registers. The chipKIT Max32 is right one I think with USB.

Yes, the Max32 has got 5 PWM's (or at least the core has, I still haven't got one myself, although I'm drooling - toggling an I/O pin at 80MHz! With a wee bit of overclocking, you could produce broadcast band FM radio on a single pin )

That said, judging from most other balancing 'bot projects, this is gross over-kill, but it's cheap and then you know it's not your hardware that limits the project.

A good start on the math part would be to make some (realistic) assumptions on the needed correction speed, as beginners tend to be somewhat "blind" to how much can actually be done in eg. 1ms.

[jkerns]

Do you really need higher speed for self balancing robot?

You will be doing some pretty complex math. Your main filter will be using feed back on motor position, a rate sensor to detect speed of tipping, a gyro to detect angle from vertical, and input command on movement. All of that means if you limit yourself in processing power upfront, you end up with a poor filter and you're stuck with the oscillation you wanted to avoid.

But I've never done this type of project before.  Take a look that Kalman filter you will probably be using and see what it requires for processing power.

The math isn't that bad. And a Kalman Filter is way overkill.

The relevent chunk of code from Hitechnic that I used for my Lego balancing robot.

Code: [Select]

//---------------------------------------------------------------------
// taskBalance
// This is the main balance task for the HTWay robot.
//
// Robot is assumed to start leaning on a wall.  The first thing it
// does is take multiple samples of the gyro sensor to establish and
// initial gyro offset.
//
// After an initial gyro offset is established, the robot backs up
// against the wall until it falls forward, when it detects the
// forward fall, it start the balance loop.
//
// The main state variables are:
// gyroAngle  This is the angle of the robot, it is the results of
//            integrating on the gyro value.
//            Units: degrees
// gyroSpeed  The value from the Gyro Sensor after offset subtracted
//            Units: degrees/second
// motorPos   This is the motor position used for balancing.
//            Note that this variable has two sources of input:
//             Change in motor position based on the sum of
//             MotorRotationCount of the two motors,
//            and,
//             forced movement based on user driving the robot.
//            Units: degrees (sum of the two motors)
// motorSpeed This is the speed of the wheels of the robot based on the
//            motor encoders.
//            Units: degrees/second (sum of the two motors)
//
// From these state variables, the power to the motors is determined
// by this linear equation:
//     power = KGYROSPEED * gyro +
//             KGYROANGLE * gyroAngle +
//             KPOS       * motorPos +
//             KSPEED     * motorSpeed;
//
task taskBalance()
{
  Follows(main);

  float gyroSpeed, gyroAngle;
  float motorSpeed;

  int power, powerLeft, powerRight;
  long tMotorPosOK;
  long cLoop = 0;

  ClearScreen();
  TextOut(0, LCD_LINE1, "HiTechnic-HTWayC");
  TextOut(0, LCD_LINE4, "Balancing");

  tMotorPosOK = CurrentTick();

  // Reset the motors to make sure we start at a zero position
  ResetRotationCount(LEFT_MOTOR);
  ResetRotationCount(RIGHT_MOTOR);

  while(true) {
     CalcInterval(cLoop++);

     GetGyroData(gyroSpeed, gyroAngle);

     GetMotorData(motorSpeed, motorPos);

     // Apply the drive control value to the motor position to get robot
     // to move.
     motorPos -= motorControlDrive * tInterval;

     // This is the main balancing equation
     power = (KGYROSPEED * gyroSpeed +               // Deg/Sec from Gyro sensor
              KGYROANGLE * gyroAngle) / ratioWheel + // Deg from integral of gyro
             KPOS       * motorPos +                 // From MotorRotaionCount of both motors
             KDRIVE     * motorControlDrive +        // To improve start/stop performance
             KSPEED     * motorSpeed;                // Motor speed in Deg/Sec

     if (abs(power) < 100)
       tMotorPosOK = CurrentTick();

     SteerControl(power, powerLeft, powerRight);

     // Apply the power values to the motors
     OnFwd(LEFT_MOTOR, powerLeft);
     OnFwd(RIGHT_MOTOR, powerRight);

     // Check if robot has fallen by detecting that motorPos is being limited
     // for an extended amount of time.
     if ((CurrentTick() - tMotorPosOK) > TIME_FALL_LIMIT) {
       break;
     }

     Wait(WAIT_TIME);
  }
  Off(MOTORS);

  TextOut(0, LCD_LINE4, "Oops... I fell");

  TextOut(0, LCD_LINE8, "tInt ms:");
  NumOut(6*8, LCD_LINE8, tInterval*1000);
}


[mike_522]

I decided to go with Arduino UNO. Also thinking of purchasing an additional shield - dual motor driver (if I won't find cheaper, better alternative). I'll try to get a reasonable response from my system first and in case of performance problems occurring, I'll go with chipKIT. This controller is definitely very cool, however I do have some concerns. I think there might be different issues with "Arduino compatibility" thing. The microcontroller is based on PIC and conversion mechanisms is a subject to mistakes and errors. Can't say for sure, never tried,  but it is this concern which led me to my conclusion. Big thanks to everyone who replied!

[mike_522]

Hello guys, I'm struggling to find 2 axis acc and 1 axis gyro IMU. Can anyone suggest where should I look for it? On sparkfun almost all products 6 DoF 

[Th232]

I doubt you'll find one because it's like like looking for a new car and ignoring those that can go 150 km/hr purely because you only need one that goes to 80  km/hr.

Just buy a 6 DoF and ignore the axes you don't need.

[mike_522]

I doubt you'll find one because it's like like looking for a new car and ignoring those that can go 150 km/hr purely because you only need one that goes to 80  km/hr.

Just buy a 6 DoF and ignore the axes you don't need.

.. seems like it. I guess I have to go with 6 DoF. Just wanted to optimize my choice and of course save some $.


What do you think of using two of them motors: http://www.pololu.com/catalog/product/1117
?

I'm thinking to connect them directly to the wheels. I think this way the responce will be less oscillatory. Problem with this is that the shaft is not long enough to accomodate an encoder, which will be self built.

Thank you for your replies!

[newInRobotics]

--> Dual Axis Acc

--> Single Axis Gyro

[newInRobotics]

What do you think of using two of them motors: http://www.pololu.com/catalog/product/1117
?

I'm thinking to connect them directly to the wheels. I think this way the responce will be less oscillatory. Problem with this is that the shaft is not long enough to accomodate an encoder, which will be self built.

Problem is that they are not going to be strong enough to move Your robot  You need some sort of gearbox to go with it. You won't be able to totally get rid of backlash, You can reduce it though by using belt drive. If You put small pulley of the gearbox output and double size pulley on the wheel shaft, you get only half of backlash than You would get when mounting wheel directly on gearbox shaft.

[mike_522]

Problem is that they are not going to be strong enough to move Your robot  You need some sort of gearbox to go with it. You won't be able to totally get rid of backlash, You can reduce it though by using belt drive. If You put small pulley of the gearbox output and double size pulley on the wheel shaft, you get only half of backlash than You would get when mounting wheel directly on gearbox shaft.

Thank you for your reply! Can you suggest a motor for this type of robot? There are more powerful, bigger, with itegrated encoder on pololu.com. However, I think it is an overkill. I want smth smaller so that there would be enough space to integrate encoder.

[newInRobotics]

To work out motor specs use formulas from Re: Choosing motors for an arduino robot to compete in robocup jnr thread.

[mike_522]

I do have an understanding of how to size a motor (for a larger scale machinery), but with this project I'm thinking going backwards, i.e. start surfing around the shops, find some quality brand, popular model and from there I can find out approx what my frame, mass, wheels should be (hoping to make my thing lightweigt). Because I'm new to robotics, I only know few shops around - pololu.com (cheapest in my view), proto-pic. There are little or no reviews on the products. Can anyone suggest good online shops or good maker of motors?