Andy,
There is a feature in the firmware that turns the motors off if the Eddie doesn't get any communications for a period of time. You can turn it off by sending a "WATCH 0" command to the Eddie control board. There is an entry for the "WATCH" command at the top of page five in the Eddie Command Set v1.2. From the "DIST" results, it does look like your encoders are working fine.
Many Thanks David. The WATCH 0 command has done the trick. It now continues to drive the motors until I send a command to stop. I never checked the Command Set for any new commands so thanks for pointing me in the right direction. Also, as you suggested it would appear that the new encoders are operating correctly.
So having installed the new encoders and got Eddie back to normal I went back to the experiments back in post #11 of this thread using the TURN and TRVL commands.
I used the same commands as before and I am experiencing very similar results as I was previously with the TURN and TRVL commands not completing. All of these experiments were done with the Eddie wheels of the floor.
TURN B4 20 (180 degrees)
Returns a HEAD of 173 degrees after the motion.
TRVL 12 10 (Forward 18 positions) only moved 11 positions
TRVL 100 20 (Forward 256 positions) only moved 248 positions
Again at the end of all these commands there is a very high pitch noise coming from Eddie until I send STOP 0 which terminates the noise.
So this update does not seem to have solved the original issue. Any ideas or is there anything else I could potentially try to get the TURN and TRVL commands working correctly?
I believe the "watch" feature was something identified by Gershon at Microsoft. They were afraid that if RDS issued a command that started the robot moving and then lost communications (or the RDS software crashed) the robot would continue its movement, probably a bad thing with a robot as heavy and powerful as Eddie. Issuing a periodic keep-alive signal would act as a deadman switch and prevent this from happening. However, I haven't seen an update to RDS so until that happens it will have to be changed as David suggested.
On that subject, any idea when the ParallaxIO service will be updated?
I was wondering if anybody (Jessica, David or anyone else!) had any ideas on the problems I’m still having with the TURN and TRVL commands described in post #33 with my Eddie robot?
Andy,
In short, the new firmware is still tuned just like the old firmware, to remain compatible. Any control software written for the old firmware should work with the new firmware by quadrupling the speed and distance values it sends and quartering the ones it receives. The newer hardware does allow tighter tuning, so you can get the performance you desire by increasing Kp, probably to 4 times higher than it is now. (Be sure to test changes on a raised platform with the wheels of the ground, but keep in mind the firmware will behave differently on the ground, due to momentum.)
Read on for the technical details as to why the tuning is having an effect.
As I mentioned earlier, if you can hear the motors after they stop, the firmware is powering the motors with a very small amount of power. The further a motor is from the position the firmware is trying to hold, the more power the firmware will apply to the motor. (Kp sets this ratio.) With the old encoder, the the low resolution limited how aggressive this could be. It cannot apply any power until it is in a position past the dead zone, which is two positions past the set point. In the case of the old encoders, the motors are off when rotated within 10° of their destination and at their lowest power when between 10° and 20° of their destination. (The destination itself is also a 10° range) The lowest power level has to be low enough that when a wheel sitting at its destination is rotated by an external impulse (e.g. something bumping into the robot) it will stop when power is applied in the reverse direction, but not turn around. If the power is high enough to reverse the motion, the wheel may turn around, pass the destination and the dead zone, and trigger the firmware to power the motor again in the opposite direction. This can repeat indefanitely, causing the wheel to osccilate. Some motor assemblies are more efficient than others, so the power needs to be low enough that none of the assemblies can oscillate.
With the new encoder, the destination is a 2.5° range, the dead zone is anything within 2.5° of the edge of the distination, and the motors are at the lowest power from 2.5° to 5° away from the destination. If Kp is tuned to just low enought to prevent oscillation, the motors will most likely come to rest within the position that boarders the deadzone, so with the right Kp values, this would mean an error of 2.5°to 5°.
The new firmware uses the same power to distance ratio as the old, which gives the same effective Kp. With the old firmware, this ment that the minimum non-oscillating motor power was between 10° and 20° degrees from the destination. With the new encoders it can be essentially the same power level at 2.5° to 5° from the destination, which is 1/4 the distance as the old encoders.
For even more accuracy, you can have your side of the firmware anticipate the dead zone by keeping a running average of the difference between the current position and the destination whenever a move completes, and adding that as an offset to future moves.
Comments
There is a feature in the firmware that turns the motors off if the Eddie doesn't get any communications for a period of time. You can turn it off by sending a "WATCH 0" command to the Eddie control board. There is an entry for the "WATCH" command at the top of page five in the Eddie Command Set v1.2. From the "DIST" results, it does look like your encoders are working fine.
— David Carrier
Parallax Inc.
So having installed the new encoders and got Eddie back to normal I went back to the experiments back in post #11 of this thread using the TURN and TRVL commands.
I used the same commands as before and I am experiencing very similar results as I was previously with the TURN and TRVL commands not completing. All of these experiments were done with the Eddie wheels of the floor.
Experiments conducted ->
TURN 2D 20 (Rotate 45 degrees at speed 32)
DIST
00000026 FFFFFFDC (38 -36)
HEAD
023 (Only rotated 35 degrees)
TURN B4 20 (180 degrees)
Returns a HEAD of 173 degrees after the motion.
TRVL 12 10 (Forward 18 positions) only moved 11 positions
TRVL 100 20 (Forward 256 positions) only moved 248 positions
Again at the end of all these commands there is a very high pitch noise coming from Eddie until I send STOP 0 which terminates the noise.
So this update does not seem to have solved the original issue. Any ideas or is there anything else I could potentially try to get the TURN and TRVL commands working correctly?
Andy.
On that subject, any idea when the ParallaxIO service will be updated?
Todd
I was wondering if anybody (Jessica, David or anyone else!) had any ideas on the problems I’m still having with the TURN and TRVL commands described in post #33 with my Eddie robot?
Any ideas to try would be great. Many Thanks.
Andy.
Sorry, I have the old encoders so can't help troubleshoot, although I am VERY interested in what you find.
Todd
In short, the new firmware is still tuned just like the old firmware, to remain compatible. Any control software written for the old firmware should work with the new firmware by quadrupling the speed and distance values it sends and quartering the ones it receives. The newer hardware does allow tighter tuning, so you can get the performance you desire by increasing Kp, probably to 4 times higher than it is now. (Be sure to test changes on a raised platform with the wheels of the ground, but keep in mind the firmware will behave differently on the ground, due to momentum.)
Read on for the technical details as to why the tuning is having an effect.
As I mentioned earlier, if you can hear the motors after they stop, the firmware is powering the motors with a very small amount of power. The further a motor is from the position the firmware is trying to hold, the more power the firmware will apply to the motor. (Kp sets this ratio.) With the old encoder, the the low resolution limited how aggressive this could be. It cannot apply any power until it is in a position past the dead zone, which is two positions past the set point. In the case of the old encoders, the motors are off when rotated within 10° of their destination and at their lowest power when between 10° and 20° of their destination. (The destination itself is also a 10° range) The lowest power level has to be low enough that when a wheel sitting at its destination is rotated by an external impulse (e.g. something bumping into the robot) it will stop when power is applied in the reverse direction, but not turn around. If the power is high enough to reverse the motion, the wheel may turn around, pass the destination and the dead zone, and trigger the firmware to power the motor again in the opposite direction. This can repeat indefanitely, causing the wheel to osccilate. Some motor assemblies are more efficient than others, so the power needs to be low enough that none of the assemblies can oscillate.
With the new encoder, the destination is a 2.5° range, the dead zone is anything within 2.5° of the edge of the distination, and the motors are at the lowest power from 2.5° to 5° away from the destination. If Kp is tuned to just low enought to prevent oscillation, the motors will most likely come to rest within the position that boarders the deadzone, so with the right Kp values, this would mean an error of 2.5°to 5°.
The new firmware uses the same power to distance ratio as the old, which gives the same effective Kp. With the old firmware, this ment that the minimum non-oscillating motor power was between 10° and 20° degrees from the destination. With the new encoders it can be essentially the same power level at 2.5° to 5° from the destination, which is 1/4 the distance as the old encoders.
For even more accuracy, you can have your side of the firmware anticipate the dead zone by keeping a running average of the difference between the current position and the destination whenever a move completes, and adding that as an offset to future moves.
David Carrier
Parallax Inc.
So I need to change the Kp value on this line of ‘eddie.spin’ ->
Kp long Motors#MAX_ON_TIME / 64 ' Proportional error feedback gain
And then ‘Run -> Compile Current -> Load EEPROM’ from the Propeller Tool?
Am I on the right track here? And what would I change the Kp value to?
Thanks again for your assistance