I’ve recently noticed that Stretch doesn’t quite turn far enough when commanded to rotate by a certain amount, and it actually seems pretty significant. So I thought I’d check what accuracy should be expected, and whether there are known fixes for improving/recalibrating it.
More information is included below. If you have any comments or suggestions, that would be great!
Testing methodology and results:
- Manually align the front edge of Stretch’s base with a line on the floor
- Command a rotation of +/- 90, 180, 270, or 360 degrees (since they’re easy to evaluate by eye)
- Record what Stretch thinks is the current angle
- Manually rotate Stretch to the desired angle, either by using the runstop and physically rotating the base or by using the Xbox teleoperation
- Record what Stretch thinks is the current angle
- Take the difference between the two angles to compute the error of its original turn
Sample video of the above test procedure, showing a significant error after commanding a 360-degree rotation
Results with various commanded angles
Python script to implement the above tests
The offset is actually quite linear with respect to the commanded angle, with Stretch falling short by about 0.034 degrees per commanded degree (using a linear regression with a forced 0-intercept).
I might try to use this relationship to adjust my commanded angles, but I worry that this may be brittle from day to day and that there is an underlying cause for the offset which we should fix if possible.
Additional notes:
- In addition to using
robot.base.rotate_by() as in the above Python script, I’ve also tried using robot.base.set_rotational_velocity() and waiting for a duration calculated using both the speed and acceleration (assuming a trapezoidal profile). The results were similar.
- Stretch seems to estimate linear drive distances quite accurately; for example, commanding a drive of 100cm actually does result in a 100cm drive. I haven’t checked whether it drove perfectly straight though, and I haven’t rigorously repeated this experiment.
- I used Stretch outside a bit on a flat sport court that I cleaned ahead of time using a leaf blower and a push broom, but there was probably still some dust and whatnot. Could that have impacted the motors/encoders and thus the rotation estimate (but not the linear drive estimates, since those still seems accurate)?
- The serial number is STRETCH.RE1.1022
Hi. Thanks for bringing this to our attention, and for the thorough test procedure. We’ll dig into this today and let you know if we can find something.
We were able to replicate the behavior you describe. In addition we confirmed that in translation it is quite good – as accurate as our ‘measuring stick’ type measurements allow. This was tested on a hardwood floor.
I believe the issue is the ‘wheel_seperation_m’ parameter. It is set to 315.4mm with the factory settings. This is the centerline of each wheel. In practice, the effective baseline may differ due to wheel scrubbing, or the mechanical tolerance stackup of the base. Even a small variation on the effective baseline can result in fairly large errors in rotational accuracy.
By adding the following to your code we estimated the effective baseline:
pct_error=degrees(wrapToPi(offset_rad))/360.0
d=(pct_error+1)*robot.base.params['wheel_separation_m']
print('Error of %f (pct)'%(pct_error*100))
print('Used wheel seperation of: %f'%robot.base.params['wheel_separation_m'])
print('Recommended wheel_separation_m %f'%d)
Your measured error of 0.034 degrees / commanded degree would indicate you have an effective baseline of 326.1mm. On our test robot we calculated an effective baseline of 320.1mm.
The baseline can be adjusted by adding the following to your $HELLO_FLEET_PATH/$HELLO_FLEET_ID/stretch_re1_user_params.yaml:
base:
wheel_separation_m: 0.326
, or whatever value works best for your robot. If it is OK with you, we can create and share a tool based on your code that will allow users to estimate and record their effective wheel baseline.
Below shows the CAD of the wheel separation to give you an intuition for the numbers here.
1 Like
Great, thanks a lot for looking into this! The wheel separation sounds like a good explanation for the observed linear offset, and a nice way to embed the compensation at a lower level than scaling the commanded angles. So far it seems like the base rotations are much more accurate after adjusting the parameter, although I ended up setting it to be a few millimeters larger than what the script recommended. We’ll see how it goes, and hopefully it’s relatively constant over the course of long experiments or even days/weeks.
Feel free to use any of the code to make a calibration tool - I’m glad it might be useful for other Stretchers! In case it’s helpful, here’s the Python script that I ended up using for myself
It explains the equations used, does a calibration turn, computes the effective wheel separation as you suggested, and optionally updates the yaml file (which works for me, but I’m not sure how robust the file parsing is).
Thanks for sharing the code. We’ll integrate it into the standard factory tools for the robot.
