Shop OBEX P1 Docs P2 Docs Learn Events
Alternative solutions to ARLO encoders — Parallax Forums

Alternative solutions to ARLO encoders

Hi,
I sent an email to parallax support, after the first answer i felt misunderstood , i'll wait for more feedback meanwhile if someone wants to help...
ARLO ENCODERS: 
144 tick per revolution encoders are very rough for robotics, mechanical flywheels that sort of just grabs onto the drive shaft, the encoders never really sit perfectly in the opto-isolator channels, which may cause collisions and damage to the encoders during general movement (you can use glue)
One solution can be measure the clock time between the encoder ticks, less time more speed, but unfortunately does not work (i tested) the flywheels are not fixed, are not equal, when reading the delta time values are not consistent, and is easy to guess why light is interrupt by different angles or different breaks.
Real life example:Unless you live in a empty mansion, you don't run the robot at high speeds, special if you are processing the visual environment, at 0.1 meters per second the arlo encoders output are 30 ticks per second.
To drive straight using differential driving both motors need to be sync.
One easy way is to calibrate the motors (e.g.: Andy Linsey Activity Bot calibration code), the calibration per se is not enough when there are other dynamic variables: different floors (carpet, cement) and the variable robot weight/load.
The solution is to implement a PID algorithm, to be successful you ll need to run the PID quickly as possible e.g. 30 hz, that it allow to adjust the motor power to reach the desired and correct speed.
With 30 ticks per second, and running a PID @ 30 hz there are not enough ticks to implement something like that.
Right now i'm running a 4 ft robot with an Activity Bot encoders... it's surreal 
good motors deserve some hall effect encoders, not fragile/unstable flywheels...
Possible solutions:
1) Parallax’s motor supplier alternative model with high encoders built in (only parallax will know, that was one of the question i asked the support).
2) Crazy idea: Attach a metal sprocket to the motor axle (where the flywheel is attached) and a metal chain to an external motor with a high resolution encoder (e.g. #28819) and use the second motor encoder.
Comments, ideas please.
Regards,Tiago 



Comments

  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-07-09 02:33
    What are you trying to do with your Arlo hardware which you can't do now?
    I plan to revisit the encoder software sometime soon to get rid of the little bit of hunting for final position but I think the encoders work pretty well with the present Eddie firmware.
    Here's the video from this post in the Eddie Firmware thread.


    How where you timing the intervals between encoder ticks? My "experimental" Eddie code times the interval between encoder ticks as well as full encoder cycles. IIRC I didn't have a lot of luck when trying to compute speed from individual encoder ticks but if I averaged a few intervals the speed precision and accuracy was pretty good.
    I'll review my code and try to post some numbers of the accuracy I was able to achieve.
    As I said, using intervals to compute speed is part of my experimental code. It's not part of the Eddie firmware right now.
    Edit: I just watch the video again and I disagree with myself 3:08 when I say "that's as good as it's going to get." I think I can improve on this performance.
  • Duane,
    I don't have problems counting the encoder ticks, before i used an external chip to decode the quadrature signals, recently i moved the decoding to the Propeller, it's not a high resolution anyway.
    When i measured the clock ticks between ticks, it was an alternative test to implement a different PID not based in delta ticks.
    I counted the difference between transitions in a single phase, the values reported where irregular 120 180 140 170 something like that, i understand the reason: the encoders are optical, and the intervals are not regular, or not 100% aligned (wobbling) .

    what i want is to drive straight line, not going little bit to the left or right...
    the pc sends a command to the propeller:
    drive 30, 30
    the propeller should run both motors at 30 ticks per second, more or less 0.1 meters per second speed, does not matter if i sent ticks or meters, i can send something like
    drivem 0.1 0.1
    to achieve that purpose, i run an initial calibration to determine the relation between wheels/power/ticks, and i store those values in the eprom.
    When i receive a drive command the propeller matches the ticks/power for each wheel, another cog is running the PID, monitoring the encoders delta values, versus the desired result, here is where lays the problem. 

    If i have 30 ticks per second, and if i want to run my PID at 30hz, 30/30 = 1 or 0 ticks per interval,i don't have enough ticks to adjust the power.
    does not matter the calibration, because the robot will carry different loads or will alternate between carpet or cement floors, the voltage also will change during the time.
    if you don't have a PID:you cant adjust the 0.1 meters for different floors, in a carpet floor the robot is slow, in a cement is faster.you can't stick to a straight path because you re not dynamic adjusting the power
    If you have a PID implementation that can run at slow rates 2,3 Hz, please let me know. 


    Tiago
     


  • what i want is to drive straight line, not going little bit to the left or right...

    the pc sends a command to the propeller:
    drive 30, 30
    the propeller should run both motors at 30 ticks per second, more or less 0.1 meters per second speed, does not matter if i sent ticks or meters, i can send something like
    drivem 0.1 0.1



    I feel like I can already do these things.
    I added code to light up LEDs based on how many ticks one wheel was in front of the other. I then had the robot drive the same 1 meter by 2 meter course to see how closely the distances travelled by each wheel matched with the other. When the robot was travelling in a straight line at "normal" speeds the encoders stayed within one encoder tick of each in distance travelled.
    I thought the robot's path was very straight.


    If i have 30 ticks per second, and if i want to run my PID at 30hz, 30/30 = 1 or 0 ticks per interval,i don't have enough ticks to adjust the power.



    Yes, this is what I'm not happy about with the present firmware.
    The present firmware calculates the speed based on the number of encoder transitions over half a second. This is fine for relatively fast speeds but this is too sluggish a response with really slow speeds. I'm pretty sure this is why my robot tends to overshoot the target position by one or two ticks and has to "hunt" for the exact position at the end of each segment.
    While I agree this could be improved, I disagree the current hardware won't allow good (or even excellent) precision.  

    if you don't have a PID:
    you cant adjust the 0.1 meters for different floors, in a carpet floor the robot is slow, in a cement is faster.you can't stick to a straight path because you re not dynamic adjusting the power
    If you have a PID implementation that can run at slow rates 2,3 Hz, please let me know. 

    The present Eddie firmware does use a PID algorithm.  I've only tested my robot on carpet but that's mainly because I didn't want to get it dirty by driving it outside on the concrete (and when I was testing the robot there was snow outside). I'd be very surprised if the robot didn't perform equally as well on concrete.

    One of my motors draws more current than the other. Parallax sent me a replacement motor but so far I have continued to use the one which draws more current so I can test the code with unequal motors. The program needs to drive one of the motors with more current in order for the robot to drive in a straight line. I think the program is doing its job well.
    As I mentioned, I think there's room for improvement but the code works so well in its present state, improving the code hasn't been a high priority.
    To drive the two meter section of the rectangle, the command "MM 2000 50" was given. This command told the robot to drive 2000mm at the speed of 50. I don't recall what the units of speed are in.
    The command "DECIN 1" had previously been given to change from hexadecimal input to decimal input.
    I'm not sure what you mean by "slow rates 2,3 Hz". Is this rate the number of encoder ticks per second? If so, no I don't have an implementation to control the robot at such slow speeds.
    The video I posted shows what sort of test I used to see how the robot behaved. I thought the robot worked well. What sort of test would you like to see to show the robot working well (or not)?
  • Duane, 
    Let's compare apples with apples, if you do tests please use slow speeds:
    for 0.1 meters, with arlo wheels is equivalent of 30 ticks per second (quadrature readings 144)
    Running a PID at 1 HZ means you check the PID only once, 2Hz 2 times per second etc.
    In another robot (not parallax hardware) i had the PID running at 30 Hz, this means 30 ticks / 30 = 1 or zero ticks.
    If is only possible to run the PID at 5Hz it will be 30 / 5 = 6 ticks per interval.
    what is the frequence of your/eddie PID algorithm ? 
    Tiago

  • Duane,
    I took a quick look at eddie.spin, but spin is almost chinese for me ;) 
    I'm trying to navigate.... in the spin code some questions:
    Does eddie needs calibration ?
    PID Frequence ? It seems half a second = 2Hz not sure ...
    CONTROL_FREQUENCY variable what's the purpose 

    what is speed unit in the eddie firmware (ticks per second?)
    PID choice : Do you know how it works ?
    Tiago 
  • Looking to Eddie schematic board, a raw H Bridge in Eddie versus the Arlo's HB25. 
    I think H bridge is much more cleaner and less prone to problems, i end up attaching a relay to each HB25 to reset when they are stuck/off, plus a single spike in the hb25 wires, makes the HB25 spining without the propeller in command... 
    i don't know how to solve those involuntary movements, the relays are only used to reset, by default they are always connect, i could wire them NC, and connect them to ON when the propeller is in charge, but i don't like the idea of having the coil always on to drive the HB25.  
    Tiago
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-07-09 09:06
    Duane, 
    Let's compare apples with apples, if you do tests please use slow speeds:
    for 0.1 meters, with arlo wheels is equivalent of 30 ticks per second (quadrature readings 144)
    Running a PID at 1 HZ means you check the PID only once, 2Hz 2 times per second etc.
    In another robot (not parallax hardware) i had the PID running at 30 Hz, this means 30 ticks / 30 = 1 or zero ticks.
    If is only possible to run the PID at 5Hz it will be 30 / 5 = 6 ticks per interval.
    what is the frequence of your/eddie PID algorithm ? 
    Tiago



    I realized after I had gone to bed I hadn't mentioned the PID frequency. The power to the motors is updated at 50Hz but the current speed is determined comparing the present encoder value with the encoder value from half a second earlier.
    Here are a few applicable constants:  CONTROL_FREQUENCY = 50 ' Iterations per second  HALF_SEC = CONTROL_FREQUENCY / 2    POSITION_BUFFER_SIZE = CONTROL_FREQUENCY / 2
    There's a buffer keeping track of the last 25 encoder totals:  long motorPositionBuffer[2 * POSITION_BUFFER_SIZE]

    So even though the PID runs at 50Hz and the speed is computed at 50Hz the encoder reading to determine the speed was from half a second earlier. This strategy of measuring speed works fine at "normal" speeds like the speed my robot travelled in the video but as you would guess this strategy doesn't work well at low speeds when there are very few encoder ticks in a half second time interval.
    While the 144 transitions per revolution will limit how precisely the speed can be measured at low speeds, I think there is a lot of room for improvement in the Eddie firmware in this regard.
    I've debated between using a two different algorithms to compute speed. One for high speed and one for low speed. I'm not sure if I'll end up doing this or not. I hope whatever method I use to compute the speed when the robot is moving slow would also work to compute faster speeds. I know I've experimented with this but I was not satisfied with my low speed motor control. I hadn't worked much on trying to get precise low speed movement because I felt like the code was working well enough in its present state and I felt like I had met the goals (including stretch goals) stated by Ken Gracey for the Open Halloween Hex up and running.
    I wrote an object which will monitor an arbitrary number of quadrature encoders and drive the same number of motors with PWM. This object uses PASM to capture the time of the encoder ticks so it's pretty accurate. The object records the time of for both individual ticks and full encoder cycles. I had planned to experiment with using these different intervals to see which interval produced the best low speed measurements. I think the hard part of writing better low speed control code has already been done I think the main difficulty will be in tuning the PID parameters. As I look at the code "EddieAbExperimental.spin", I recall one of the next steps I had planned was to scale the speed variable to better reflect the improved precision of the new speed calculation.
    Computing speed from the interval between encoder ticks is challenging when using integer math. There are lots of opportunities for overflow errors. I believe I have these challenges overcome.
    The method "ComputeEncoderSpeed" computes the speed using several different techniques. I haven't decided which technique is best. The various options include measuring the time between individual encoder ticks, measuring the time of full encoder cycles or measuring the interval of half cycles. Measure half cycles and full cycles reduces the errors introduced by differences in sizes of the slots and the spokes of the encoder.
    There are a number of commands to modify PID parameters. This should allow the PID to be tuned while the robot is running.
    I would like to see how well I can get my robot to travel with very low speeds but it may be a few days before I have time to work on this.
    Back to your "apples with apples" test. 30 ticks per second should be the same as a speed of 15 using the Eddie firmware. 30 encoder ticks should cause my robot to travel 0.1023m (3410um per tick).
    The constant used to calculate the conversion between millimeters and encoder ticks is "MICROMETERS_PER_TICK" (3410 for my robot).The constant used to convert between encoder ticks and how much the robot has turned is "POSITIONS_PER_ROTATION" (748 for my robot).Rather than trying to determine these values based on features of the robot, I determined these values indirectly by seeing how much the robot actually moved with given commands to drive straight or to turn in place.
    I believe the speed used when making the video was 50 which is 25 encoder ticks per second.
    What kind of course would you like to see the Arlo hardware capable of performing? What distances and what speed? I could be persuaded to test my robot outside if you want to see a larger test pattern.
    I'm pretty sure the surface material won't affect the speed of the robot much but it might affect the robot's turning characteristics. I came up with the 748 ticks per revolution by having the robot spin in place. I had the robot spin in place ten times. If the heading of the robot after spinning in place 10 complete revolutions was different than the heading prior to the robot's spinning, I'd adjust the value of "POSITIONS_PER_ROTATION" and try again. The value of "POSITIONS_PER_ROTATION" should equal 2 * pi * distanceBetweenWheels.  The value of "distanceBetweenWheels" needs to be in units of encoder ticks.
    Hopefully I answered the questions in the post I just quoted. I'm not sure if I'll answer other posts tonight or wait 'til the morning to do so.
  • what is speed unit in the eddie firmware (ticks per second?)

    PID choice : Do you know how it works ?

    The other questions in the above quoted post were answered in my earlier post.The speed used by the Eddie firmware is ticks per half second.I think I understand the PID algorithm. If I understand it as well as I think I do, there isn't a D component to the algorithm. The algorithm initially just used P but I added the I component. I'm not thrilled with the current PI algorithm. I think improving the performance of the algorithm will likely require measuring speed from encoder tick intervals.
  • Looking to Eddie schematic board, a raw H Bridge in Eddie versus the Arlo's HB25. 
    I think H bridge is much more cleaner and less prone to problems, i end up attaching a relay to each HB25 to reset when they are stuck/off, plus a single spike in the hb25 wires, makes the HB25 spining without the propeller in command... 
    i don't know how to solve those involuntary movements, the relays are only used to reset, by default they are always connect, i could wire them NC, and connect them to ON when the propeller is in charge, but i don't like the idea of having the coil always on to drive the HB25.  
    Tiago


    I don't have the problems you mention. I think the Eddie firmware works with both the HB-25 motor controllers and with a h-bridge. In my experience the code works a bit better with the HB-25 motor controllers.
    I'm sure I'll have more questions about how you have your robot wired tomorrow. The only issue I've had is the distribution board pulling a lot of current from the USB when I had my robot on the bench to program.
    I don't use any relays with my robot and I don't have any "involuntary movements" with my robot. I'm pretty sure there has been more than one version of the HB-25. Maybe you have a different version? We can check this tomorrow. 
  • Duane,
    I went off topic, but to clarify....
    HB25:
    1) i switch my robot with a single on/off operation and sometimes the HB25 do not respond to commands, i need to go the motor switch off/on and the control is back, solution: relay off->on
    2) I have a quickstart board connected via USB to the PC, if for any reason the PC restarts, or goes off for awhile sometimes the motors move, or spin erratically, the only solution so far manual motor switch off.
    3) HB25 have a 20 ms min pulse, where you cant refresh the signal otherwise will shutdown, look to eddie firmware you are refreshing the motors at 50hz = 20ms, but eddie does not have HB25, try to do it with the HB25 it will work ?

    4) The HB25 chip allows current sensing, but the pins are not available, i end up interfacing current sensors outside. one argue why the need.  You have high torque motors and if you don't implement a stall detection, and for any reason your robot crash to the wall, you will at least blow up a fuse, worst case hardware damage.
    5) The HB25 fan, is very thoughtful but if you have the robot iddle, is very annoying. Forget the surprise effec ;) to solve the issue i'm using mosfet to controll both fans (on, off, %speed), as a precaution i ll put thermistors attached to the heatsink and it will override the fan setting.
    I understand is not possible to create a product to satisfy all the different needs, but i would leave the door open to other needs like leaving the point 4 CS pins available,  leave the the H-bridge pins available and a jumper to disable the "servo" functionality.
    I don't like to give up, i bet and i spent the money on the HB 25, they are working (still need to find a solution for point 2), but if i started fresh... Tiago
  • Duane, 
    Coming back to the encoders,  I've been in this road for a few months with Arlo... I'm happy at least i got your input, but the main question aren't we trying to solve in the software something that is a hardware design ? 
    Arlo optical encoders, without a fixed position (wobbling) costing $40 is the solution for a $300 motors. I'm not trying to build a Nasa robot, but for $340 i'm trying as much possible justify the investment, this value can be higher if you break the fragile encoders (like a few other folks, they spent 2 sets until they decided to use glue).
    Like i said i tried to measure the intervals between the ticks, I'm surprised if you got stable values. 
    I hope i can still piggyback on your software ideas, but you don't work for Parallax and is depending on your availability. Thanks
    I'm not a mechanical guy, neither a arts & crafts, my background is software, and i need quickly come back to the path... 
    Do you see any other hardware alternatives, a similar worm motor with a built in (hall effect) from the same supplier or other that could fit in the Arlo. I prefer to lose the original motors, versus losing my time and motivation trying to find a software solution when i know whatever you will get relies on a lower optical encoder.
    The other solution attaching a sprocket, and a metal chain to an external motor w/encoders, is only an idea, i'm very afraid to touch the optical encoder, after struggling to put straight ... If is possible i can try see if parallax can sell me one second hand/damaged but similar to see if i can match sprockets and a chain...
    Please comment hardware alternatives, do you have other ideas ? Different motors can be lucky guess if they can fit in. 
    Tiago
     
     (wobbling) costing 
  • Arlo optical encoders, without a fixed position (wobbling) costing $40 is the solution for a $300 motors. I'm not trying to build a Nasa robot, but for $340 i'm trying as much possible justify the investment, this value can be higher if you break the fragile encoders (like a few other folks, they spent 2 sets until they decided to use glue).
    Do you see any other hardware alternatives, a similar worm motor with a built in (hall effect) from the same supplier or other that could fit in the Arlo. I prefer to lose the original motors, versus losing my time and motivation trying to find a software solution when i know whatever you will get relies on a lower optical encoder.
    The other solution attaching a sprocket, and a metal chain to an external motor w/encoders, is only an idea, i'm very afraid to touch the optical encoder, after struggling to put straight ... If is possible i can try see if parallax can sell me one second hand/damaged but similar to see if i can match sprockets and a chain...


    I don't recall reading any posts where people have broken the encoders used on the Arlo motors.  If one did get broken during installation I'm sure Parallax would replace it for you if you contact them.  Their support is excellent.  When I've installed them I did add a small amount of glue on the encoder disk where it is mounted on the shaft to ensure it won't move.  They seemed to have a snug fit and shouldn't move but I added the glue as a precaution just in case.  As long as the encoder wheel is centered between the encoder sensors it should never hit them.  If the shaft holding the wheel moves in/out enough where the encoder may rub on the sensor then you should double check the assembly of them.

    While the 144 position encoder doesn't sound like a lot it is much better than the original position controllers used on these motors.  Since the encoder is directly on the output shaft with the wheel there is a point where going higher on the encoder won't matter as much due to play/backlash in the motors.  I think ideally you're looking for a way to get high resolution on the armature of the motor itself.  Unfortunately the motors (and most heavy duty wheelchair motors) don't have any easy way to do this.  So working with the best resolution you can get on the output shaft (factoring in the backlash) is the way to go.  It sounds like there is still somethings that can be done in software so I wouldn't give up yet.  I've seen these motors used in quite a few projects with excellent results.

    In regards to the HB-25 issues I haven't run into that myself.  The only issues I had were with the early position controllers (with low res encoders) and the one side needed to have a command sent to reverse to orientation.  That was an unfortunate design decision that should have been a jumper setting.  Until that command was sent if you bumped that one wheel it would just take off on you.  To prevent that from being an issue I added a relay to power the HB-25's and only power them up after the position controllers were initialized.  Since I ditched the old position controllers that is no longer a problem and just use the relay to shut off power when not used to save energy on the robot.

    Robert
  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2015-07-09 16:23
    If you are having trouble dealing with low sampling rates, switch from speed to raw tick counting. You can set whatever delta you want, even down to one tick, independent of time. Speed-based dead reckoning using incremental encoders is something of an oxymoron anyway. You're looking for distance derived from speed over time, when you already have it from the encoders directly.
    There is no reason why a Propeller can't process the encoder output in both ways at the same time, and use them together if you'd like: ticks for distance odometry, as well as derived speed.

    Non-surplus encoders with high resolution are not cheap. You can look at alternatives here:
    www.usdigital.com
    but be prepared to pay $30-$200 per encoder. Variations include a shaft or thru-bore. Or you could use the individual parts they sell to make your own. Combine a transmissive encoder disc with an optical head. You will need to baffle the head to prevent ambient light from spoiling the sensor, and secure it well enough so that any runout of the motor shaft doesn't cause the disc to rub against the optics
    I don't have an Arlo, but the earlier Eddie-type platform. The motors used there are different, though along similar lines. I have not noticed a lot of runout of the shaft, but that's to be expected. If you're using a thru-bore encoder, for example, you set the encoder in a soft mount, so it allows for the runout. If you hard fasten it, and the runout is significant enough, the encoder will just break over time.
  • Guys, 
    Thanks for the feeback.
    @Gordon:
    Arlo encoder attach, there is nothing to fasten, look the PDF, i don't want to even try to get it out from the axle, probably will get loose, they seem very fragile.
    I don't understand your point regarding raw tick counting, there are no propeller issues counting one phase, two or two motors, with the existent encoder resolution, its not an issue.
    I'm already counting raw ticks, the propeller mission is to drive/control a motor within a specific ticks per second, does not matter if it will run for 10 seconds, or for 1 minute, that control is done at the PC level.
    based in the wheels geometry, and the number of ticks per revolution, and other variables the PC determines the necessary speed  and sends a command 
    drive 30, 30
    propeller need to keep the pace, and adjust the speed to avoid going left or right and the control is independent per wheel, slight turn :
    drive 20, 40
    because propeller does not know where is going and how long to run, the mission is to keep the correct request speed until new drive command is received.

    I found an optical encoder HEDS 5500, applied to the back of a motor,  
    i'm outside of my comfort zone. 



    Tiago     
  • Duane DegnDuane Degn Posts: 10,588
    edited 2015-07-09 17:25
    Hi Gordon,
    The current Eddie firmware does keep track of both the total distance and the speed.
    I added a row of ten WS2812B LEDs to my robot and used it as an indicator of which wheel was ahead while the robot moved. I had a LED light green for each encoder tick the right wheel was ahead of the left wheel or a red LED light for each encoder tick the left wheel was ahead.
    I had the robot drive the same 1m by 2m course shown in the video and the results were very boring. A single LED would flicker on and off. The total encoder counts for each wheel stayed matched within one count as it drove the course. There were occasions when there would be more than one LED lit but these happened at the end points of the segments and robot would quickly adjust itself so the encoders were positioned in the expected location for each segment of the course. As I mentioned earlier, I think these small over/under shoots were caused by the half second speed measurement interval. These over/under shoots were only one or two encoder ticks and the robot would not proceed to the next segment of the course until the measured ticks matched the target ticks.
    The matching of the encoder ticks while travelling was part of the original Eddie code. This worked great before I started working on the project. I added an integral component once the robot neared its destination so the last few encoder ticks were realized. (I also added a bunch of other cool stuff to the program.)
    I think higher resolution encoders would probably make it easier to program the robot to drive nice and straight without the little adjustments between segments but I'm not convinced higher resolution encoders would improve the overall performance of the robot (performance being getting the robot to a desired location). I personally think the robot drives pretty straight. 
    Other gearmotors I use have the encoders on the DC motor shaft rather than the drive shaft. For example Parallax's 30:1 gearmotors have the encoder on the motor so the 48 transitions per rotation gets multiplied by the gearbox to 1440 transitions per rotation of the drive shaft. I think it would be great if the Arlo had 1440 transitions per rotation but I don't think this was an option when using automotive gear drive motors.
    I haven't had trouble with my encoder disk wobbling but I would have liked some way of aligning the encoder disk.
    I won't pretend to be unbiased since Parallax gave me the hardware in exchange for changing the code to work with the Activity board but I'm pleased (in by biased way) with how the Arlo hardware is working.
  • @Gordon, Do you have an Eddie Control Board with a h-bridge?
    If so, I hope you try out the my version of the firmware. I think I improved the ways the Ping sensors are read from the previous firmware.
    The Readme file of the Eddie firmware repository gives instructions on which archive to download depending on the hardware you have.
  • ercoerco Posts: 20,244
    edited 2015-07-09 18:26
    TTYTT, I've been pleasantly surprised how accurate I can get with 64 ticks (32 B/W stripe encoder) per wheel revolution. IMHOTEP the secrets are high gear reduction, moving slowly, minimum backlash in your motors, and using a combination of coasting and dynamic braking.
    Here's a BS2-controlled bot using mechanical relays to switch the motors, demonstrating good repeatability:


     






  • GordonMcCombGordonMcComb Posts: 3,366
    edited 2015-07-09 20:22

    because propeller does not know where is going and how long to run, the mission is to keep the correct request speed until new drive command is received.


    I'm aware you're counting raw ticks. You have to, but then you're converting to a time measurement. Turn the equation around. Your main concern is making sure it goes where it's supposed to go. Speed comes into play; you need the encoders to establish speed, but you don't need speed to establish distance.
    An incremental encoder already tells you how far it's gone. Let the ticks measure distance for each wheel instead. By not using time, sampling rate doesn't matter. You look at the delta of R/L ticks to determine  course. 
    This is not new. Resolving via "follow-me" had been done for years in keeping film picture and sound editing  equipment synchronized. Counting pulses is the only way it can work (well, other than a mechanical linkage between the two). Advance the picture one frame manually, and the sound track suddenly jumps the same amount. If "speed" were involved, it would only work at projection rates, which wouldn't work here.
    (Of course, those kinds of flatbed editing systems are pretty much obsolete, but my point is the technique has been around for years, and is very accurate.)
    Duane, I don't have Eddie-anything. I got the MadeUSA platform a while back, and put on my own control electronics. I initially used the HB25s for it, but later removed them for another project, and replaced them with traditional H-bridges from Pololu that I could control with standard PWM.
  • I'm glad Gordon brought this point back up.

    because propeller does not know where is going and how long to run, the mission is to keep the correct request speed until new drive command is received.

    This is one area I haven't tested much. To make it easy on myself, I ran the robot through a predetermined course so the program always knew how many encoder ticks it would need at the final destination.
    I just looked at the present Eddie firmware and it uses different "modes" depending on the command given. If the program is in speed mode it calculates a target encoder position each loop of the program and compares the current position against this target position. The program adjusts the power to the motors based on the difference between this current position and the target position. In the speed mode there is only proportional corrections made. There isn't an integral or derivative component to the speed control algorithm.
     I hope to revisit the the Eddie firmware within the next few days. I'll try to test the accuracy of the encoders while in speed mode. It seems like this is a harder mode to test since you'd need a large area to run the robot at a set speed for time intervals long enough to test the efficacy of the program. I think I've only tested this mode at the bench with the wheels free to spin. Does anyone have a suggestion on how to test the speed mode without the need of a large test area?
  • Duane,
    Any progress on your side ? 
    I tried tweaking the PID 2 or 3 times per second, but no luck. It's not responsive enough to quickly adjust the speed.
    Tiago 

Sign In or Register to comment.