# iRobot Create 2: Angle Measurement

I have been working on trying to get the angle of the Create 2. I am trying to use this angle as a heading, which I will eventually use to control the robot. I will explain my procedure to highlight my problem.

I have the Create tethered to my computer.

1. I reset the Create by sending Op code [7] using RealTerm. The output is:

bl-start
STR730
2007-05-14-1715-L
Roomba by iRobot!
str730
2012-03-22-1549-L
battery-current-zero 252

(The firmware version is somewhere in here, but I have no clue what to look for--let me know if you see it!)

1. I mark the robot so that I will know what the true angle change has been.
2. I then send the following codes [128 131 145 0x00 0x0B 0xFF 0xF5 142 6]. This code starts the robot spinning slowly in a circle and request the sensor data from the sensors in the group with Packet ID 2. The output from the Create seen in RealTerm is 0x000000000000, which makes sense.
3. I wait until the robot has rotated a known 360 degrees, then I send [142 2] to request the angle difference. The output is now 0x00000000005B.

The OI specs say that the angle measurement is in degrees turned since the last time the angle was sent; converting 0x5B to decimal is 91, which is certainly not 360 as expected.

What am I doing wrong here? Is the iRobot Create 2 angle measurement that atrocious, or is there some scaling factor that I am unaware of? are there any better ways to get an angle measurement?

• Is 6 in "packet 6" a typo? "Create Open Interface_v2.pdf" shows Group Packet ID 6 returning 52 bytes instead of half a dozen. Also, why not use ID 20? Also see the question create2 angle (packet ID 20), Apr 28, 2015 at 20:26
• Great catch; I have updated the post. Using [142 20] works, but the problem is the same. Apr 28, 2015 at 21:23

There is a known bug in the angle command. We are still working on a workaround. In the meantime, please extract the angle yourself by using the left and right encoder counts. See this question for detailed equations.

• I have been trying to work with the encoders. I use the same procedures and experimental setup detailed above. I call [128 131 145 0x00 0x0b 0xFF 0xF5 149 2 43 44]; it reads 0x00010001. Then, after moving 360 degrees, it reads 0xF97C0693, which when plugged into the equation listed in the other post yields -117.639 (that lots of radians!). Do you have any advice on what I need to change to get a usable measurement? I searched the document linked in the other post and could not find a direct derivation of the angle equation. Will the measurement be invalid if the robot spins in place? Apr 28, 2015 at 21:22
• I get the correct result. The left wheel is 0xF97C ticks which is twos complement for -1668, the right wheel is 0x0693 which is 1683. $\frac{(1683 \pi 72 / 508.8) - (-1668 \pi 72 / 508.8)}{235}$ = 6.34 radians = 363.2 degrees
– Ben
Apr 28, 2015 at 23:38
• Isn't the encoder count an unsigned integer? Is it possible to just treat the encoder count as signed despite what the OI spec says? Apr 29, 2015 at 0:57
• Thank you for pointing this out. The encoder counts are indeed signed. The document will be updated fixed shortly.
– Ben
Apr 29, 2015 at 15:33
• The summary table in "Create Open Interface_v2.pdf" also shows angle units as being in mm (rather than degrees or something) so while fixing the docs you could adjust that too. Apr 29, 2015 at 18:19

To get the firmware version:

To get what software the robot has, connect it to a serial application (such as PuTTy) and turn the robot off then on. It should print it out then

New says: r3_robot/tags/release-3.4.1:

old says: r3_robot/tags/release-3.2.6: