How can 1 meter travel be less than both 0.5m and 2m travel as shown in your 1st, 2nd, and 6th forward trials and 1 meter travel be greater than 0.5m and 2m in the 2nd and 3rd backward trials? And what are the numbers in the table? Are these numbers in the registers(encoder counts)? If so what are the values at zero meters? It looks like you significant issues even beyond the significant 8% error noted(and 8% linear error is huge when you convert to rotation).

Hi Billy, In the table I have pasted above all the values are normalised to a self contained 1m. ie if they are 0,5m they are multipled by 2, if they are a reading subsequent to the first reading then they have the previous readings taken away from them - so every number is a comparable to every other.

The original values are in the xls I link to above.

Yes these are encoder counts counted at the output of the topic - /lwheel_ticks and /rwheel_ticks.

Every test started at an encoder count of zero and there are 12 tests above (3 tests full power ahead, 3 tests full power stop start ahead, 3 tests full power reverse, 3 tests stop start reverse).

When I say "full power " vs "full power stop start", I mean on "full power" I kept the stick pushed forwards and just marked the encoder reading at which the robot crossed the 0.5/1/2m lines.where as on "full power stop start" I stoped asking the robot to move at the 0.5/1/2m points, took the reading, and then started moving again.

Looking at these normlaised encoder ticks per m values, reguardless if they are a true meter run, a 0.5m run scaled up, the start, middle, or end of a continuious 2m run, there are some big ish inconsistencies.

For example, the 0.5m to 1m part of run 2 and run 3 for full power no stopping - the equvilent of 10,666 ticks vs 11,286. Why does the same 0.5m traveled sometimes show 620 less ticks - the equivilent of 5cm difference!

I am pretty sure this is not wheel or tire slipage - there is nothing holding the robot back.

Next test is off the ground I think - how many ticks for ten visual rotations of the tire, totally isolated from ros, just make the motor go full power and count the ticks for 10 rotations. One for the morning.

+1 for planning isolation testing. Do you have an oscilloscope you can use to look at raw electrical signal? I'm suspecting you may find the signal drops out sometimes.

Some thoughts:

• Are your encoders measuring rotation of the wheel axel or rotation of motor spindle?
• According to the spec sheet for the encoder, how many ticks is a single 360° rotation?
• For these tests, you should not be using a joystick because it's difficult to keep angular velocity at 0. It's better to use code to publish to /cmd_vel at a slow velocity your motors can smoothly handle.
• The phrase "full power" implies "wheel slip" to me. Have you checked the left/right encoder difference with the drive wheels not touching the ground?

Hi Mike thanks for your questions:

• Encoders are measuring rotation of the motor spindle, not rotation of the wheels..
• 6 ticks (3 ups, 3 downs) per rotation
• Pror to the Edit 1 tag this was uing ROS and a Joystick. After Edit 1 tag this is not using ros at all, just pythos code controlling the motors and reading the ticks directly - but in the same was as I do in my driver_node that I use for ROS..
  
• 'Full power' was a 'direct to the motor controller' PWM setting of 100. Re "checked the left/right encoder difference with the drive wheels not touching the ground" - Yes, the first screen shot after the 'Edit 1' Tag labeled "Free Wheeling" is wheels off the ground.

Thanks very much Kev

A slight oddity, with the econders connected to the Pi and my DSO, I see highs of 2.4v on an analog reading, and I need to set the DSO to 1.8v logic in order for it to recognise that as a high. When I disconnect the encoder outputs from the Pi and just connect them to the DSO, I see highs of 3.3v and the DSO recognises that as High with a 3.3v logic setting (or infact any of the 1v, 1.8v, 2.5v, 3.3v, or 5v settings). I have tried playing with the pull up / pull down / float settings of the Pi DigitalInputDevice(encoder_a_l, pull_up=True) etc) to no effect at all.

Looks like you found the issue. Your right encoder is failed.

Unfortunately I don't think so. My driver_node code only uses the A encoder on each motor, and the A encoder on both motors is ok.....

I can see two possible explanations for your data:

• the hardware is not counting all the encoder output edges (possibly on both L and R, but with different loss rates.)
• the motors are mismatched, and a particular PWM value does not result in the same spindle velocity.

Perhaps this test would tell you something: run a motor at "constant" speed and see if the oscilloscope reports the same number of ticks/second as your software?

How do you know which way the motor is turning if you only use one channel of the encoders? How confident are you that it really only uses one channel? I've never heard of any application using an encoder single channel (it would then just be a tachometer).

@Billy - My code just says "If the Power is positive then encoder ticks must be going up, if negative, encoder ticks must be going down". See here:

• https://github.com/KevWal/ROS-Bot-Workspace/blob/master/src/edukit_bot/src/driver_node#L106

I used to use the yellow TT motors with a single optical encoder on the output shaft - so had no choice but to do it this way.

I changed to the Micro Metal Gear Motors to get a higher gear ratio (to get slower minimum speed) and to get more encoder ticks per ros rate spin. With the TT Yellow motors I was only getting 15 ticks per ros rate spin at a rate of 5hz, so no chance to be acurate, now geting 60 ticks per ros spin at a rate of 10hz as encoders attached to motor shafts rather than wheel shafts.

@Mike-Scheutzow thanks for the comment,

• Re not counting all the encoder ticks - I agree a posibility, but not sure how to check. I could run the motors for a fixed 1 second, the software would tell me about 600 ticks, but then I have to go an manually count 600 ticks on the 'scope to compare! I could do 1/10th of a second I guess and count 60...

• Re motors are mismayched - oh they are, one generates slightly more speed for the same pwm thatn the other - thats clear in the data. 10 turns of the L wheel causes 9.7 turns of the R wheel in the same length of time. 10 turns of the right wheel generates 10.36 turns of the left wheel in the same length of time.

Re the test - my current 'scope is not telling me frequency of the signal, i can only get frequency of a single pulse. My multimeter will tell me frequency, but the values in the read_PWM code are up and down like a yoyo (within a range), and the multimeter output is similar - so compar

[encoder output] up and down like a yoyo (within a range), and the multimeter output is similar

Unfortunately this doesn't tell us much - it could be a sensor-reading problem or a motor-control problem (or both.)

I'm not familiar with the PWM control requirements of inexpensive motors - maybe it expects your control loop to keep shifting the PWM width in the desired direction? I assume your raspberry pi generates the PWM width using hardware. Have you tried to create a software control loop to run the motor at a constant velocity (as reported by the encoder)?

Regarding:

My code just says "If the Power is positive then encoder ticks must be going up, if negative, encoder ticks must be going down". See here:

OK, so they are simply guessing which way the encoders are counting based on the polarity of the voltage at the motor. It's no wonder then you're having issues. On deceleration you can have negative motor power and positive going encoder counts and this code would generate errors. And if you're rotating robot with one wheel "stopped" on the edge of an encoder line while power is hovering around zero you could get false counts (wrong way) as well. You really want to use a proper encoder counting method. Use this as a learning opportunity and take the time to do it right. There are multiple ways of counting quadrature to assure you count the correct direction.

@billy thanks, once I get a 2nd motor with both encoders working (2nd replacement sent back to Amazon today due faulty encoder!) I will sort out quadrature encoder reading - can't do much on this area till then. I must admit I can't see this being a big area of error - the motors change direction within 30ms - I can see the change on the 'scope, but can only help and a good learning experiance moving to quadrature encoder reading as you say.

@Mike-Scheutzow (I don't seem to be able to get the @ to work for you btw)

Lots of work updating pigpiod and making sure my code is as logical as possible and then testing ros code output vs what I see on the 'scope and I can now confirm they match up within 1 tick or so - for forward movement only - see images about to post in original question edit 4.

So I fixed my 1 failed encoder, I implimented quadrature encoding (easy with gpiozero's RotaryEncoder code), but I still have crap odom. Given Hector slam does a near perfect job, with both accuracy and speed I'm gona give up on encoder based odometry for a while...

"give up on encoder based odometry for a while..." I think this sounds reasonable if you have a work around for now. Eventually you may want to come back to it since the odom from hector slam can't update any faster than your laser and that will limit performance. Have fun.