Need some general feedback on self-balancing robots.

Projects General Guidance
1

Am going to embark on this oft-travelled journey and obviously there are many resources out there to help me along my way.

However, i just wanted to get feedback on several assumptions which i have in making decisions for the project.

  1. Are encoders absolutely necessary ?
  • i have seen some robots that can return to the exact same position after it has been pushed/displaced from the original position, but if one is only looking to get back to an upright position (and eventually stay still) - then an IMU is the "only" necessary sensor-unit, right ?

  1. The motors will always be on - in other words, even at stand-still, there will be minute movements going on which might not even be visible as wheel movement - this will obviously be drawing current all the time.

  2. As far as size goes, the smaller the robot, the more difficult it will be due to sensitivity of the readings required, am i correct in that assumption ? i have been plotting raw analogRead() data from a MMA7361 (from DFRobot) which has been "simplified" to only power-lines and data pinout, plus a DIP switch for choosing 1.5g or 6g settings - what is strange (or am i misunderstanding the principles) is that the 'noise' from the 6g setting is much smaller - meaning the graph plot range is much tighter than when on the 1.5g setting.

Eventually though, i will be using an Uno and MPU-6050 since that has 6xDOF and a lot more examples out there - although i'm to understand that for a self-balancing robot, 3xDOF is sufficient.

Any other 'newbie' advice would be appreciated.

2

BabyGeezer:

  1. Are encoders absolutely necessary ?

If you had an ideal IMU, then possibly not.
Have a play with your Uno and MPU-6050 and then decide :slight_smile:

  1. The motors will always be on - in other words, even at stand-still, there will be minute movements going on which might not even be visible as wheel movement - this will obviously be drawing current all the time.

Servos are usually arranged with some 'dead band' so the motor isn't driving back and forth or 'hunting', however, the motor may have some holding current (if it's a stepper for example).

  1. As far as size goes, the smaller the robot, the more difficult it will be due to sensitivity of the readings required, am i correct in that assumption ? i have been plotting raw analogRead() data from a MMA7361 (from DFRobot) which has been "simplified" to only power-lines and data pinout, plus a DIP switch for choosing 1.5g or 6g settings - what is strange (or am i misunderstanding the principles) is that the 'noise' from the 6g setting is much smaller - meaning the graph plot range is much tighter than when on the 1.5g setting.

Not entirely sure what you are getting at here...
Are you reading at 1.5g, multiplying by 1.5 and graphing - then reading at 6g, multiplying by 6 and graphing ?

Yours,
TonyWilk

3

Humans continually make small adjustments to maintain balance even when standing still because we are not stable. If a robot is 'balanced' (as opposed to being in a stable static position like a table) then it too will have to make continuous small adjustments.

This link shows a cycling robot which uses gyros and PID loops for balance. Note that when stopped but waving its hand it moves the bike wheel despite having one foot on the ground.

https://www.youtube.com/watch?v=mT3vfSQePcs

4

Corrected clickable link: Amazing Bike Riding Robot! Can Cycle, Balance, Steer, and Correct Itself. #DigInfo - YouTube

5

This link (Reply #2 in the Thread) may be of interest - especially the video it links to.

...R

6

ardly:
Humans continually make small adjustments to maintain balance even when standing still because we are not stable. If a robot is 'balanced' (as opposed to being in a stable static position like a table) then it too will have to make continuous small adjustments.

yes, i was thinking about human muscles too - i guess that confirms point #2.

Robin2:
This link

(Reply #2 in the Thread) may be of interest - especially the video it links to.

...R

ooh yes - thanks for that !

i definitely need to learn more about PID control.

read a good blog that simplified it as; 'P' is for the current data, and reaction to it; 'I' is the historical data (cumulative totalled) and 'D' is for the predicted data (based of course on current and historical data).

my grasp of it is : P for the first sets of actuator instructions, until oscillation is minimized, and then fine-tuning it further with I and D.

TonyWilk:
If you had an ideal IMU, then possibly not.
Have a play with your Uno and MPU-6050 and then decide :slight_smile:

well, i guess that means i'll proceed without encoders first. :slight_smile:

TonyWilk:
Servos are usually arranged with some 'dead band' so the motor isn't driving back and forth or 'hunting', however, the motor may have some holding current (if it's a stepper for example).

ah yes, that should've been a key question - is it best to have a (modified for continuous rotation) servo ?
i assume a stepper motor might be more expensive too.
i will be using a toy motor with built-in gearing, so i hope that could reduce the jittery movement.

TonyWilk:
Not entirely sure what you are getting at here...
Are you reading at 1.5g, multiplying by 1.5 and graphing - then reading at 6g, multiplying by 6 and graphing ?

no - the data gets plotted as is, how it arrives from the MMA7361 module.
in other words, at 1.5g - you get one version of a stream of data, and when the DIP switch is changed, you get fed the same stream of data (through analogRead() ) but when i graph them (both noisy) - the 6g 'curve' seems tighter - say within a range 340-360 whereas the 1.5g data can stretch from 300-400 - for sitting on the table.

admittedly the data can also be quite erratic and get even more noisy at different attempts of the same situation - which is why i decided to go with the MPU-6050 in the end.

7

BabyGeezer:
no - the data gets plotted as is, how it arrives from the MMA7361 module.
in other words, at 1.5g - you get one version of a stream of data, and when the DIP switch is changed, you get fed the same stream of data (through analogRead() ) but when i graph them (both noisy) - the 6g 'curve' seems tighter - say within a range 340-360 whereas the 1.5g data can stretch from 300-400 - for sitting on the table.

According to the datasheet, the MMA7361 outputs 800mV/g when in 1.5g mode and 206mV/g in 6g mode.

So just looking at raw analogRead() numbers, you would expect variations in 1.5g mode to be about 4 times the size compared to 6g mode !

A lot of processing needs to be done to the sensor signals to make 'em useful, I gather there are libraries to do this sort of thing. (Not used 'em myself, did my own math)

Yours,
TonyWilk

8

read a good blog that simplified it as; 'P' is for the current data, and reaction to it; 'I' is the historical data (cumulative totalled) and 'D' is for the predicted data (based of course on current and historical data).

Call me me pedantic but it's frustrating seeing something as simple as PID being tortured by people attempting to explain something they don't understand. To correct the simplified explaination you read:

'P' is the correction for the current error
'I' is the correction for the accumulated error
'D' is the correction based on the current rate of change of the error.

Prediction of any sort is not part of PID, its 100% based upon the error which is the difference between the desired operating point and the actual observed point of operation. Billions of words have probably been written over the years about PID but the concept remains unchanged and everything you ever need to know about tuning PID was written by Ziegler and Nichols in 1942.

9

Now that the topic has been opened up IMHO the thing that everyone calls PID would be more logically called IPD because the I-term is the important one. It is the only value that is relevant when the system is operating at a steady state because in that situation the P-term and the D-term will both be zero. (It is possible that the I-term would also be zero, but that does not invalidate the logic).

When there is an error between the setpoint and the actual performance the most immediate correction comes from the P-term and the I-term is adjusted a little at a time with each iteration.

Mainly under the influence of the P-term the system should move towards the setpoint and the error should reduce. Ideally, by the time the error is back to zero the I-term should have changed enough so that it alone is sufficient to hold the system in the steady state. In practice, of course, an overshoot is likely and that will be followed by adjustments in the other direction.

By careful choice of the fractions for the I and P adjustments the system should become stable with few overshoots.

In my usage controlling the speed of small DC motor I have not needed to use the D-term. However it may be important for a balancing robot - I have not yet tried one of those.

...R

10

the thing that everyone calls PID would be more logically called IPD because the I-term is the important one.

PID is a not a one-solution-fits-all-problems kind of thing.

Different systems exhibit different behaviors and every system has different needs. Common implementations include P only, PD only, PI only and of course full PID. Add the velocity model, the position model and some other variants just for fun and you have an alphabet soup of control methods. What remains constant though are the three terms and how they function.

11

avr_fred:
Call me me pedantic but it's frustrating seeing something as simple as PID being tortured by people attempting to explain something they don't understand. To correct the simplified explaination you read:

'P' is the correction for the current error
'I' is the correction for the accumulated error
'D' is the correction based on the current rate of change of the error.

thank you, pedantry is what i'm looking for - too many beginners just "stick with what they first understood (or thought they did)" and carry on the bad habit (or wrong comprehension).

TonyWilk:
According to the datasheet, the MMA7361 outputs 800mV/g when in 1.5g mode and 206mV/g in 6g mode.

So just looking at raw analogRead() numbers, you would expect variations in 1.5g mode to be about 4 times the size compared to 6g mode !

i see, so that means the 6g mode being "more sensitive" means it takes more of a 'movement' to budge it - whereas the 1.5g gets jittery at the slightest nudge. (seems a bit reversed from my comprehension of "sensitivity") :confused:

TonyWilk:
A lot of processing needs to be done to the sensor signals to make 'em useful, I gather there are libraries to do this sort of thing. (Not used 'em myself, did my own math)

yes - all sorts of filters from simple moving average to advanced math of Kalman filters - i'm still just trying to understand what the raw data coming through looks like !!

12

okay, it seems i might be in a bit of trouble.

i just read somewhere that usually one starts with the motor specs and then tailor the rest to that.

i guess that shouldn't be dogma when one tries to work with existing components already at hand.

anyway, my motors are two of these;
Power-Motor 50:1 9V 1,1A (rot) — FTDB
rated at 9V and 1.1A

while the motor shield is;
Arduino_Motor_Shield__L293___SKU__DRI0001_-DFRobot
which handles 1A per channel

would this be "out of bounds" or within acceptable limits ?
if one avoids running the motors at full speed, would that be safe enough ?

i intend to use 7xRechargeable AA batteries = 7x1.2 = 8.4V but i'm wondering if the "drop via the H-Bridge" would leave little room to manipulate the speed;

i refer to this post on L293D being "old technology" :confused:

13

If you already have the motor shield then try it. If not then I would suggest getting a motor driver that uses Mosfets and which can deal with a higher current (maybe 3 or 5 amps) AND which can withstand an overload or short circuit without damage. The Pololu website lists several motor drivers and other suppliers have similar products.

I am using a Pololu DRV8833 to control a model train with PID speed control. That driver can support 1 amp per channel and the two channels can be connected in parallel. Note however that it is a low voltage device - max is about 10v IIRC. I am using it with a 1S LiPo.

In another project I am using an Infineon TLE-5206 h-bridge chip.

...R

14

Thanks for the tips on alternative chips.

So, i will go ahead and try using what i have.

What sort of newbie pitfalls should i be looking out for; just for safety's sake so as not to fry any board or the motors.

Or, can i assume that with the current setup, the worst case will only be a shortfall of power to the motors and it won't budge/move enough.

Since this will be focussing on balance and not speed, limiting the PWM should be sufficient to safeguard the motors, right ?

15

BabyGeezer:
Since this will be focussing on balance and not speed, limiting the PWM should be sufficient to safeguard the motors, right ?

Learn how to control the motor at different speeds with a very simple program and without any attempt at PID so that you can determine how your motor driver works. Don't jump straight into a project as complex as a balancing robot.

...R

16

Robin2:
Learn how to control the motor at different speeds with a very simple program and without any attempt at PID so that you can determine how your motor driver works. Don't jump straight into a project as complex as a balancing robot.

yes, i have gone through all the basic tutorials - and i guess i really shouldn't be asking such fundamental questions if i have truly grasped the concepts.

this is my understanding of motors so far, can you comment on the following statements - whether they are correct, inaccurate or just plain wrong;

  1. a motor rated 'n-Volt' should NOT be given more than n Volts.

  2. we control the speed of the motor by modifying the current (I) passed to it.

we can do this by;

  1. changing the R (in V=I*R) using a variable resistor (say a potentiometer) in series (before the motor) which alters the voltage drop which changes the current (hence speed) of the motor.

or;

  1. changing the V (in V=I*R) using PWM as the voltage with which to run the motor, the lower the V, the lower the current and hence, speed of the motor.

  2. using PWM means the voltage is turned on and off quickly simulating a lesser amount based on the time it is on vs. off ( =duty cycle) as opposed to (2) where it is a constant supply of the determined V amount.

  3. using a motor driver chip (ie. with transistors) means some "usable"(?) voltage is lost to the transistor which means the "effective" voltage to the motor is less.

  4. Load adds mechanical resistance. The motor starts to consume more current to overcome this resistance and the speed decreases. This uses P(ower) = I*V - I increases, so V decreases and hence the speed.

  5. If the load goes beyond a certain point, V drops to a level where it is insufficient to spin the motor - called motor 'stall' but the current is still being drawn and this is usually a high amount - the important amount which can cause damage to circuits not able to withstand it.

17

You are not correct about " a motor rated 'n-Volt' should NOT be given more than n Volts." The important thing is to limit the maximum current in the motor coils so that the motor does not overheat to the point of damage. Obviously in a given situation a higher voltage results in a higher current. But when using PWM the average current could be kept within bounds even with a higher voltage.

And you have missed one important facet of electric motors. When the motor is moving it generates a reverse voltage that opposes the power supply voltage. The faster the motor runs the higher is the reverse voltage. The current in the coil is the result of the difference between those voltages. Consequently, for a give supply voltage the current will decrease as speed rises - which is what limits the top speed of the motor - at that point the current is just sufficient to overcome internal friction in a fre-running motor. The other side of all that is that when the motor is stationary there is no reverse voltage and the only thing limiting the current is the very low coil resistance. That means the stall current can be very high - for many motors it is high enough to destroy the motor if it last for more than very short period. And you can probably see that for faster motion a higher voltage is necessary but that brings with it the risk of an unacceptable stall current - no such thing as a free lunch. It may be less obvious from all of that but faced with two motors that are physically the same but have different coil windings then the motor designed for the lower voltage will usually run at a higher speed if both motors were to be powered at the same voltage.

...R

18

Robin2:
You are not correct about " a motor rated 'n-Volt' should NOT be given more than n Volts." The important thing is to limit the maximum current in the motor coils so that the motor does not overheat to the point of damage. Obviously in a given situation a higher voltage results in a higher current. But when using PWM the average current could be kept within bounds even with a higher voltage.

hmm - so then it would actually be okay to use 8 x Rechargeable AAs (=9.6V) and limit any "max PWM" to below the actual max 255 limit.

this would certainly save having to custom-rig a 7-pack battery holder !

Robin2:
And you have missed one important facet of electric motors. When the motor is moving it generates a reverse voltage that opposes the power supply voltage. The faster the motor runs the higher is the reverse voltage.

i see, that's what makes it such an inefficient 'machine' (power usage-wise).

and the other statements, 1 to 7 are all correct understanding then ?

19

BabyGeezer:
i see, that's what makes it such an inefficient 'machine' (power usage-wise).

? ? ?

Electric motors can have very high efficiencies (like 90%) - though generally that is achieved in large commercial motors.

...R

20

Robin2:
? ? ?

Electric motors can have very high efficiencies (like 90%) - though generally that is achieved in large commercial motors.

...R

am i referring to some other "efficiency" then ?

from this page;

If the motor has 100% efficiency all electrical power is converted to mechanical energy. However such motors do not exist. Even precision made small industrial motors such as one we use as a generator in generator kit have maximum efficiency of 50-60%.