Hi everybody I would like to show the project I was working on for the past six months and
also my first major project.
Its a self balancing robot that you can control with a Wiiremote, that is connected to the arduino using a bluetooth dongle and a Usb host shield.
for more information go to:
http://letsmakerobots.com/node/26095
congratulations..
I followed the kas guide and with his same components and pid values the bot was working fine..
I changed the IMU and cannot find the right PID values..
I read a lot of theory about PID, but...nothing stable as Your bot.
Are You using encoders? Do You use PID with angle and PD with encoders or what else?
bye,
Danilo
very nice!
Awesome!
Thanks for the replies,
And Danilo yes I am using encoders it is a vital part for balancing on 1 point otherwise it will always drift.
For the PID i suggest starting with a value of 30 and working your way down until the jittering is minimal.
I use a PID for the IMU and a PD for the encoders I find the iTerm to be not that important. But the
website I can recommend to you is http://www.x-firm.com I have used that one A lot, and
it is very good in explaining all the different aspects of the code.
Timen,
i am using the same code You are using (more or less Kas style)..
the theory for PID tuning says:
For manual tuning, set all three constants to zero, then turn up Kp until oscillation occurs.
Then turn up Kd until oscillation disappears. Adjust Kd until the system is critically damped, i.e. there's no overshoot.
Did You follow this rule?
Could You post a video of your bot drived only from Kp (IMU) until oscillation occurs?
I would like to understand what means "oscillation occurs".
Driving my boot only with Kp this is what happens:
Kp low the bot falls;
Increasing Kp around the " error zero" it vibrates a little bit then falls.
do I have to assume that " until oscillation occurs" means this vibration around " error zero" or an oscillation should be more "important", lets says -20 0_+20 or -40 0_+40 in pids?
thanks,
danilo
Wow! Inspirational!
oscillation occurs. that means the bot keeps going back and forward and the back and forward motion does not increase. But no I did not follow that rule because I think that only works with sensors who give a physical output you can measure easily not something you can do with the movement of the balancing bot.
The way I did it was start with a Kp of 40 Ki = 1 and Kd = -8 than just lower the Kp until you think the bot balances OK it will still jitter but that is really hard to completely remove. If you found your Kp than just modify Kd until your bot does not jitter so much you will never remove the jittering because of the backlash. The Ki i found does not affect the balancing a lot. But its mainly experimenting around with values it will take time and practice but with 2 POT meters it is a whole lot easier and faster to do because you can adjust the constants on the fly.
Timen,
thanks again..
I am now working on this 3 actions:
We are using the same Pololu motors, do You think that the new battery could drive better the motors?
bye,
Danilo
It depends on the voltage of your battery if you use 3 cells your voltage should be 11.1 volt which is just fine.
But I do recommend removing the motor encoder code for now just make you bot balances using only PID and than look into that. All at once is just to much! And I strongly recommend using my PIDPD loop when you start with using your encoders! I could not get kas his encoder code to work so I used other code.
Oh and one last thing Keep the COG(center of gravity) as high as possible! batteries on top that means!
Ok one very last thing balancing bots are a hard thing to make but it IS SOOOOOOOOOOO rewarding when it finally stands!(so don't give up)
Hi Timen,
I am following Your suggestion about using Pots to find out Kp and Kd...
Now I am facing problems on battery and motor current.
The battery I am using now is a "DC 12V 4800mAh Super Rechargeable Lithium-ion Battery" from ebay http://cgi.ebay.it/DC-12V-4800mAh-Super-Rechargeable-Lithium-ion-Battery-/120522024195?pt=LH_DefaultDomain_0&hash=item1c0fac2503
as soon as motors go back and forward all the systems shoots down and I have to power off and on again, arduino restarts..
I am using your same pololu motors and this as driver Projekte,Schaltungen,Komponenten und Bauteile für den Robotik-, Microcontroller-Entwickler ...
Did You ever face this kind of problems?
What kind of driver are You using (could You post a link)?
What kind of battery are You using (could You post a link)?
thanks,
danilo
Hmm it indeed looks like your motor driver or battery is the weak link. My german is very bad so I can't say if the motor driver is any good but I don't think that is the problem.
I myself used this one: SparkFun Ardumoto - Motor Driver Shield - DEV-14129 - SparkFun Electronics
But that one was just because I did not have anything better laying around but it gets pretty hotttt:P
And the battery looks like first grade chinese crap... But I don't really know if a premium battery is necessary for this kind of usage. So I don't really know where the fault is located but you are looking in the right direction.
Maybe that low quality battery do make a difference I paid 85 euro's for the same amount of energie storage:
http://www.rctechnics.eu/hyperion-5000mah-p-3976.html
And can't you try testing your setup with a program that runs your motors at all kind of speeds and all kinds of directions.
Timen,
the problem is the battery.. i get back to my old battery (a very simple pack of 10 1,2 nimh 2600mah) and the system does not switch off..anyway it still does not stay up..
Ok, the photo "1" is my first release..it could stay up for 45 min, it hat a sonar sensor to avoid obstacles and a turning infrared receiver to understand the direction of the ir emitter and to follow it....the main kode was based on Kas thread.
I think that some inverse current coming from the motors burned arduino, the sonar sensor and the Sparkfun 5DOF analog IMU....at that time I was using the simple pack of 10 1,2 nimh 2600mah.
The new release is based on Freeimu (from Fabio Varesano), a digital 9DOF that is working pretty fine (photo "2").
I inserted a diode on the +12v line that powers the motor driver.
The crappy battery that does not work is in the photo "3" ..I am now back on the simple pack of 10 1,2 nimh 2600mah, the system does not switch off but i cannot reach the "until oscillation occurs" (with Kd=0)..I believe that motors are not powered enough..
I'll try to build up another pack of 10 1,2 nimh 2600mah and put the 2 pack in parallel or try to order your same Lipo battery pack...
Any idea?
BYE,
Danilo
Ok 2 things is your sensor as close to your axles as possible?
And if you put Kp = 40 Ki = 1 and Kd = 8 in you robot does it stay upright I just need to know that.
yes, the sensor is close to the axis..
do You mean Kp = 40 Ki = 1 and Kd = -8 (!!-!!) ?
and what about K?
thanks
Hello guys
My second robot is starting to get ready but i think I will add one PID for each motor that will try to keep the setpoint speed in (deg/sec). To try to get the motors to behave as equal as possible.. Also have a fuzzy logic control to order the motors to compensate for the error in angle. What do you guys think about that? (One PID for each motor)
I also want to add a better calibration of the sensors then in my old one that was based a lot on Kas code. Something like needing to tilt it 180 deg laing it on the floor then making a sound and then tilting it -180 deg to the other side. Then calculate the calibration values from those two positions or letting the user hold the robot in some more positions may be?
I will post some pictures of my bot this week on my blog.. I also want to integrate a display and some pots for debugging with out the need of a GUI..
K = 1.9 and Kd = -8 Kp = 40 and Ki = 1 Try those values and if it does not balance well than something else is going on because at those values your robot probally will vibrate like hell but stay upright.
If it stays upright than you have got some starting point.
Btw what wheels are you using (diameter?)
And Patrick fuzzy logics will improve the bot a lot! but it's some pretty hard stuff to learn.
And if you use motor encoders than you don't really need to calibrate the sensor, because it will sort of self calibrate due to you taking the motor encoders into the PID Calculation.
When you look at it it is pretty easy to understand if your bot is wrongly calibrated and moves forward than you encoder count starts going up and will want to go back to zero. Eventually a balance will set in with the encoder PID compensating the wrongly calibrated sensors.
And displays are always usefull!
mY wheels: Pololu Wheel 90x10mm Pair - Black
no. it does not works with Your K set....
I think there is something wrong in Kalman even if the angle is whell evaluated, maybe it is a little bit slower than the real angle and this creates a phase problem... I am still investigating.
bye
Hi Timen,
could You please attach a print out of Serial Monitor (2 minutes is enough) while Your boot is up and stable (with no inputs from the wiimote) using this code within the loop:
Serial.print(ACC_angle, DEC); Serial.print(",");
Serial.print(GYRO_rate, DEC); Serial.print(",");
Serial.print(actAngle, DEC); Serial.print(",");
Serial.print(drive, DEC); Serial.print(",");
Serial.println(count, DEC);
I'll make a comparison with my datas to findout my problem...
thanks,
bye
OK, I find out the problem...I was using Serial.begin(9600); instead of Serial.begin(115200)...4 simple Serial.print used to debug were taking 40ms...Kalman was KO (the Kas Kalman code is expeting to be used every 10ms...).
Now the Bot can stay up, but I think PID parameters need to be tuned...
You can see the video... Two Whell Balancing Bot with FreeImu and Arduino - YouTube
Any suggestion?
bye,
Danilo
