General-purpose calibration mechanism

[davidjsherman]

Documenting a discussion with Christophe and Paolo. Not sure when this is the right idea or not.

Robots are manufactured with components of different characteristics. Adding calibration in manufacturing is not cost-effective. Field calibration is possible under two conditions:

1. Having a mechanism for adjusting values on the fly based on stored calibration parameters
2. Having a reliable test program and calibration environment that deduces parameters

Christophe has observed that the correction of motor speed, for example, depends on the speed. Sensor response is nonlinear, but the unreliable sensors have the same curve, just squashed. My intuition is that a low-cost affine y = Ax + b transformation will be good enough (testable hypothesis!).

Proposed firmware modification

The proposal is to:

1. Add a table of (A,b) parameters in the flash memory, initially (1,0) for each sensor and motor.
2. Change the firmware so that at runtime it applies this transformation on the fly to each value, either when reading (sensors) or writing (motor target).

This will consume 11 words of flash memory, and will add approximately 66 cycles to the microcontroller's update loop.

For example, when the Aseba program asks to set the target motor left speed to 300, and the flash parameters have (105,6) stored because the physical motor is 5% slower than expected, the value actually applied would be (300*1.05+6) = 321. For example, a batch of ground sensors that measure at 80% of the expected value, would have flash parameters (125,0), and convert a measured value of 420 to 525.

Plan B (plan Z): compiler modification

If it is not feasible to change the firmware, the Aseba compiler could be changed to take into account an optional robot profile, consisting of the calibration parameters. The generated code would apply these transformations when reading or writing. Advantage: no modification of firmware. Disadvantages:

• Bytecodes would not be portable between robots. Possibly not a problem since usually programs are recompiled anyway, except when loaded automatically from the SD card
• Since the transformation is done in bytecode, it will be slower and reduce available program memory
• The Studio will need access to a catalog of robot profiles or a means of loading one.

Calibration environment

The calibration environment could be a 1000mmx1000mm box with off-white walls and a fixed ground pattern. It could be built by any user or by a local support service. With the right ground pattern, the time series of left and right ground sensor events for a given motor speed is enough to deduce: ground speed (from the intervals of the events), left/right motor delta (from the phase of the events, since the delta will induce a curved path), and ground sensor grey level detection (from the measured values).

Since printers have different ideas of grey levels, it might be more reliable to use a black and white dither pattern. The ground sensors see out of focus anyway.

The proximity sensors can be calibrated from the dimensions of the box, only once the motor speeds have been calibrated.

[stephanemagnenat]

The calibration of such a robot can perfectly be done with a simple procedure, we built a nice calibration procedure for the marXbot (see marxbot-calibration.zip) which uses similar technology. As far as I remember (and can read back from my code), an affine function was used for both the motors and the sensors. The trick is to sample a distance in a good range for the sensors.

Now whether it can be done in the factory, I have trouble being convinced it cannot. The procedure for the marXbot took only 2 minutes to perform, so I do not see why it cannot be implemented in our production line.

I strongly oppose modifying the compiler, there is no rational reason not to do it in the firmware.

[stephanemagnenat]

I'm bringing the economic question offline.

Indeed, regardless of who performs the calibration, the firmware should allow it there is no good argument, excepted the lack of time to develop it, not to do it.

[davidjsherman]

Maybe also an offline question, can we assume sensors ±50%, motors ±20%? Arithmetic precision is going to be a question.
If A is signed 8 bit fraction added to 1.0 and b is signed 10 bits, and sensors have 7 useful bits of value, I think we can do each transformation in 6 cycles without overflowing the registers.

[stephanemagnenat]

In the marXbot we used the math.muldiv native function that does the multiplication in 32 bits, so it was not a problem even in the aesl code. The processor is far enough powerful for that kind of simple operations.

[mbonani]

Hello,
For the motor I understand and see the need. For the sensors it is less evident for me, it is not something that could be cool for scientist but didn't matter for most users?
Also you has to know that motors and sensors have already values stored in flash.

For the motors it is already a absolute variation for the speed. For the setting mode we just correct relatively so that the robot go straight. We can think about something so that we correct also the absolute speed and the rotation. Something that people can do home, think about all robot in nature, it as to be compatible. I think doing something like Christophe do for thool but with the value stored in the flash it is possible.

For the horizontal sensors there is also a kind of automatic calibration based on the smalest value ever seen in robot life. It was put because there was some sensors on a batch (10%) that react very differently of the other. It was not trivial to make and I do not want to break that.
For the ground sensor there is nothing, should perhaps have something. But there is a big disparity in the batches and we have now problem in production for that. We need more information about the producer of the senors (I just send a repport on monday).

More generally it is not the problem of doing or not in production and the cost of it, but more the time to develop and install it in production that will be time consuming.

Also having something that is back compatible is very important for me.

[stephanemagnenat]

For the motors it is already a absolute variation for the speed. For the setting mode we just correct relatively so that the robot go straight. We can think about something so that we correct also the absolute speed and the rotation. Something that people can do home, think about all robot in nature, it as to be compatible. I think doing something like Christophe do for thool but with the value stored in the flash it is possible.

The problem is that for blocks such as "go forward 30 cm", not only going straight is important, but the distance must also be correct. Reaching that is just a matter of improving the calibration procedure already in place.

For the horizontal sensors there is also a kind of automatic calibration based on the smalest value ever seen in robot life. It was put because there was some sensors on a batch (10%) that react very differently of the other. It was not trivial to make and I do not want to break that.

The calibration on the marXbot was using the smallest value (step one was to measure the values when no obstacles), but then a factor was computed at a specific distance (a ring was put around the robot), and finally the saturation value was measured. I do not see any reason not to do the same for the Thymio, the only added difficulty is that we cannot use a ring due to the shape of the robot.

For the ground sensor there is nothing, should perhaps have something. But there is a big disparity in the batches and we have now problem in production for that. We need more information about the producer of the senors (I just send a repport on monday).

I do not remember what we did for the marXbot, do you?

More generally it is not the problem of doing or not in production and the cost of it, but more the time to develop and install it in production that will be time consuming.

I agree, but we already developed the full procedure for the marXbot, and the codes are still around (see my attachment).

Also having something that is back compatible is very important for me.

What do you mean? Which use case?

[davidjsherman]

Concerning the sensors, since the Braitenberg coefficients are hardwired in the firmware behaviors, if the absolute values from the sensors are very wrong then the preprogrammed behavior for that robot can be very different. The same is true for the sample programs (suiveur.aesl etc.).