Firmware source for Eddie robot
goupil35000
Posts: 10
in Robotics
Hello,
I want to ask my students to add other functionalities and test some new algorithm on control of the wheels for my Eddie robots (I know that Eddie is now deprecated). They will have to program in C on the propeller.
Is-it possible to get the source of the last firmware for Eddie robot ?
Thanks.
I want to ask my students to add other functionalities and test some new algorithm on control of the wheels for my Eddie robots (I know that Eddie is now deprecated). They will have to program in C on the propeller.
Is-it possible to get the source of the last firmware for Eddie robot ?
Thanks.
Comments
The version for the original Eddie board is located in the archive "Eddie - Archive [Date 2015.01.01 Time 20.21].zip" in my GitHub repository.
I added an ARC command and I improved the way the Ping sensors are read. I also added an integral component to the control algorithm so the motors don't stop a few encoders ticks away from the target destination.
I posted video of some encoder tests here. There's a video using hardware I hope approximates the original Eddie hardware and there's also a video using Arlo hardware.
I don't have an original Eddie board so I haven't tested the Eddie firmware on the real hardware. I hope you let me know if there are any unexpected behaviours using the new firmware.
Thanks a lot. I will test with Eddie and I will tell you if all is ok on Eddie robots.
Just one question; is-it the code for the firmware distributed by Parallax ? We have applications that work on Eddie robot directly with commands defined in "https://www.parallax.com/sites/default/files/downloads/550-28990-Eddie-Command-Set-v1.2.pdf".
Do you change things in this ?
Thanks.
PS: I have some problems with original firmware about timing when I send commands to the robot
All the commands should be backwards compatible.
The most significant change is likely the way the Pings are used. The previous code triggered all the Pings at once and returned the distances from the sensors. The caused a slight delay between when the Ping command was issued and when data was received. The biggest problem with this strategy was all the Ping sensors were triggered simultaneously. These simultaneous pulses had a very good chance of interfering with each other. I noticed this interference with my own robot which is why I changed the code to continuously monitor the Ping sensors and return the last readings when the Ping command is issued. This difference in time is not likely to be an issue but it should be kept in mind that the returned data from the command were readings taken prior to the command being issued rather than after the command had been issued.
I personally think the advantages of this continual reading approach greatly outweighs any disadvantages (if there are any).
Please let me know if you continue to have these timing issues. I have not tested the firmware with the ROS program.
While I tried to keep all the original commands backwards compatible, I added some additional commands for convenience. Rather than just having the command "DIST" where the distance needs to be entered in encoder ticks, I added the command "MM" which does the same thing as "DIST" except the units are millimeters.
I did a lot of my testing my entering commands from a serial terminal so I add a command "DECIN" to allow decimal values rather than hexadecimal. To use decimal input the command "DECIN 1" would be issued. "DECIN 0" would set it back to hexadecimal input. I added a similar "DECOUT" command to make it easier to interpret the output from the program.
A variation on the "ARC" and "ARCMM" commands are the commands "PATH" and "PATHMM". "PATH" and "PATHMM" are similar to "DIST" and "MM" but rather than a single distance value, these commands accept two distance values. I thought these commands would make it easier to precisely control the motion of the robot.
The additional commands should all be documented in the comments of the top object. I think there are some PID related commands which I haven't implemented yet.
There is an couple important constant you'll want to set. The value "POSITIONS_PER_ROTATION" is two times pi times the distance between the robot's wheels (in encoder ticks). I found it very difficult to measure this value directly. Instead, I'd have the robot spin in place ten times and see how close to the starting orientation the robot was. If the exact number of rotations were made, then I know the value of "POSITIONS_PER_ROTATION" was correct. If the robot's orientation wasn't correct, I'd adjust the value "POSITIONS_PER_ROTATION" up or down until I couldn't get a better result.
Likewise, if you want to use the "MM" command, you will want to make sure the value "MICROMETERS_PER_TICK" (in the header object) is correct. I think I determined this constant by having the robot travel some set distance and compared the actual distance travelled to the distance commanded to travel. It's not likely you'll need to change this value.
I'm pretty sure I've written these instructions before. I really need to keep one location where this information is provided. Now that I think of it a bit, the GitHub readme seems like a good place for this sort of information.