Calibration and Homing

Software
1

Hello everybody!
My goals are:

  • define once for all the time the “zero configuration” of Solo, and
  • allow the motors to drive Solo to this zero config whenever the power is turned on.
    This objective arose because I don’t want to move manually the links to the zero config but I want to automate it. To do this, I proceed in this way.
  1. I manipulate the links in the desired zero config (in my case, the legs are orthogonal to both the floor and the hips) and I turn on the power
  2. I calibrate the encoders so as to find the nearest index, I save these displacements (these are offsets wrt the zero config, let call them offsets) and I turn off the power
  3. I manipulate again the links so as to reconfigure the robot close enough to the desired zero config and I turn on the power (in this way, the encoders read zero near to the desired zero, because this configuration does not completely match desired zero config)
  4. I calibrate the encoder so as to find the nearest index (if the config in point 3 is very close to the config in point 1, these indices should be the same found in point 2) and I save these displacements (these are offsets wrt the initial config in point 3, let call them offsets’)
  5. I set the motors offsets to (offsets’ - offsets)*gear_ratio_signed (the sign define the direction of the motor) and then I request to move to the zero config.

In my mind, with 5, the motors should bring the robot to the desired zero config (the one defined in 1), but actually they realize a completely different config :frowning:

Does anyone has tried to code a similar calibration and homing procedure? Or has experienced problems in setting motor offsets? May my reasoning be wrong?

2

Hello @francesco-roscia,

We use a similar technique to home the robot. You can find a python implementation here: solopython/masterboard_utils.py at master · thomasfla/solopython · GitHub

This code is being transferred to C++ with a cleaner code here:

but we still need to fix some issue related to the calibration, So better take inspiration of the python code for now.

3

Hello Francesco,

we have just recently designed calibration tools for the robots that align the legs in the zero position.
This should help you to determine the offset between the zero position and the next index more precisely.

GitHub Page Robot Calibration

Best.
Felix

quadruped_12dof_calibration_1
quadruped_12dof_calibration_1982×892 125 KB

2 Likes
4

These tools are really appreciated!

5

In these codes, it seems that nothing ensures that the zero config of a run coincides with the zero of another one. Isn’t it?

6

It is, since the offset from startup to first seen index is compensated for inside the uDriver.
The big advantage is that you can restart your controller without having to recalibrate the index, (provided that you did not power off the motor).

You can have a look at the udriver interface documentation and look at the offset compensation flag here: https://github.com/open-dynamic-robot-initiative/master-board/blob/master/documentation/BLMC_µDriver_SPI_interface.md#mode

I will try to better document the homing procedure when I have some time.

To get convinced, you can run the main_solo8.py or main_solo12.py from solopython repo.

I hope this helps,
I will try to better document the calibration procedure as soon as I have some time.

Best,
Thomas

7

Sorry @thomas.flayols, in the previous reply I was not precise enough. I meant that your code seems not able to drive the robot in the zero config after you have turned off the power (am I wrong?). So, everytime you turn on the power supply, you have to manipulate the robot joints to accomplish the zero configuration. I don’t want to get my hands on the robot too much; meanwhile, I desire to be sure that, everytime I turn the power on, Solo can go to the same zero config. Are your codes able to manage this?

Thanks for the time you are dedicating to me

8

Ok I understand, however, I’m afraid that what you want to achieve is not possible on solo hardware. Indeed, the index on the motor codewheel are not sufficient to know the joint positions due to the gear ratio of 9:1. The encoder will see 9 index pulses per joint revolution.

The best we can do, is to manually bring the legs close to zero, then the calibration procedure will find the closest index and calibrate accurately from that.

The hardware solution would be to have a second encoder at the joint side, preferably absolute. An other solution is to have an encoder that is able to memorize/count the pulses even when power off.
The two solution has been excluded due to complexity and space…

9

I have another question. If I keep the motorboards turned on but I reset the motherboard, can the offsets still be compensated or they will be lost (requiring another calibration)?

10

Hi again,

You are talking about the Masterboard right?

If so, not really… Although the udriver boards (motor control boards) will have the offset’s information, they will be in an error state as soon as the masterboard dies (Timeout), and there is no possibility to reset this error other than reset the power all board (by design).
On all our robots, we have the power lines shared between the masterboard and the udrivers.
Can you explain why you would like to power off the masterboard?

On the other hand, if by motherboard, you mean your control computer, then yes, you can restart your PC (or the network connection between the masterboard and your PC) and keep the calibration active.

In practice, we have to calibrate only at the power up of the robot, and until the robot is powered down we do not have to recalibrate. If an experiment goes wrong, we try to kill the controller by software instead of by hardware Power E-STOP, so that we can latter reconnect without having to calibrate the robot again.

I hope this helps,
do not hesitate to ask if something is still not clear.
Best, Thomas

1 Like