Balancing Robots with NEWER sensors?

charleyshf · 2011-03-02 07:13

Hello,

For a while now I have been building a balancing robot from scratch, after reading MANY different articles and papers on balancing robots, going through many different forums, Kalman filtering, fuzzy logic, PID, etc, etc, etc I am wondering about some things that I noticed that most of these balancing robots have in common and was hoping that someone could shed some light on the subject.

1) I have yet to see a balancing robot that uses all digital sensors (Accelerometer/Gyro/motor controller-Serial not PWM) but it seems that some if not all sensors are interfaced with an external A/D and the motor controllers all use PWM. Is there a reason for this?(cost,speed, better control?)

For example, in the book Programming and customizing the multicore prop book, looking at Hanno's dancebot, it's using a combination of analog and digital sensors, the motor controller via PWM. Minus the vision, the amount of cogs used I think could be reduced if:

No external A/D or analog sensors - use I2C Accelerometer/Gyro combination.
Motor controller controlled via serial, and the motor controller also takes care of encoders/PID routines, in fact I have a motor controller that I am writing a driver for most recently called a Robo Claw,(still cleaning it up after help from this forum) that in addition to controlling motors, also takes care of the PID routines, for encoder counts for example you can just read them in and not have to worry about keeping track of counts. The controller is here http://www.basicmicro.com/Robo-Claw-2x5A_p_47.html
.
I don't know if this controller is fast enough or not to be used for a balancing robot.

I am not that good at programming the prop in spin, I can figure out most of what the code is doing, but I noticed that there are sections of code from the OBEX that use assembly in parts of it, and I am lost at that point, I have never programmed in assembly and to be honest I really don't want to start.

The balancing robot I am working on now (which I have "training wheels" attached to keep it from falling over) I am the point where I can control it, but basically like a big trak, you plug in how far you want it to go and it does it, it was a highlight for me at first, but about 5 minutes later I am thinking, how the hec am I going to:

1) Using Hanno's Dancebot example code, gut out the pwm(which is written in assembly) and replace it with my serial motor controller routines.
2) I have the same i2C Accelerometer as dancebot does(LIS3LV02DQ), however my gyro is an I2C HMC5843,again I have to gut out that part of dancebot's code and figure out how to make this sensor work.

Above everything else, is this idea with different hardware going to be fast enough ? Hanno had posted his dancebot code with comments not that long ago from this forum here http://forums.parallax.com/showthread.php?120678-DanceBot-Questions&p=973973&highlight=dancebot#post973973 , post #4, which is what I am working with. I also have used code from the OBEX that allows me to get sensor readings from my accelerometer and gyro, which I think I can combine with the Dancebot code.

I'd greatly appreciate any feedback/ideas on this.

Thank You

Hanno · 2011-03-02 13:18

Hi Charley,
I recently bought a 9 degrees of freedom all digital sensor: http://www.sparkfun.com/products/9623
It includes an arduino which you can program with code that will calculate roll/pitch/yaw for you.
I've sadly been unable to clone myself so I haven't had time to pursue DanceBot- but am hoping to get to it soon. This one would use 9dof for a sensor, Propeller as controller, and big wheels to run around- maybe: http://www.parallax.com/tabid/768/ProductID/507/Default.aspx
Instead of balancing bot may do a bicycle...
Nothing analog, read digital from 9dof, output pwm to drive wheels and read in position.
Hanno

Roy Eltham · 2011-03-02 14:15

what about one using Parallax parts? They have a gyro and accelerometers.

Hanno · 2011-03-02 14:39

When I built the DanceBot I was toying with the idea of somehow commercializing it- hence the focus on low cost and discrete components.
By using an existing full IMU I greatly simplify the problem- less things to debug means more chance I'll actually finish it.
Hanno

charleyshf · 2011-03-02 20:07

Hi Hanno!
It's been a while, and It's good to hear from you, I hope everything is okay with you and your family..

I was looking at that IMU from your link, but they discontinued it and they are working on a newer version. The sensors I have currently (3 axis LIS3LV02DQ accel / 3 axis HMC5843 Mag) I bought over 6 months ago and am just working with them now. That motor controller I was talking about above, the Robo Claw can run in Serial/RC/Analog modes so if the serial mode wasn't fast enough I could always switch to PWM mode. I mainly got it because I figured if I could get it work with all the features it has to offer, I can free up some resources on the prop(it takes care of tracking and keeping count of two quad-encoders, as well as the abiity to customize PID settings, it's worth taking a look at, in my case a pair of USDigitals and the same motors you run on the Dancebot). The only problem is that if it doesn't work out in serial mode, the encoder and pid routines do not work in PWM mode

. A balancing bicycle with a prop would be very interesting to see, but 150rpm, would that be enough?

I've read so many different articles on balancing robots, different approaches, Kalman filtering(which I still cannot get a grip on, then again as a bunch of people have posted "I don't understand it, but it works"), i've just gotten to the point where I am thinking I can spend the next 100 years researching, and I am not going to get any further until I start actually doing this, which I have started, but among other things i've always wondered why analog sensors are still used so much in balancing robots, my only conclusion is cost..

Hanno wrote: »

Hi Charley,
I recently bought a 9 degrees of freedom all digital sensor: http://www.sparkfun.com/products/9623
It includes an arduino which you can program with code that will calculate roll/pitch/yaw for you.
I've sadly been unable to clone myself so I haven't had time to pursue DanceBot- but am hoping to get to it soon. This one would use 9dof for a sensor, Propeller as controller, and big wheels to run around- maybe: http://www.parallax.com/tabid/768/ProductID/507/Default.aspx
Instead of balancing bot may do a bicycle...
Nothing analog, read digital from 9dof, output pwm to drive wheels and read in position.
Hanno

charleyshf · 2011-03-02 20:09

Hi,,,

I could be wrong, but from I have been reading I don't think the current sensors gyro/accel that they offer are quite fast enough, but like I said I could be wrong..

Roy Eltham wrote: »

what about one using Parallax parts? They have a gyro and accelerometers.

charleyshf · 2011-03-02 20:15

I remember when you were considering this, it's still a great idea I think, and prices for imu's are starting to come down, I wonder if someone could build an IMU using the prop as the controller for it like they did with the IMU you purchased from Sparkfun??

Hanno wrote: »

When I built the DanceBot I was toying with the idea of somehow commercializing it- hence the focus on low cost and discrete components.
By using an existing full IMU I greatly simplify the problem- less things to debug means more chance I'll actually finish it.
Hanno

Hanno · 2011-03-02 20:52

Why not take it one step further and integrate everything into one chip- like this:
http://invensense.com/mems/gyro/mpu6000.html

charleyshf · 2011-03-03 01:26

Hanno wrote: »

Why not take it one step further and integrate everything into one chip- like this:
http://invensense.com/mems/gyro/mpu6000.html

That's a interesting little sensor... The i2c version is out and it looks like people are working on / already have a breakout board for it, trouble is there are some wild claims about it's abilities...

JoeBotics · 2011-03-03 07:47

Hanno wrote: »

Why not take it one step further and integrate everything into one chip- like this:
http://invensense.com/mems/gyro/mpu6000.html

Hey Hanno / Charleyshf... I have also been looking into this IMU.. although I bought the IMU3000 module + INV-ARM module (this one allows you to interface the IMU3000 with the computer via USB)... you can signup and download their Visual C++ 2005 libraries and play with them...I was also curious about the capabilities of this IMU.. and from what I can see it is amazing!... unfortunately the libraries are VS2005 and I spoke with one of the guys at Invensense and there are no plans for VS2010 libraries yet... also... their documentation states that the INV-ARM drivers are only for XP... but the guy also provided me with the INF file necessary for Windows 7... I can attach it to this thread once I find it in my computer... peeking through the libraries I am learning how this IMU works... the IMU3000 / IMU6000 generate "quaternion" values... but there is a function in the library that converts the quaternions to more understandable values that we can code in the Propeller once we get to interface with the module via I2C.. now.. from looking at the libraries.. the IMU3000 / IMU6000 in fact integrates gyro/accel data and provides us with usable yaw/pitch/etc values!!... I went through the library functions and I don't see anything that takes raw gyro/accel data and performs complex calculations to integrate the data... so as far I can tell.. the IMU does its magic !!... the library documentation is pretty basic in the sense that it tells you what the functions do, but not the meaning of the results... the most usable one I found is the function that converts quaternions to eight independent values... here it is:

void quaternionToRotationMatrix( const long *quat, long *rot )
{
rot[0] = (long)(((long long)quat[1]*quat[1]+
(long long)quat[0]*quat[0])/536870912L-1073741824L);
rot[1] = (long)(((long long)quat[1]*quat[2]-
(long long)quat[3]*quat[0])/536870912L);
rot[2] = (long)(((long long)quat[1]*quat[3]+
(long long)quat[2]*quat[0])/536870912L);
rot[3] = (long)(((long long)quat[1]*quat[2]+
(long long)quat[3]*quat[0])/536870912L);
rot[4] = (long)(((long long)quat[2]*quat[2]+
(long long)quat[0]*quat[0])/536870912L-1073741824L);
rot[5] = (long)(((long long)quat[2]*quat[3]-
(long long)quat[1]*quat[0])/536870912L);
rot[6] = (long)(((long long)quat[1]*quat[3]-
(long long)quat[2]*quat[0])/536870912L);
rot[7] = (long)(((long long)quat[2]*quat[3]+
(long long)quat[1]*quat[0])/536870912L);
rot[8] = (long)(((long long)quat[3]*quat[3]+
(long long)quat[0]*quat[0])/536870912L-1073741824L);

I modified the Demo to show those values on the screen... and I can tell that rot[7] and rot8] provide Pitch / Roll values very similar to JWood's "IMU.get_angle_pitch" / "IMU.get_angle_roll" functions ..... very exciting indeed!!...

I bought my IMU3000 kit + INV-ARM USB interface board from cdiweb.com (BTW... the IMU6000 does exactly what the IMU3000 does but it integrates everything in one chip.. the IMU3000 still requires an external accelerometer.... but the IMU3000 is really small... I don't believe there is a IMU6000 kit with SPI interface in the market yet)

Hanno · 2011-03-03 21:15

Very exciting to see this integration of nanotech. Last year I attended a talk by HP about their accelerometers with nice photos of the tiny structures. Now we have to come up with good applications!
Hanno

charleyshf · 2011-03-03 21:39

Hi Hanno,

I'm still amazed how small these sensors are getting, like the 9DOF IMU'S i've been looking at recently, however I would like to see the cost come down some..

I've been going through your code for the dancebot, and what I am in the process of doing is modifying it so instead of using pwm, it uses serial commands to get it's readings from my motor controller(encoders/speed/target velocity), and the other thing I have to do is get the gyro readings from the i2c gyro instead of the one you were using, it sounds trivial, but so far proving to be difficult for me to do. Hopefully in the coming weeks I will be able to come up with something...

Hanno wrote: »

Very exciting to see this integration of nanotech. Last year I attended a talk by HP about their accelerometers with nice photos of the tiny structures. Now we have to come up with good applications!
Hanno

Cluso99 · 2011-03-04 01:43

You can buy the Wii Motion Plus which contains a gyro and I2C interface from eBay for ~$10 inc shipping. IIRC there is a thread about this and also code in the Obex. It's a nice tiny pcb. It is 5V.

JasonDorie · 2011-03-04 12:01

I've got this gyro (http://www.sparkfun.com/products/9801) on my quad rotor, and found it to be very good all by itself. I've been meaning to write the code to fuse the output of a digital accelerometer into the readings, but honestly the thing works so well without it that I just haven't been motivated enough to do it. :-)

Not as cheap as the Wii Motion Plus, but it's got built in filtering at user selectable frequencies, different internal sampling rates, and a built in temperature sensor which makes it relatively easy to compensate for drift.

Cluso99 · 2011-03-04 12:24

Jason: Here is a link where they tap the analog section of the Wii Motion Plus http://www.rcgroups.com/forums/showthread.php?t=1143569&page=609
My pcb is the same as post #9129. They are invensense dual gyros.

For the accelerometer, a Nunchuck has one and they are also cheap and can daisy chain on the I2C bus with the Wii Motion Plus, or just in parallel.

Sapieha · 2011-03-04 13:53

Hi All.

Why not use that one.

9 DOF - Razor IMU AHRS comp.

charleyshf · 2011-03-04 19:23

There's definately some choices out there, but some things that I am wondering about.

For an effective 2 wheeled balancing robot, how many DOF do we actually need? Effective meaning that the robot can balance for long periods of time. Also the robot can travel around while maintaining balance.

What kinds of speeds do we need for digital I2C sensors as far as communicating with them to the prop(accel/gyro). Also we need decent motors with encoders(i'm running the same motors/encoders as Dancebot).

Some people have used a Floating Point Co-Processor uM-FPU v3.1 as well with the prop/sensors, I assume for the Kalman filtering/Matrix ?

I'm still working with Hanno's Dancebot code changing things over on the motor and sensor routines to work with newer sensors, no analog..

Hanno · 2011-03-04 21:43

Hi Charley,
You actually only need 1DOF- the "pitch" or "tilt" of the platform to balance. You could measure this directly using ultrasound/led (but doesn't work for rough/inclined surfaces) so best is to measure 2DOF- using gyro and accelerometer. If you want to do dead-reckoning then a 3-axis magnetometer is good. I didn't get good results with parallax's compass- the bot was tilting too much- hence the need for 3-axis.
The higher your center of mass- the slower you can do your calculations. For my ~30cm high bot my loop was running at 200hz.
Good luck!
Hanno

charleyshf · 2011-03-06 15:57

Thanks Hanno,

I've spent the better part of the weekend just on trying to understand the _Motor.spin object, I know what it's supposed to do but once I get to the assembly part I am lost. Since I am using a motor controller that takes care of both encoders and is interfaced to the prop via serial comms it's proving to be a big pain in the neck.

charleyshf · 2011-03-09 18:12

I did something the other day out of flustration trying to get a better understanding to what's involved to get a balancing robot using a prop and converting different pieces of code, if you google for "how to build a Balancing robot for dummies" you will find in the "cough", "cough", Arduino forums a complete how to on setting up a balancing robot, some good info in there as well. I had all the parts except for the pwm motor controller, I had a much smaller one that fried after an hour or so of balancing(L298, and it was old and abused), but it took me all of an hour to get it going, and it did a really good job at balancing. It also gave me some other ideas on how to attempt to do this better using the prop and a better understanding to what's involved to make all of this work.

Still I see most balancing robots using analog sensors and controlling motors using PWM, even the one above I just built. I would think that going digital on the sensors would cut down on some of the noise(and yes I know that most of the i2c sensors have a/d converters on the boards). For the motor controller, the one I am working with now with my prop, I am sending commands to it via serial i/o, starting to wonder if it's going to be too slow for my balancing robot. The nice thing about this controller is that it takes care of the encoders, you can change PID settings, built in ramping if you need it, all sorts of things with this controller and I thought it would offload the work from the prop.

I am not that good at programming in spin, but constantly learning, I can make the parts I need for the base (cnc mill, I usually prototype with PVC plastic), anyone care to start a project on this??

Balancing Robots with NEWER sensors?

Comments