Shop OBEX P1 Docs P2 Docs Learn Events
PWM - compensate for variances between 2 motors — Parallax Forums

PWM - compensate for variances between 2 motors

Ron CzapalaRon Czapala Posts: 2,418
edited 2011-05-17 21:00 in Robotics
I am trying to figure out how to make my robot move in a relative straight line. It seems that even though the motors are "identical", the robot veers hard to one side. (I know rotary encoders providing feedback to the MCU are the best method, but hope to compensate thru program code.)
I tried switching the motors on the Dual MC33926 Motor Driver Carrier and connected the inputs for both input channels together to make sure the difference was in the motors, not the H-Bridge driver module.

The robot is described in this forum topic Homemade StingRay.
I am using a simple BS2 program to ramp up/down the motors to just move forward, pause, and backward. I tried increasing the Duty value for the second motor but it doesn't make much difference.
Any suggestions would be appreciated...
bs2
bs2
ZapBot2.bs2
2K

Comments

  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-10 12:27
    You basically have two choices:

    1) add an encoder of some type

    -OR-

    2) set both motors at 50% duty cycle

    3) let it run for 10 feet, measure the difference of where it ended up compared to a straight line

    4) if significantly off a straight line, use the difference to increase or decrease the duty cycle on one of the motors, goto 3

    5) now you should have settings for a straight line; and you should be able to increase/decrease the "default" by the same % to go faster/slower more or less straight

    I am building the above algorithm into my RoboProp boards firmware.
  • kwinnkwinn Posts: 8,697
    edited 2011-05-10 13:26
    Bill Henning wrote: »
    You basically have two choices:

    1) add an encoder of some type

    -OR-

    2) set both motors at 50% duty cycle

    3) let it run for 10 feet, measure the difference of where it ended up compared to a straight line

    4) if significantly off a straight line, use the difference to increase or decrease the duty cycle on one of the motors, goto 3

    5) now you should have settings for a straight line; and you should be able to increase/decrease the "default" by the same % to go faster/slower more or less straight

    I am building the above algorithm into my RoboProp boards firmware.

    This is a good approach to compensating for motor differences. If the difference is not linear you may need to have % values for several speeds and extrapolate between those points.
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-10 13:48
    Thanks, and I agree that multiple reference values are a better approach.

    For my RoboProp firmware, I intend to make an array (potentially for 1..100%) to store the offset value, but 10%/20%/.../100% should suffice, with linear interpolation between the steps.
    kwinn wrote: »
    This is a good approach to compensating for motor differences. If the difference is not linear you may need to have % values for several speeds and extrapolate between those points.
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-10 16:44
    Bill,
    Thanks for your suggestions - I will experiment some more.

    Do you think the reference points will be affected by the battery level?
  • prof_brainoprof_braino Posts: 4,313
    edited 2011-05-10 18:13
    How much can be attributed to the mechanic tolerances of the device?
    The kids in the robot club said "two motors never just go straight, you have to steer."
    We found wheel alignment, motor coil resistance variation, uneven surface, defect in the tread, and contamination on the test area all affect "strainghtness".
    The result was a standard assumption that the robot will not go straight when you want it to, some feedback for steering must be provided.

    If you find to the contrary there a bunch of kid with Legos that will be interested :) .
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-11 13:25
    Hi Ron,

    You are most welcome.

    I'd first ignore the battery level, get it going straight with a full charge... then test at different battery levels.
    Ron Czapala wrote: »
    Bill,
    Thanks for your suggestions - I will experiment some more.

    Do you think the reference points will be affected by the battery level?
  • Bill HenningBill Henning Posts: 6,445
    edited 2011-05-11 13:26
    Totally agreed - but using calibration like above, or better yet, wheel encoders, can keep robots (mostly) on a straight line :)
    prof_braino wrote: »
    How much can be attributed to the mechanic tolerances of the device?
    The kids in the robot club said "two motors never just go straight, you have to steer."
    We found wheel alignment, motor coil resistance variation, uneven surface, defect in the tread, and contamination on the test area all affect "strainghtness".
    The result was a standard assumption that the robot will not go straight when you want it to, some feedback for steering must be provided.

    If you find to the contrary there a bunch of kid with Legos that will be interested :) .
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-11 14:01
    I placed the Parallax Absolute Binary Rotary Encoder on the breadboard a created a program to start with a base PWM duty value of 170 - it was unstable at lower values.

    Setting the encoder from 0 to 15 (0xF) and hitting the stamp reset let me change the speed for a short run.

    The best results were setting the PWM Duty value of the slower motor 7 higher than the faster motor.

    The are differences between repeated runs at the same speed - for various reasons I'm sure, but
    adding sensors to detect objects and change direction seems more practical now that I can get it to move relatively straight...

    This video shows two runs at different speeds:
  • ercoerco Posts: 20,256
    edited 2011-05-12 00:24
    Nice bot! Despite all your efforts to calibrate a straight line or precision turn with multiple variables (speed, battery voltage, rolling surface carpet/tile/concrete, etc), you'll never get it totally right without encoders. You can make inexpensive encoders yourself; I've had good success and made a few posts on the subject.
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-12 06:27
    erco wrote: »
    Nice bot! Despite all your efforts to calibrate a straight line or precision turn with multiple variables (speed, battery voltage, rolling surface carpet/tile/concrete, etc), you'll never get it totally right without encoders. You can make inexpensive encoders yourself; I've had good success and made a few posts on the subject.

    Thanks erco! I found your thread on making your own encoders but it looks like the Hamamatsu P5587 is discontinued and similar components are hard to find.

    Do you know of any place to get them or an alternative?

    I may just spring for the Pololu motors with the Hall effect encoder

    Your video with the laser pointer was pretty neat.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-05-12 09:18
    That's not a bad combination, but the motor efficiency is abysmal. At 5A stall you'll be spending more money on the H-bridge than necessary. Prices jump when going from 1A or 2A to 5A. The MC33926 can do 5A peak, so you may be okay with what you have.

    I guess they went with their highest torque motor. They offer a similar motor with slightly lower torque, but a lot lower stall current. Assuming your platform can handle the lower torque, I'd advise getting that one instead.

    -- Gordon
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-12 09:55
    GordonMcComb wrote: »
    That's not a bad combination, but the motor efficiency is abysmal. At 5A stall you'll be spending more money on the H-bridge than necessary. Prices jump when going from 1A or 2A to 5A. The MC33926 can do 5A peak, so you may be okay with what you have.

    I guess they went with their highest torque motor. They offer a similar motor with slightly lower torque, but a lot lower stall current. Assuming your platform can handle the lower torque, I'd advise getting that one instead.

    -- Gordon

    The MC33926 has an analog current load feedback output pin that lets you detect a current overload.

    The Pololu 12V motors all have a free-run 300mA and 5A stall (not sure what moter you are referring to)

    My bot weighs over 9 lbs so I don't want to underpower it.

    The current wheel/motor combo - Pololu 90mm (3.54") wheels at 310 rpm gives 4.8 ft/sec.

    I just ordered 4 7/8" BaneBot wheels (same as StingRay) from Trossen Robotics.

    I also ordered the Pololu 50:1, 200 rpm motors (170 oz/in torque) with two-channel Hall effect encoder

    That wheel/motor combination should give 4.25 ft/sec with 170 oz/in torque vs. the current 110 oz/in.
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-05-12 11:48
    You're right that at 9 pounds you probably don't want lower torqued motors.

    Looks like a good combination. How will you be reading those encoders?

    -- Gordon
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-12 12:52
    GordonMcComb wrote: »
    You're right that at 9 pounds you probably don't want lower torqued motors.

    Looks like a good combination. How will you be reading those encoders?

    -- Gordon

    Pretty sure a Propeller is the way to go. Especially when I add object detection sensors -
    I have some Sharp GP2Y0A02YK0F Distance Measuring Sensors (20 to 150 cm) and some Pings.

    I guess I can use a cog for PWMing each motor and a cog to read each encoder.

    Better start researching the OBEX...
  • ercoerco Posts: 20,256
    edited 2011-05-12 15:28
    Ron: Yes, my beloved 5587's are discontinued and I'm quite despondent about it! They are a tiny, tidy package and quite useful. I'll have to seek a replacement. An email from Junun said they are also out of their Fairchild optosensor, http://www.junun.org/MarkIII/Info.jsp?item=14

    The Sharp IR distance measuring sensors are being phased out, too. Stock up now!
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2011-05-12 16:22
    erco wrote: »
    The Sharp IR distance measuring sensors are being phased out, too. Stock up now!

    What I'm hearing is that they have a newer series of smaller and less expensive PSD-based sensors, but they are currently "not available in North America" so as to clear out the gray market channel. Pololu is selling one or two of the units marked as not available in the US, so apparently they're getting them somehow.

    The new sensors are digital only, have a 300 Hz refresh rate (as opposed to the ~20 Hz of the older version) and use much less current. Not sure if they plan on bringing back any analog sensors in this style, but I'd think they would.

    These sensors seem to be an important part of Sharp's IP portfolio. I'd be really surprised if they disappeared altogether. It would be a shame if they didn't, unless Sharp sells or licenses their patents.

    -- Gordon
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-12 16:27
    erco wrote: »
    Ron: Yes, my beloved 5587's are discontinued and I'm quite despondent about it! They are a tiny, tidy package and quite useful. I'll have to seek a replacement.

    erco,
    Check out this Honeywell HLC2701 sensor - does it sound like a comparable sensor based on youe experience with the 5587?
  • ercoerco Posts: 20,256
    edited 2011-05-12 17:21
    Looks like a great sensor. Where did you find it & how much?
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-12 18:21
    erco wrote: »
    Looks like a great sensor. Where did you find it & how much?

    DigiKey $4.42

    Mouser $2.83

    It needs a separate IR emitter though...
  • Ray0665Ray0665 Posts: 231
    edited 2011-05-17 12:21
    My first bot was basically a tricycle, the drive wheels were on a common shaft steering was via servo controlled rear wheel. It had no problem going straight.

    With differential steering / drive it is a different story altogether. The most common method is a PID drive which of course requires encoders and some type of feedback.

    There are also other more "interesting" methods such as line following or wire guided that can keep you on the straight and narrow.
  • Ron CzapalaRon Czapala Posts: 2,418
    edited 2011-05-17 21:00
    Well, I received my new 50:1 12V motors with two channel Hall effect encoders from Pololu.

    If I just monitor one channel I will get 800 pulses per wheel revolution (16 per motor shaft revolution).

    Since the wheels are roughly 15.3125 inches in circumference, I would get about 52 pulses for each inch the wheel rolls.

    If I monitor both channels as a quadrature encoder setup I would get 3200 pulses per wheel revolution but I can't imagine needing that much precision.

    I found OBEX objects for quadrature encoders but haven't tried them yet...
Sign In or Register to comment.