Balancing Bot

Status
Not open for further replies.
JFDuval said:
Hello!

The link is working, it's the video that can't be seen (by some people at least). The directory jfduv/ exist. Don't forget the slash at the end.

It appears to be the accent on the 'e' which stops it being found, presumably some language setting in Windows?.

Try **broken link removed** which works.
 
MrMikey83 said:
Seems to stay pretty still which doesn't make for a very exciting video. Good job though!
~Mike

lol
thanks MrMikey

I didn't even think of that!
it was so much work (for me, i'm new to all this) that i wanted to send the best movie of it, by that i mean best tuned


yours looks good
i like the wheel's, that was one of the hard things for me finding cheap wheel's for it
so i cut them out of wood
lol
 
I plan on driving mine around outside of concrete sidewalks and through grass, so wood wheels wouldn't have been good for me. Plus, the high speed these motors can reach would cause the wood wheels to slip . Not sure how the high speed will effect the balancing calculations, but my controller is proportional so I can make it go slow and speed up gradually if I need to.
(Assuming I ever get the receiver to talk with the ATmega)
~Mike
 
Update:
I finally got readings from the reciever with bmcculla's help. Now, I just need more plugs to connect the other channels to the AVR. I can finally start designing my PCB, now that I know everything will work on the ports they are connected to.

The circuit will have the AVR with 5V and 12V power supplies from the 24V battery source. A separate board will be made for the sensors so that I can possition them where I need them. The motor control H-Bridge might be separate, but I'm not sure yet. I might leave it separate so that I can use them on other projects. Also need to design battery charger circuit when I receive my samples.
~Mike
 
How about an update?

The monster truck motors I realized were way too fast for what I need. I got some very nice quality low speed Pittman motors instead. The RPM out of the gearbox is 1,227rpm and will be geared down also. Normal speed should be about 4MPH at half voltage, allowing plenty of room for the controller to speed up the motors in case it tilts a lot or needs to climb over something on the ground.

I used an online tutorial to instal encoders on the motors so I can detect the speed. My battery charger seems to work and it charged in just a couple hours. I need to transfer it from breadboard to PCB.

The new Pittman motors require me to alter the chassis for my robot. I am waiting on some new drive gears to arive in the mail (old gears are too small for motor shaft).
Will post a picture when I get the new chassis built.
~Mike
 
Got the motors mounted and the circuit boards etched. Everything is finally connected together and ready to go. Now I just have to program it to do what its supposed to do.
~Mike

**broken link removed**
THis is the controller board, where everything else connects in.

**broken link removed**
Heres the battery charger circuit.

**broken link removed**
The motor controller kit I got.

**broken link removed**
FInally, the finished product. Its not blancing yet, I propped it up.

**broken link removed**
Another finished pic.
 
After battery problems, I rebuilt the batteries into a wrapped pack and they work and charge fine.
I have programmed the motors to move forward when tipping forward and same for reverse. Also, they speed up the more or faster it tilts.

Now, the problem...
The motors create a lot of vibration that travels through the frame and circuit board and shakes the crap out of the accelorometer.
Anyone have any idea of how I can filter this noise so I can have a signal to work with?
~Mike
 
You might be better off trying to damp out the motor vibration. Maybe a rubber washer between the motor and motor mount.

If you still have noise you can add a cap to the accelerometer ouput to cut the bandwidth and reduce noise. This would also reduce the bandwidth of your control loop.

If you want to do things digitally a simple FIR filter wouldn't be too hard to implement.
 
Mike why did you put the batteries on top ? just asking??
maybe something aerodynamic up there will help,like a peice of cardboard , once you get it going..
 
i dont know of anything that will hold the accelerometers in place, and not pass at least some vibration to them.. except maybe bubble wrap or a very soft foam..if you could keep the vibration that the accelerometers are subjected to, in the vertical plane , somehow , that might help also..
 
Hi,

I don't mean to advertise too hard on your forum, and I would really like to give all the info I can, as well as receive some help.

I too have been trying to build a reverse pendulum bot for awhile! Basically - she doesn't balance on her own yet, but very close. The control loop is just a bit out of whack. My bot is almost as simple as you can get. I use a 16F88 with bootloader at 20MHz. My brother's friend came up with the structural design and cut the plastic for me. I use the 1A H-Bridge (SN754410) stacked to help reduce some of the heat. It works, but they get toasty when the bot starts kicking back and forth rapidly. I found some quick, torquey, 6V DC gearheads that I am over-voltaging with 8 NiMH AAs - super fast with great torque. We produce little IMU boards with the ADXRS and ADXL sensors mounted together in a nice right-angle fashion. I am using the ADXRS401 and ADXL320 currently with a new layout for the ADXL203 on the way. I have the ability to increase the sensitivity of the PIC's ADC (setting Vref+/- with a resistor divider network) but have been too lazy.

I have tried every combination of smoothing, fudging, tweaking, and I can't get it to stand up. It's pretty violent when tweaked hard (I imagine Mike is experiencing similar issues) - but I don't think vibration reduction is the answer. I am thinking that I am going to have to go with a Kalman filter. I am sure the PIC can handle all the math at 20MHz, but I just don't think I need (or want) something so complex.

I would love to get any input from other users who have implemented a inverse bot with only a tilt sensor and a gyro. Many others (google balancing robot) have managed quite well but use wheel encoders which I would like to avoid. Anybody know of some sort of a math/integration trick or a way to make the math a bit more sensible for implementation on a 8-bit micro, and not a desktop 2GHz running MatLab?

-Nathan

**broken link removed**
Here are the close-ups :
**broken link removed**

Code:
    while(1)
    {
        //delay_ms(45);

        //Look for user input
        check_for_button();
        
        //Find tilt magnitude
        //===================================================================
        tilt_value = read_tilt();

        tilt_angle = tilt_center - tilt_value;
        //===================================================================
        
        //Find gyro magnitude
        //===================================================================
        gyro_value = read_gyro();

        gyro_amount = gyro_center - gyro_value;
        //===================================================================
        
        tilt_correction = tilt_angle * tilt_fudge;
        gyro_correction = gyro_amount * gyro_fudge;

        new_correction = tilt_correction + gyro_correction;
        new_correction = new_correction * new_fudge;
        
        //motor_correction = motor_correction + new_correction; //Integrate over time
        motor_correction = new_correction; //
        //if (abs(tilt_angle) <= 1) {putc('!'); motor_correction = 0;}
        
        /*
        printfloat("T=%f ", tilt_correction);
        printfloat("G=%f ", gyro_correction);
        printfloat("C=%f ", motor_correction);
        */
        
        set_motors(motor_correction);
        
    }
 
You have a good setup to do a PD controller. A derivative term will help damp out oscillation. You have your accelerometer to give you angle and you have your gyro to give you the derivative of angle(it'll be helpfull that you can measure derivative(angle) because noise will play havok with calculating derivative).

motor_correction = P*angle + D*gyro; //where P and D are the controller constants. D should be negative to oppose the P term.

EDIT: On closer inspection it seems that you are already doing a sort of convoluted PD controller. Making an explicit PD controller as above will make your life easier because it decouples the P and D terms (no common new_fudge term).

You should also make sure your control loop happens at a fixed interval. otherwise adding code to the loop will change your controller characteristics. 1ms is about right for this sort of controller. Don't do prints in a control loop. Make a background task that doesn't interfere with the timing of you loop.

You don't want an integral term in your controller because there won't be any steady state force to overcome.
 
Thanks! I got rid of the common term and setup the PD as you suggested. I continue to have some really wicked shimmies whenever I start playing with values. I feel like I need a dampening variable - that's why I was trying to integrate the correction value over time.

I've tried changing the PWM update rate on the motors, the delay in the faux_pid loop (from 0-45ms), I've re-glued the hubs in an effort to remove slop. I've run the P and D values from 0-8 in 0.01 steps. You can feel the bot correct itself very well and intelligently (direction is correct, magnitude feels right) - but the system never stabilizes.

I have a hunch that the tilt sensor is not of high enough resolution. A 1 'tick' change in the ADC reading, and the system reacts so quickly, it starts to oscillate. If I decrease the ADC range (I'll set the Vref+/- pins tomorrow) I can increase the tilt resolution. It may calm the system down enough to get rid of the shimmies.

This is a really horrendous control loop! I am surprised there is not more example code out there. The big guys (nBot, Trevor Blackwell, etc) don't have actual code. They only allude to filters (Weiner and Kalman). They also use encoders. Should I stop now and get an encoder on here somehow? I'd really hate to.

Most Kalman filter write-ups involve three-dimensional control of UAVs. Does anyone have any insights into a 1-D line Kalman? I feel like the prediction characteristics of a Kalman would dampen out all the over-corrections of the system.

Mad thoughts, way after midnight.

-Nathan
 
From a quick look at what it is a Kalman filter is way more complicated than you need. It looks like just a slick way to implement a controller with a predicted feed-forward term.

I think your problem is your tuning of your PD controller rather than the controller itself. A PD controller should be fine for this app.

I've run the P and D values from 0-8 in 0.01 steps.
You NEVER want to use floating point values in time critical code of an 8 bit system. Floating point computations are really, really slow on an 8 bit system. A single floating point multiply will take several THOUSAND instructions compared to tens for a 16 bit integer multiply. I have a feeling your control loop is running a lot slower than you think. If you need fractional values use Fixed point numbers which can be implemented using standard integer math.

The trick to PID controllers is how you tune them. Start out with D set to 0. You then gradualy increase P until the system starts to oscillate crazily and then back off a bit. To get the best system responce you want P just below the value that causes instability. You then start to increace D until you get a nice quick response with little overshoot.

I feel like I need a dampening variable - that's why I was trying to integrate the correction value over time.
It's the derivative term that is the damping term - make sure you have the sign right so it's damping (it should be in the opposite direction of the P term). The integral term is only to cancel out constant forces in steady state. The rest of the time it make a controller worse.

A 1 'tick' change in the ADC reading, and the system reacts so quickly, it starts to oscillate.
This means your P term is too big. If you can't make P low enough and still use integer values just add a constant divisor to the control output (this effectivly make your values like a truncated fixed point). You can also add something called "dead band" this is where you ignore differences lower than a couple ticks.
 
hey MrMikey and SparkFun
you guys got me into this again!

i ordered the gyro/Accel(it is a great little board!) board from you a while back, but never got around to playing with it till last weekend

from the things i've been doing/reading i don't think you can use the accel part
in the control loop
just use it to reZero the gyro

one thing i did to see what kind of output the board give's, is hang it from a string like a pendulum
while graphing the output on a 128*64 lcd
the gyro gave a good wave but the accelerometer gave a flat line!!
so it will not know when the robot is falling!

well i put this together over the last week
and i just use the gyro to control it, so it will stand perfectly still for a few seconds before it starts to drift
i need to use the accel to recalibrate it every 100ms or so

also i am using an op-amp to amplify the gyro output
before the op-amp the output was almost unusable(very small!)


here is a picture of it balancing(click to see bigger)

**broken link removed**

**broken link removed**
 
With respect to the vibration aspects, there are elastomeric materials that you sandwich into your system. They basically act like RLC circuits (so they are tuned dampening) and wll have a roll-off just like a circuit. They will add a resonance point to your system, but it is usually at such a low frequency it hardly matters. EAR composites is one whose products I have successfully used.
 
I just finished a year long research project for my school's research program. I compared an accelerometer, distance sensors, and both in combination to find the best sensor/combination that made the robot balance the best. I spent months trying to get my robot to balance and I can offer two tips. 1) Put battery and boards on top. 2) Use big wheels. My final robot has 6 inch foam 1/4 scale model airplane wheels and is over a foot tall. I will include pictures of it, movie of it balancing, as well as specifications of it later in the week. (I have an AP computer science exam coming up so I need to study : ) Hope that helps. Email me if you have any questions.
 
Status
Not open for further replies.
Cookies are required to use this site. You must accept them to continue using the site. Learn more…