thanks might!
thanks might!
the drift
Hey Simon, nice bot!
With regards to the drift you’re seeing, I had the exact same problem on mine. I think just relying on the imu sensor makes it very hard to keep it in balance. I ended up adding a velocity sensor, first by trying to use current sensors to measure the amount the motors were pulling, but found that wheel encoders gave a much better reference.
I have a vid here, if you’d like to check it out ->
http://www.youtube.com/watch?v=l0EFWTlT-BI
The project page I put up for it at zappedlab.com is sorely in the need of finishing, but there’s some details there on my parts list.
Best of luck with version 2!
Thats a very nice and
Thats a very nice and detailed bot you got there. It looks like its dead-stable as well! So good job.
I will make a wheel encoder on my next version so thats allready on my list 
Hopefully it will provide me with a more controllable platform, but I dont see how this relates to drift. Of course, once you know you’re moving you can regulate your PID, but I’m still conviced its possible to do this without the encoders soley based on temp/volt reference - since thats the place the drift is caused in the first place. Changes in temperature and volt drop.
That so so bloody stable! i
That so so bloody stable! i may venture into this after i finish my micromouse 
Try a gyro
may be a little more accurate then an accel.
What do you mean by that?I
What do you mean by that?
I use both a Gyroscope and an Accelerometer on this robot.
Very NICE!
This was a first project? Wow, very impressive! CONGRATULATIONS! It can balance! How cool is that?
Thanks for all the great documentation on this project. You’ve pointed the way for others to follow on building a balancing robot!
The drift - interesting to watch, it almost looks like it is overcorrecting a bit at each swing? Perhaps the Arduino doesn’t have the processing speed to put in a bit of correction before the error value becomes larger and it goes “oops, gotta fix that”? I don’t know. I would think 16Mhz on the Arduino clock is PLENTY fast enough. Perhaps some code adjustment on the PID error calculations, or a different filter algorithm? Floatpoint vs Integer math error? I imagine you have thought of all these and a hundred more things I haven’t even thought of. Anyway, good luckwith it. It will be interesting to see how you solve the drift problem!
Thanks for the great
Thanks for the great comment!
Documentation is part of the learning progress for me - so it has proven helpful to write about it. Nice to see that you appreciate it. During the progress of building this bot I realized there was alot of information on the internet, but it can be hard to find. Especially good information about use of Filters for non-mathematicians was time consuming.
Regarding your second point; yes its probably overcorrecting, but thats better then correcting to little. If you overcorrect too much it will cause robot to reach a angular velocity + angle which is impossible to re-gain balance from, and it will tip over. In my case its about finetuning the PID to gain a more stable robot. The “slow” correcting might be caused by motors as well. Motors will first turn after a certain amount of volt so in a case where you need very little correcting it sometimes is hard to find a good balance of variables. My PID updates every 0.02sec so that should be plenty, but in my next version I will try to increase the calculation speed by adding a 20Mhz clock and saying “when ADC is ready, update PID”. Especially the gyro has a very good presicion which can be improved i think. I havent done exessive testing on the floating point versus integer math, but the margins between balance and not balance are so small that I cant imagine it to be a good solution to drop the presicion further.
The drift is caused by voltage drop over the power lines, btw. so that has nothing with the above to do I will not fix that on my current robot - instead i’m building a new and better one.
BTW, I just realized you
BTW, I just realized you might have meant the drift i got due to the use of the Kalman filter. Which of course is a completly different subject then what i answered in my first reply. sorry for that.
Good job
A balancing bot is not in my plans, but am impressed. I agree you cant peat plexaglass. Old Ebay erector sets are also priceless. Can those things actuallt stand up without driving them around (auto mode)? Just curious. I have not seen many of those types.
I’m not sure if I understand
I’m not sure if I understand your question. What do you mean by Ebay Erector(vintage toy’s?) and what did you mean by stand up without driving? What is supposed to stand up. If you mean balance standing still, then yes its possible, but small bumps on the floor and things like that will make it move abit, unless you have a very good algorithm.
Nice project
Hi Simon
Very nice and well documented project
I did make a balancing robot during my Parallax Basic Stamp time: http://forums.parallax.com/forums/default.aspx?f=21&m=270511 , using an ultra sonic sensor.
I downloaded your code, but the PushButton.h file is missing. Can you direct me to this file ??
Did you experiment the wheel encoder feature ??
How do you plan to combine this additional info with the gyro/acc signal ??
Greetings from Grenoble, France
yves
Haha,That robot of yours
Haha,
That robot of yours sure looks funny
The PushButton.h file you are refering to is just a library to control the use of simple pushbutton. I uploaded it, but you really dont need it to control the balancing algorithm. Anyway, here’s the link
I’m working on a new balancing robot with wheel encoder. I havent looked at how to create the new source code yet, but will probably expand the PID somehhow. So cant say much at this point.
Thanks for the kind comment, though. Happy you liked it!
Simon.
Thanks Simon
Thanks for the good words and the link
I really beleave that backlash is a major issue for balancing
I plan to use Dynamixel AX-12 servos:
- high torque
- serial connection
- continuous mode
- built-in encoder
more infos: http://www.trossenrobotics.com/dynamixel-ax-12-robot-actuator.aspx
Arduino library: http://forums.trossenrobotics.com/tutorials/how-to-diy-128/controlling-ax-12-servos-3275/
additional comments from Nathan: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1225283209
Simon, is your code up to date ??
(I noticed RAD_TO_DEGREE in protobot8261.pde translates to RAD_TO_DEG in parameters.h)
Please advise
Best regards
Yves
Not sure why the
Not sure why the inconsistency in the code.
I dont have the possibility to test it now since I’m short on SN754410NE’s and had to use one which was attached to the bot. In the v2 bot I’ll be programming directly to the AVR(ATmega328p) to get better control of what is happening and maybe increase the speed and precision of the calculations. It is still some time in the future till i’ll be capable of doing anything there – as I need to work on the hardware side first.
My new hardware will hopefully help on the backslash as well. I’ll create a new robot page for that soon™.
This robot is, for the moment, only part of spontanious updates. So thanks for the interest, but sorry for the short answers. Hope to see your new project on LMR
Regarding the servo
Sure torque is important, but speed is as well. I’m not sure those servo’s you are linking are fast enough.
They list 0.196sec/60° which is the same as 1.176sec/360° or 51RPM at no-load 10v. I’d look for something fast if i were you.
Hi Simon
To compute tilt angle, you use the X axis Gravity composant, via aSin.
You may already know that using the projection on both X and Y (via aTan), tilt angle is obtained for the complete 360° interval. Please see this video (Acc only, with basic signal processing) http://www.youtube.com/watch?v=CUC7O58g4rY
I am convinced that the Arduino 10 bits ADC is less than adequate for this application; a 90° rotation is described by only 102 ADC units. A balancing robot will typically fluctuate ±5° from vertical, all control has to be implemented based on only 10 ADC units variation.
I plan to add a separate 12 bits MCP3208 ADC, possibly with a pseudo differential input configuration in order to have a zero based signal.
http://ww1.microchip.com/downloads/en/DeviceDoc/21298D.pdf
Imu mounting
Hello,
ADXRS401 gyro is yaw axis gyro, but like I see in pictures you mount it like pitch axis gyro. So looks like you are using only accsel for tilt calculation…
Second mount imu on the bottom of bot, coz now you are measuring falling bot acceleration.
Here are mine simple balancing bot http://www.youtube.com/watch?v=QQklpBy6s7Y , it uses old and very low sensitivity murata gyro, 0.67mV/deg/s so its more than 3deg per ADC tick and looks like mine bot is more stable than yours.
Looks good
Looks good but not much different then the last video. Just back and forth?
You’re right about the imu
You’re right about the imu mount. It should have been lower. I’m fixing that issue in v2.
Both gyro and accel are used in current tilt measurment.btw.
Nice robot you got there. Yep, think yours is more stable then mine.