Eddie TURN command
Well, Ive been testing the encoders, and it seems somewhat strange. Its possible Im not converting the angles correctly from decimal to a 16-bit signed (twos complement) hex value which is what the command requires.
Anyway, lets say I wanted to turn left by 90 degrees. I calculated the hex value to be FFA6. When I gave the command to turn (i.e. TURN FFA6 14 that means turn 90 degrees to left at 20 positions/second), it turned only 74 degrees (I measured using a protractor).
Whats more interesting is that if I enter the HEAD command which tells you the current heading in degrees, it returned FB5 which I believe is calculated to be exactly 74 degrees. So, it would seem the robot knows that it went 74 degrees based on the heading but did not turn the full 90 degrees I specified. Finally, to confirm, I basically gave it a command to turn 90 degrees to the right (i.e. TURN 5A 14 that means turn 90 degrees to the right at 20 positions/second), and it only turned 74 degrees again to the right. When I put in the HEAD command again, it was back to 0.
Im guessing this is a firmware issue. It seems HEAD is fairly accurate while TURN is incorrect (though relatively consistent).
Has anyone encountered this before or am I just not calculating the hex values correctly?
Dan.:nerd:
Anyway, lets say I wanted to turn left by 90 degrees. I calculated the hex value to be FFA6. When I gave the command to turn (i.e. TURN FFA6 14 that means turn 90 degrees to left at 20 positions/second), it turned only 74 degrees (I measured using a protractor).
Whats more interesting is that if I enter the HEAD command which tells you the current heading in degrees, it returned FB5 which I believe is calculated to be exactly 74 degrees. So, it would seem the robot knows that it went 74 degrees based on the heading but did not turn the full 90 degrees I specified. Finally, to confirm, I basically gave it a command to turn 90 degrees to the right (i.e. TURN 5A 14 that means turn 90 degrees to the right at 20 positions/second), and it only turned 74 degrees again to the right. When I put in the HEAD command again, it was back to 0.
Im guessing this is a firmware issue. It seems HEAD is fairly accurate while TURN is incorrect (though relatively consistent).
Has anyone encountered this before or am I just not calculating the hex values correctly?
Dan.:nerd:
Comments
No, I never solved it. I think perhaps its just the encoders aren't very accurate. You might want to reach out to Parallax support. Unfortunately, I can't really offer too much guidance.
Dan.
Hopefully somebody can help. From my testing I issue the command 'TURN 2D 20' (rotate 45 degrees at speed 32). Then after using the ‘HEAD’ command Eddie has only rotated 30 maybe 35 degrees.
I worked around the problem by using for example 'GO 14 EC' (Left wheel forward at 20 right wheel backwards at 20) and then continually checking ‘HEAD’ until it has reached 45 degrees and then issuing ‘STOP 0’.
But I would have imagined the ‘TURN’ command would have done this operation for me as Eddie knows it has only turned less than this through the ‘HEAD’ command.
Unless I am missing something!?! Does anyone have any idea?
As the Eddie robot approaches its destination, it slows down so that it doesn't overshoot it. If your Eddie robot has a low battery or extra rolling resistance, the motor power may go too low for the Eddie to finish its turn. Try executing the same command with the Eddie robot chassis resting on a block that prevents the wheels from touching the ground. If the HEAD command then shows that it rotated the full 90° turn, than this is probably the problem you are having. If the problem continues with the battery fully charged, you can increase the constant "Kp" in the DAT section of the Eddie firmware to account for extra dampening from rolling resistance.
— David Carrier
Parallax Inc.
Many Thanks for the response. I did as you suggested and raised Eddie's wheels off the floor by resting the chassis on a block. And with a fully charged battery I conducted the test again.
I am still getting the same results 'TURN 2D 20' (Rotate 45 degrees at speed 32). Then 'HEAD' returns 34 degrees. I tried with a longer TURN 'TURN B4 20' (180 degrees) and this return a HEAD of 166 degrees after the motion.
This is the pretty much the same results as with the wheels on the floor. Surely with the wheels off the ground there shouldn't be any dampening from rolling resistance?
Do I still need to try and change the line 'Kp long Motors#MAX_ON_TIME / 16 ' Proportional error feedback gain' in 'eddie.spin'? If so what amendment do I make?
If you could advise on the next step that would be great.
Thanks in advance
Andy.
If it is stopping early with no load on the wheels, then adjusting Kp probably won't make a difference. What version of the firmware are you using? (i.e. What does "VER" return?) Does the TRVL command work correctly?
— David Carrier
Parallax Inc.
Todd
David: I used the TRVL command as you suggested but, like the TURN command, it doesn't reach the distance specified. All the following experiments are with the wheels off the ground and a fully charged battery.
I tried several commands but here are an example of two ->
TRVL 12 10 (Forward 18 positions) only moved 16 positions
TRVL 100 20 (Forward 256 positions) only moved 254 positions
One point to note, after the wheels have stopped turning I can here the motors trying to turn the wheels (a high pitched noise until I send STOP 0 which stops the noise). So it obviously knows it needs to move more but can't turn the axel. This is also the case with the TURN command.
So it appears it is having trouble with slow speeds so I thought I'd try ->
GOSPD 1 1 (this turned the wheel a fraction, stopped and repeats)
GOSPD 2 2 (same as above but at a quicker rate)
GOSPD 5 5 (same as above but at a quicker rate)
GOSPD 10 10 (turns wheels at a constant speed)
It would seem to me it is struggling to turn the wheels at a constant rate at anything below around 10. Which in turn causing the TURN and TRVL commands to not function correctly.
Should GOSPD 1 1 turn the wheels in a smooth constant motion very slowly? If the above is correct I definitely have a problem here.
Is there anything I can do/try to overcome this?
Thanks in advance
The control system on the Eddie robot has a two-position dead zone to prevent heavy Eddie robots from oscillating under all possible load conditions. If you can hear the motors after it stops, but it is really close, it is probably right on the edge of the dead zone and is powering the motors with a very small amount of power. Because of the dead zone, it is normal for an Eddie to stop a position or two short, but it will be consistent for both short and log distances. The encoders cover about half an inch per position, so it can be off by an inch or so. The rotation issue you mentioned earlier could be because of this, since each wheel could be off by an inch, which could total five to ten degrees of error.
If you give it an extremely slow speed, it will be a little choppy, because of the wheels only move a few positions per second, and the robots momentum may not carry it forward for that long. The feedback from the sensor essentially isn't coming fast enough to allow the control system to smooth it out, so it moves a position, waits, then moves a position again to get the correct average speed. The feedback loop on the Eddie robot is also somewhat detuned to allow a both stock robots and ones with large loads to use the same settings. The side effects are exaggerated by the relatively low encoder resolution on the position controller.
We have been using part number 29321 for some in-house Eddie robots, and they have four times the resolution which allows the robot to stop within 1/4" of the final destination with the same tuning. We are working on an upgrade path for current Eddie robots, which we should have available soon. If you are always going to have the same weight on your Eddie robot, you can also play around with increasing Kp to make it approach the end position at a faster speed.
— David Carrier
Parallax inc.
I look forward to seeing the upgrade path. After working with Eddie for almost a year the only complaint I have is the accuracy of the encoder. I'm curious if the upgrade only requires changes to the control board firmware, or if a re-compile of the Parallax2011ReferencePlatform service will also be required.
Todd
Am I out of line in expecting that a Microsoft/Parallax/PC-based product would have this basic navigational ability down pat, especially this late in the game?
Just catching up with this thread as I've been away.
It does seem strange that an out-of-the-box Eddie with the wheels off the floor(no friction) cannot perform the TURN or TRVL commands successfully. In myexperimentation with my Eddie it makes these two commands unusable as explainedin post #12 of this thread.
Just a bit of background I am currently working on a projectwith my Eddie that detects and maps his environment therefore it is absolutely essentialthat I know the exact position of Eddie and the TURN and TRVL command wouldassist me greatly with this but currently I can’t use them.
It is mentioned above that buying the higher resolution sensors would work as apotential workaround. I purchased the Eddie as an individual at (what I thoughtwas) quite a cost to me and I am finding it difficult to spend additional moneyon extra parts. But I guess I would begrudgingly purchase the ‘36-positionQuadrature Encoder Set’ if this would solve the problem for me. Do you think itwould do? Could I then use the TURN or TRVL commands successfully?
Also, it was mentioned that "Kp" value in the DATsection could be amended. Is this worth a try? If so what should I set it to?
The third option I guess is wait for the update that was also mentioned above.Do we know when this will be released?
One point to make is that I am happy that there are options availableas it would be much worse if there were none! Any advice on which course ofaction would be best to take would be greatly appreciated.
Many Thanks
Andy.
David's our firmware guru, so he'll chime in with those answers. I've got your replacement encoder information. But first, some backstory (which is also to answer erco's question).
When we first developed Eddie with Microsoft, we had a very limited timeframe to work in and needed to utilize as many existing components as we could. The current (green) encoders in your kit were originally developed for the BASIC Stamp modules, using a coprocessor to provide position information. Obviously, the Propeller can handle processing this data on its own, but the new encoder development needed to start after we let Eddie out into the world. Thankfully, we had Matt G to design this excellent product after Eddie's release.
That being said, of course these new encoders would be provided to you at no additional cost. However, in order to minimize the disassembly of your Eddie, a different encoder wheel was designed (details here). We still need to laser cut those pieces before we can send out the kits (need to check with production on a date). In the meantime, Andy, if you want to PM me your address, I'll make sure a new set is mailed to you as soon as the parts are cut.
Same offer goes to any other existing Eddie customers as well.
Cheers,
Jessica
I look forward to the installing the new parts
I have now received the new encoders (Thanks Jessica) and followed the excellent installation guide (Thanks Matt G) which all went really well but on putting Eddie back together and issuing a 'GO 20 20' command I get 'ERROR' and with 'VERB 1' get 'Encoder Error'.
I reconnected the wires in the same fashion as the previous encoders but I assume here I need to do something different? Also do I need to change anything else? How does the Propeller know it has higher resolution encoders installed?
I couldn't find any further instruction on anything beyond the installation.
As always your help is appreciated.
Andy.
Yes, a different encoder configuration is required. You can find the updated connection information on page 12 of the Eddie Robot Assembly Instructions.
Let us know if you run into any other issues!
Jessica
Why then do I see this constant in the beginning of the code??
' Positions one wheel must make for a 360° rotation
POSITIONS_PER_ROTATION = 744
Shouldn't that number actually be 144 since that is the number of counts the encoder puts out??
This simple typo could cause all sorts of odd issues and I would expect the movement to be off. Is this the latest code? If so, can someone at Parallax explain why it is 744 instead of 144?
Perhaps someone with a working Eddie could try changing that constant, build the firmware image, and see if that fixes the issue.
Robert
— David Carrier
Sorry about the wording on that post. It wasn't really clear from the comments in the code and it really sounded as if it was for one 360 degree rotation of the wheel. It's just a coincidence that both values end in 44 and that at first glance the 7 could have been a typo for a 1. Thanks for clearing that up.
Robert
I have yet another problem I’m afraid! I managed to get the new encoders installed and followed the setup guide for the wiring on page 12 of the Eddie Robot Assembly Instructions as you suggested.
I then update the Eddie firmware using the Propeller Tool to version 1.3.2 (07/09/2012).
My Eddie was then demonstrating very strange behaviour. The motors would only run for a very short period of time. I have three examples are ->
Command: GO 20 20
the motors run for approximately 1 second and then stop ->
DIST returns -> 00000036 00000038 (54 56)
Command: TRVL 100 20
the motors run for approximately 1 second and then stop ->
DIST returns -> 00000036 00000034 (54 52)
GOSPD 40 40
the motors run for approximately 1 second and then stop ->
DIST returns -> 00000076 00000075 (118 117)
Any ideas what is happening here? It would seem that after the updates have been done the motors can only run for around a second. Previously a GO or GOSPD command would run forever until I issued a command to stop the motors.
I also downloaded Eddie Firmware v1.3 (.zip) file and updated the firmware to 1.3.2.1 (16/01/2013) and this displayed the same behaviour.
Have I done something wrong with the update potentially or could something else be causing this?
Andy.
That is an amazing coincidence. Teams of numerologists had been working around the clock on that one. To be safe, do not, under any circumstances, modify the code as follows:
' Positions one wheel must make to rain fire & brimstone
POSITIONS_PER_ROTATION = 666
The commands should work the same as in previous versions, and the correct firmware for the updated encoders should be 1.3 dated 16/01/2013.
After you run the command once, are you able to run it again without power cycling? Or do you receive an encoder error?
Jessica
I’m definitely using the correct firmware (16/01/2013). In answer to your question I can continue sending commands and don’t receive the Encoder Error message.
If I was to send GO 20 20 every half second Eddie would continuously drive the wheels forward.
It is a really strange problem and I can’t think what I can try to fix it. Is there any advice you can offer?
Andy