I was under the impression that Lynxmotion motor could be plastic gears and have been searching for “motor+metal gear+encoder” Sofar, my best hit is: http://www.pololu.com/catalog/product/1444 12V, 200RPM, 300 mA free-run, 5A stall, 170 oz-in (12 kg-cm) 3200 counts per rev (gearbox’s output shaft) any comment on this one ??
Finally, I did reviewed your code, and have some comments last_vrDist and vTurn are always zero and vTurnR = vTurnL = vTorque I beleave that in Calculate_Speed(), “last_vrDist = 0;” should be "last_vrDist = vrDist;" Please confirm that above source code is working "as is"
Hi Yves, I did almost the same balancing bot you did, but I used a Roboduino microcontroller (see it here). I came out to the same conclusion: the servos are too slow to recover from more than a few degrees unbalance. I remember the Legway robot by Steve Hassenplug that was using Lego motorcycle wheels (82mm diameter) mounted directly on Lego geared motors (300 RPM free run). That one could get up by itself, so I was thinking getting a faster motor, something around 350 RPM, like this motor . I was also looking to get the hubs and perhaps this motor driver. I might go for a Sabertooth 2x5, still debating. But anyway, there will be some time until I can order the parts and actually build the thing.
I also heard people built a successful balancing robot using these motors and controller but it seems too expensive for me.
I am also looking to find quiet motors for my balancing robot, so planetary motors are out of the question, as they are the noisiest motors (thing of a couple of cordless drills running around in your house…). But I intend to build a bigger balancing robot that will use scooter or wheelchair motors that are quiet enough for my taste. If so, I can swap the 2x5 Sabertooth with a beefier version and keep the same controller and code.
So, good luck with your project, I will follow it with great interest!
Also have a look at this impressive video: http://fr.justin.tv/hackertv/b/259330753 (first 45 seconds) This balancing bot is powered by AX-12 dynamixel digital servos which are claimed to have zero backlash A new faster, more powerfull AX-18 has been recently launched
I am balancing (no pun intended) between the 350 RPM Pololu motor and the AX-18
@Dave Please answer the code and wheels diameter questions in my last post
@ Ro-Bot-X I wish good luck with your bigger project; why would you choose the Sabertooth vs Pololu 14A motor driver,??
I checked out your link and your first attempt looks better than my first attempt… hehheh… As for the wheels, yes those are the ones I have… I would believe that larger diameter wheels would help, another thing that I think would help greatly is if you could find a really soft rubber or inflatable wheel that you could run half flat to increase the friction between the motors and the floor… I was going to try that one myself, just havn’t had time…
As for the motor that looks the same as the ones I ended up using, again they do work but it is kinda dangerous to try.
I don’t have the code on this computer so I will verify that I didn’t post the wrong code but I am 98% positive that it was the complete working code from the video…
I honestly have no idea how noisy planetary motors are as I don’t have any… The ones from the link look great but are a bit pricey…Also 24V supply would have to power the motors only and a separate power supply for the microcontroller or a v regulator. But those would work well and you could probably work on a larger project yourself…
I tried to answer your questions below and again I will get back to you on the code. Keep in mind the vrDist is only for the encoders and it will balance without it… I would recommend you don’t even use that part untill you get your PID tuned as that will for sure be different than mine… Good Luck…
Ok to start with the balancing and the compensation of the wheel encoders are very much trial and error… I have built a few balancers using different filters for the balancing but the same problem always exists and that is tuning the PID… This can be extremely time consuming so to assist I highly recommend you add 3 pots to your design and use those to dynamically tune the PID settings… Get your robot to balance as perfectly as you can before you consider adding in the complication of wheel encoders…
With that said basically I read the encoders using interrupts, then I use that info to calculate a number to indicate speed every 50ms… I didn’t try a calculate km/h or m/hr or f/s I just wanted a number that I could work with that represented speed… Then I use a PD calculation to stabalize the readings. From there I mapped it to a more usable range. After that I simply incoporate that into my angle calculations…
So after you have a balancing robot, you will notice that it will tend to drift accross the floor, or if you were to put it on a ramp it will balance but roll down the ramp. Much like a person to compensate for a ramp you would lean into it in order to balance in one place. So the accel/gyro can tell the robot we are standing up straight and balancing, but the wheel encoders tell the robot we are moving in one direction constantly so let’s take the angle from the accel/gyro and add a bit more too it untill we aren’t falling down the ramp…
Hi, thank you for the reply, this is what I noticed also, the robot is balancing but the problem is it tilts a little in one side ( the motors have backlash) then starts to run away at the direction of that tilt while gaining speed also. Can this be solved by a wheel encoder or should I change to a zero backlash motor?
Without seeing a video of your design I am not sure how bad your motors are but that is kind of a common issue… I would recommend you adjust vSetpoint untill you get it as close as possible… Then yes the wheel encoders will definitely correct that when you get the speed PID tuned properly… The best thing to do in the beginning is to run it on a carpet, this creates a bit of friction which really helps when tuning the PID’s…
I am very familiar with this one… In fact that is how I found this site in the first place… I had actually in some of my earlier designs used some of his code for the Kalman Filter… Kudos to that guy as he did a great job… Thanks for the link…
From the code above, I am just wondering how you extracted the angle from the gyro and accelerometer, the gyro output is v/degree/sec while the accelerometer is v/g how did you extracted the angle not using trigonometric functions?
Honestly I an just using 1 axis of the accel… I zero it for the balance point and use the number that comes from reading the analog pin … I know there is a trig function using 2 axis of the accel which would probably be alot more stable but I didn’t really need it as I just use the accell to correct the gyro… Hope this makes sense…
>> I beleave that in Calculate_Speed(), “last_vrDist = 0;” should be “last_vrDist = vrDist;” >> Please confirm that above source code is working “as is”
>> I don’t have the code on this computer so I will verify that I didn’t post the wrong code >> but I am 98% positive that it was the complete working code from the video…
Hi Dallaby,
Please confirm that above code is the latest (working) version
Ok so I looked back and I do have a newer version of the code that added the R/C part… The rest is pretty much the same… As I said at the top of the post I hadn’t cleaned up the code so there are some things in there that could be removed… Please see below and I hope that helps clear this up…
void Calculate_Speed() { if((millis()-lastBalupdate) >= myBaldt) ----- Only attempt to calculate the speed every 50 millis() { lastBalupdate = millis(); ------ Reset the timer variable for sampling
vrSpeed = vrDist - last_vrDist ----- This line should be changed to vrSpeed = vrDist to assign the current encoder count to vrSpeed vrSpeed = (vrSpeed / myBaldt); ---- I am trying to calculate a velocity value more than a speed vrSpeed = vrSpeed * 15.5; ---- Again I just need a number to represent velocity that I can work with
last_vrDist = 0; ---- Can delete vrDist = 0; ---- This resets the vrDist value to ensure if the wheel stops then the velocity is set to 0
sPterm = vrSpeed * sPgain; ------P sIstate = (sIstate + vrSpeed); ------I can be deleted as I only used the P & D part sIterm = sIstate * sIgain; ------more I as above can be deleted as it wasn’t required sDterm = (vrSpeed - last_vrSpeed) * sDgain; ------D if you aren’t sure how or why this exists please read up on PID loops
last_vrSpeed = vrSpeed; ------set last speed variable to current
vrSpeed = 0.0; ----- reset the vrSpeed variable for next time
vrSpeed = sPterm + sDterm; ----- incorporate the PD calculations
vrSpeed = map(vrSpeed,-400,400,-30,30); ----- map the results to a more usable range
vAngle = vAngle - vrSpeed; ---- use the calculations from the encoders to adjust the balance point of the robot… } }
I really hope this helps to clear this up… If you have any questions as always please let me know…
I am very impressed by the compactness of your core code, especially Complimentaryfilter() and Calculate_Torque() Can’t wait to give it a try I ordered from Pololu: 2 x #1443 29:1 Gearmotor with 64 CPR Encoder (350RPM @ 12V) 1 x #708 Dual VNH2SP30 Motor Driver Carrier MD03A 1 x #1083 Pololu Aluminum Mounting Hub for 6mm Shaft pair 1 x #1084 Pololu metal Bracket pair 1 x #1435 Pololu Wheel 90x10mm pair 1 x #1430 Pololu Wheel 80x10mm pair
Thanks for your help in reentering this “fight for Balance”
