No problem! First, a few items that may / may not self evident:
The uC reports an ‘effort’ which is then scaled in the Stepper class of Stretch Body to current (A).
There is a low pass filter of the reported effort signal that runs on the uC. You can find its values under your
stretch_re1_factory_params.yaml. As configured it has a roll-off of 2hz
You can overwrite the default value by including it in your
stretch_re1_user_params.yaml, for example:
The Lift joint is unique in that it needs to support itself against gravity. Thus it has a non-zero feedforward current (A)
You could extend the Lift.move_to( ) to also allow setting of the i_feedforward to the uC on each control cycle. You’ll see that Stepper.py passes the term down on each push_command()
The tool stretch_lift_jog.py can be useful to experiment with the Lift. On my robot, when I jog the lift up and then down, and then allow the reported force to settle, I see roughly 10N of hysteresis. (Note: These reported forces are only only rough approximations of Newtons).
You are correct in noting that for the reported force, the feedforward current is first subtracted off - so with an ideal transmission it would be zero when the arm is not in motion. See
, in Lift.py
The non-ideal reported forces of the Lift and the arm will vary based on the history of the motion (eg, hysteresis on up vs down). The will also vary somewhat based on the position of the arm. As the arm extends the friction of the telescoping mechanism will increase. As the arm and lift retract, the internal cable winding mechanisms will apply increasing and possibly discontinuous forces that the motor must fight against. You can get a sense of these forces by backdriving the two joints with the Runstop enabled.
Below are the motor parameters of the motors.
Base wheels and Arm:
Good luck, let us know if you need anything else. We’d love to see the admittance control in action once it is working.