Eddie Robot - Differential Drive
Hi everyone,
I'm currently doing a project for school with an Eddie Robot. I use C# and Microsoft Robotics API for programming his behavior.
For the moment I successfully managed to move him with SetDrivePower method and it work very well.
However, I'm having troubles to make the robot move with RotateDegrees and DriveDistance methods. Microsoft says this methods are not implemented on all drive service because it need encoders.
So, does Eddie implement this methods ? I know it has two "drive wheels with high-torque 12 VDC motors and position controllers" so I thought he would.
If I can't use this methods, how can I "emulate" them ? I've seen we can do the job with a timer, is this a good substitution or are they other ways ?
Regards,
JackJack
EDIT: I've post in the wrong pool but I can't figure how to switch to robotics forum ... sorry
I'm currently doing a project for school with an Eddie Robot. I use C# and Microsoft Robotics API for programming his behavior.
For the moment I successfully managed to move him with SetDrivePower method and it work very well.
However, I'm having troubles to make the robot move with RotateDegrees and DriveDistance methods. Microsoft says this methods are not implemented on all drive service because it need encoders.
So, does Eddie implement this methods ? I know it has two "drive wheels with high-torque 12 VDC motors and position controllers" so I thought he would.
If I can't use this methods, how can I "emulate" them ? I've seen we can do the job with a timer, is this a good substitution or are they other ways ?
Regards,
JackJack
EDIT: I've post in the wrong pool but I can't figure how to switch to robotics forum ... sorry
Comments
I'll move it for you.
EDIT: Done!
Can you tell us more about the motors and "position controllers"? Did you purchase these from Parallax? What color is the encoder circuit board? (I know a strange question but Parallax changed the color when they changed the hardware and firmware.)
I'm presently working on the Eddie firmware as part of the Open Propeller Project #8.
Even if you're not using the same hardware I have, I think I'm familiar enough with the Eddie firmware I should be able to help you out. I just need to know which version of hardware and firmware you're using.
The Eddie firmware will return the version of both hardware and firmware with the commands "HWVER" and "VER".
@Publison: Thank you for moving my post.
Thank you for your answer Duane,
Eddie was bought by my school, so I guess they bought it on Parallax because they gave me parallax web-site as reference. I'll ask my teacher tomorrow if he bought it on parallax. What I know about the position controller is it's on details features.
I didn't assemble Eddie, I've just resumed an other student project so I'm not very familiar with him, you just made me discover Eddie can be controlled with commands.
Where should I enter this commands ?
We still need to figure out which encoders your robot uses but all the Eddie commands available in the Eddie Command Set document should work with your robot.
I did find a mistake in the PING command section of the document. The conversion factors used are off by a factor of 64. I discuss this issue and the issue of sensor interference in this post. The other commands should work as described in the documentation.
Based on your original post, I think you should look at the "TRVL" command and the "TURN" command.
The commands can be entered via a terminal window. I generally use the Parallax Serial Terminal (PST) to test the commands.
Here's what the PST icon looks like.
PST may also be launched from within the Propeller Tool but pressing F12. The Propeller Tool allows one to inspect and edit the firmware. Files ending with ".spin" can be opened with the Propeller Tool (other file types are may also be used with the tool). The Propeller Tool can be used load firmware to the Eddie board.
I would be surprised if the PC you're using with the Eddie doesn't have the Propeller Tool and PST installed. PST is installed with the Propeller Tool so you shouldn't need to install it separately.
Once PST is open you want to make sure the Com Port being used by the Eddie board is selected and the Baud Rate matches what the Eddie firmware is using (I'm pretty sure this is 115,200)..
Click inside the white box near the top of the terminal to activate the text entry box and type the commands there.
For example TRVL 3E8 3F will cause the robot to travel 1000 encoder ticks at half speed. The commands can be entered in either upper or lowercase. The numbers are entered as hexadecimal values (I use Window's calculator in "Programmer" mode to convert between dec and hex). The command is not executed until the enter key is pressed.
I haven't used the RDS 4 software yet. I'm pretty sure RDS 4 controls the robot by issuing these commands through the USB connection. Only one program can access a Com Port at a time so you want to make sure you don't have PST connected to the Eddie board when you want RDS 4 to connect with it and visa versa. You won't be able to load firmware with the Propeller Tool if the Com Port is active in one of these other programs.
Depending on which encoders you have, some of the commands may not work precisely. The control algorithm lacks an error over time component which will leave the robot slightly off its intended target. I'm presently working on adding this component (I had to stop work on the software to take care of some hardware issues).
I'm still working on updating the Eddie firmware to work with different hardware. I think some of the changes (hopefully improvements) I'm making to the firmware could be applied to earlier hardware configurations. If I know there's interest, I will likely apply the same changes to earlier firmware versions.
Thank you for the answer Duane,
The encoder circuit board is blue, and it's written "quadratic encoder" on it.
The version of the firmware is 1.3 and hardware version is FFFF (is this normal ?).
I succeeded in making the robot turn with "TURN 005A 7F" but when I re-enter the same command I have an error. I set the verbose mode on and the error is "ERROR - Encoder error".
I also tried to put an RST command between the two TURN but the result is the same.
I tried to change the degree parameter in the turn command but Eddie always turn the same angle.
Do you know where can I find more information about the encoder error ?
JackJack
I don't know what the hardware version command should return. I'm pretty sure $FFFF is what an unused section of EEPROM would return so I'm guessing the hardware version was either never set or cleared.(I'm using $ to indicate hex (Spin does the same).) We can figure out the hardware you're using based on the software version.
I also was getting this error when I first used my hardware.
Since the encoders didn't reach the exact location (give or take a small error amount set by the "DEADZONE" constant), the program assumes there's a problem with the motors and shuts off the motor control cog.
I've changed this behavior in my version of the Eddie code but my version uses the HB-25 motor controller and not the Eddie board's h-bridge. I should be able to make this same change to the h-bridge version of the code.
I should be able to make and post this change later today.
You'll need to upload the new firmware to the Eddie board's EEPROM with the Propeller Tool.
I think the new "ARC" command should be easy to add to the h-bridge version of the code. I'll probably do this while fixing the encoder error issue.
I added a couple of flags to my version of the code which, when set, will allow decimal input and output instead of the usual hexadecimal.
I don't want to bloat the code but I find it very convenient to be able to interact with the program through a terminal while using base 10 numbers. If requested, I'll add these same flags to the H-bridge version of the code.
Now that I think about it, I really ought to modify the way the PING command works in the h-bridge version. As it is now, the Pings are all triggered at once which often causes one sensor to receive the wrong echo.
Take a look at the Open Propeller Project #8 thread and let me know if there are any features I've added there which you'd like in your version of the code.
I kind of like having the robot make sounds but if the robot has a PC attached, it can make all sorts of sounds without the need of using the Propeller.
I've seen on Propeller tool we've got a "Load EEPROM" option but should we access it from Run> compile current or Run> compile top ?
For the sound, we have a pc and a c# speech synthesizer on it's okay thank you.
I explored the file "Eddie with 29321 encoder.spin" (eddie.spin) and I've seen there is a DEADZONE variable but I don't understand how it works.
This command is cool. Since I didn't know for the commands of Eddie, I managed to make myself a smooth movement function in c#. Can we use your command in c# instead ?
For the PING, do you know how to access this in c# ?
Thank you,
Jack jack
EDIT: Do we only have to balance DEADZONE and SAFEZONE ? Or is it more complicated.
I think there is a mistake line 515 of the file "eddie.spin", shouldn't we clear MidVelAcc[RIGHT_MOTOR] ?
I've been working on the code today. I think I'm to the point where I'm ready to test the h-bridge version of the code but I still need to finish wiring up my h-bridge.
I've been trying to make the two versions (Eddie Control Board with h-bridge and Propeller Activity Board with HB-25 controllers) as similar as possible. I'm hoping there will be just a few lines of code to change from one board to the other.
I think I have this working but I'm not so sure I'm ready to post the latest version of code without testing it with a h-bridge circuit.
Yes, this should do it. Pressing F11 also works.
Good. It turns out the h-bridge version of code uses one more cog than the HB-25 version of the code.
It was either lose the option for music or the option of controlling servos (another new feature).
I have not looked at the PC side of the code. In my testing, I've either used terminal commands or used a second Propeller board to issue commands.
You won't be able to use C# to program the Propeller directly (I'm not sure if you were asking that). It is possible to program the Propeller with C but I'm using Spin and assembly in this project.
You can interact with the Propeller board by sending and receiving serial commands. I haven't looked into how this is done on the PC side but I probably will investigate this in the near future. Your C# program should be able to access the Pings with the PING command. I don't know if you'll need to write your own function to do this or not.
Sort of yes (to both questions). I think modifying the value used for these constants could be useful but this problem really requires a more involved solution. Initially, I'll just disable the code which disables the motor control cog. My plan is to modify the motor control algorithm to allow one to precisely control the robot without having these encoder errors causing trouble.
The current algorithm counts encoder ticks within a set time frame (20ms) and uses this count (averaged over half a second) to compute the robot's speed. This is okay when the robot is traveling relatively fast but at really low speeds only one or two encoder ticks occur each control frame which really limits the precision the speed cam be controlled.
I've been working on computing the speed by timing the interval between encoder ticks but I've had some hardware issues which has slowed my progress (I think the issue with the right motor kept causing the Propeller to reset).
Correct. I noticed that typo myself. I'm still not sure what effect, if any, the typo had on the performance of the robot. To tell you the truth that section of code is still a bit of a mystery to me.
I minored in Physics in college so I like to think I understand these sorts of distance, velocity and acceleration type problems but I'm still having a hard time understanding what all the variable names mean. I'll be very surprised if I can't get this program to work much better than it is right now, but it will take me a while to do so.
Fortunately this sort of stuff is intensely fun to me.
Time for me to stop typing and wire up the h-bridge to test the code. I'm still hoping I'll be able to post the code today/tonight.
I hope you give the latest code a try and let me know how it works.
Edit(12/28/14): There's a bug in the code attached to post #34. Use the code attached to post #36.
I'm hoping someone tests my code with RDS 4 to make sure I preserved backwards compatibility.
I've moved the code to my GitHub account. You'll want to download the file "Eddie-Archive . . . .zip"
Since GitHub takes care of the version control stuff, I've dropped the date stamps from the file names.
I hope you give the new firmware a try and let me know what you think of it.
He maintains that a passenger car is "differential drive", since it uses a differential to drive the car.
"Differential steering" is his preferred term for the familiar tank-style steering used by nearly all small robots.
Except my new superbot. But I can say no more.
SUPERBOT, now you have me curious? You, can say no more. How about a picture?
Jim
Thank you for your work and uploading the firmware.
Unfortunatly, I can't test it on the robot. I had to deliver my school project (19 December) and a new student will continue it next year.
I managed to correct the firmware myself but I only had two weeks ( and others problems with Kinect and Microsoft Robotics) and one was already over, so I made a quick and dirty fix (Just remove the part who made the robot in error ...), and it "did the job".
Thank you again for having taken the time of helping me,
Best regards,
JackJack
I'm glad you got the code working. I hope you new student about the updated firmware. I've tested it with a normal h-bridge (instead of the HB-25 controllers) and the code appears to work correctly. I think the Ping sensors should work a lot better now that they're triggered sequentially.
Thanks for the update.