Add support for the original SCI protocol #25
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ADD_PACKET(ID_CLIFF_RIGHT, 1, "cliff_right", V_ALL); | ||
| ADD_PACKET(ID_VIRTUAL_WALL, 1, "virtual_wall", V_ALL); | ||
| ADD_PACKET(ID_OVERCURRENTS, 1, "overcurrents", V_1); | ||
| ADD_PACKET(ID_DIRT_DETECT_LEFT, 1, "dirt_detect_left", V_1 | V_2); |
There was a problem hiding this comment.
I think for DIRT_DETECT_LEFT it should be V_ALL
|
Nice work I'll try it out on the Create 2 and let you know how it goes. |
|
Tried out the changes on a Create 1 and a Create 2. Everything seems to be OK 👍 |
|
@lopsided98 Could you please add a brief section to the README with links to the three supported protocols? Thanks. |
|
Thanks, if you squash your commits I'll merge 👍 |
…iginal SCI protocol.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for the original SCI protocol used by the Discovery and 400 series (though apparently not all of them) Roombas.
Since three robots are now supported, the existing system of specifying which model to use did not work that well. Therefore, I decided to create a new
RobotModelclass, which encapsulates the the wheelbase width, baud rate, and protocol version, as well as any other parameters that might differ between models.I added a new
ProtocolVersionenum which largely replaces the oldRobotModelenum in the various conditionals that decide how to communicate with the robot. The three protocol versions are based on the three documents that describe them:V_1- http://www.ecsl.cs.sunysb.edu/mint/Roomba_SCI_Spec_Manual.pdfV_2- http://www.irobot.com/filelibrary/pdfs/hrd/create/Create%20Open%20Interface_v2.pdfV_3- https://cdn-shop.adafruit.com/datasheets/create_2_Open_Interface_Spec.pdfLike we talked about, I split the
Serialclass intoSerialStreamand a newSerialQueryclass which uses the Sensors command to retrieve data.Since
V_1does not include the "drive direct" command, and this is a very important command for create_autonomy, I decided to emulate it using the "drive" command.I also had to emulate the mode retrieval and requested wheel velocities because they are not supported in
V_1. I decided to not request the requested velocity sensor packets (even when they are supported) since the exact same functionality can be gained by just caching the last requested velocities indriveWheels().I found that the odometry on my Roomba 400 is much better than on my Create because the angle field is implemented as "the right wheel distance minus the left wheel
distance, divided by two" and it does not have the same bug as the angle field on the Create 1.
I tested this on my Roomba and my Create, but there is a possibility that I broke the odometry on the Create 2, so I would recommend testing it.
Let me know what you think. I will have a PR for create_autonomy soon that supports these changes.