tilt sensor measured angle changes while no movement of technic hub

[vanczakp]

Hello all, I wanted to create the weight overload function to my Liebherr crane and got a similar but different issue.
While the crane was stable the tilt of hub was around 9deg and stable (no rubbers, jut at the end position). Then I moved the hub, then released to initial position where the tilt was 9deg. Tilt value started to decrease, and after one minute it was around 7.5 only. Same happened when I wanted to have a program which keeps a tank's turntable in position regardless where it is moving. I was told it is due to the sensor re calibrates itself as it heating. Can you advise how to eleminate this issue?

[laurensvalk]

If you want to measure tilt, it would be best to use the tilt() method as the name implies.

If it is reporting a decimal value of 7.5 then it sounds like you are using a different method?

[vanczakp]

I was surprised it has like 10digit accuracy because few months ago and few firmware update earlier the same command gave me integer only.
I use beta block coding only. Used the get "hub name" rotation y+ output block in a repeat cycle with print of value and wait of 500ms.
Firmware update was yesterday

[laurensvalk]

Right. So it would be better to use tilt() to measure tilt.

If you use rotation(), then 3-dimensional movements all affect each other. There is also some drift. You can use this in fast moving applications.

For things that are almost stationary, like cranes, tilt is usually the simpler option.

[vanczakp]

Thanks. That woud be the pitch, right?

Anyway this is still half solution, its okay for weight overload, but I have an another big project, automatize a lifle like lr13500. For that, to keep the supestructure always on levele, I need more precise measurment than an integer, i need like 1/10 deg or 1/100 accuracy and I definetly want to avoid measuring the accelerations. I want to measure the angle of main and derrick boom as well because counting the cable winch rotation is overkill and unstable.
So the question still applies: do you have plan to eleminate the drift? When it happend the crane was laying on a shelft and the turntable was turned off so it was really a rotation around one axis.

[laurensvalk]

Pitch or roll, depending on which axis you're tilting along. I'm open to a feature request to return tilt as floating point values.

I definetly want to avoid measuring the accelerations

This is ultimately what the tilt() method is doing.

[Debenben]

I would recommend:

• Use acceleration and calculate the angles yourself, that way you are not affected by gyro drift like rotation() and you are not limited to integer precision like tilt()
• Calibrate the accelerometer with an offset e.g. somthing like [Feature] User IMU calibration ideas #943 (comment)
• Take an average of at least 10 accelerometer readings

The above should get you to 1/10 deg accuracy without problem, I checked this by attaching laser pointers to a technic hub.

• In case you need more precision you could calibrate it more precisely, e.g. like described here https://www.nxp.com/docs/en/application-note/AN4399.pdf
• In case you need faster reaction time or want to compensate for different temperatures or things like that and you are not afraid of writing some C functions and compiling your own firmware, you should be able to e.g. set a low-pass filter on the accelerometer on a hardware level. If I am not mistaken you can also add a calibration offset here https://github.com/pybricks/pybricks-micropython/blob/master/lib/pbio/drv/imu/imu_lsm6ds3tr_c_stm32.c#L430 with something like

uint32_t pbdrv_imu_get_acceleration_offset(pbdrv_imu_dev_t *imu_dev) {
    uint32_t offset = 0;
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_usr_offset_get(&pt, &imu_dev->ctx, (uint8_t*)&offset);
    lsm6ds3tr_c_xl_offset_weight_get(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t*)((uint8_t*)&offset) + 3);
    return offset;
}

void pbdrv_imu_set_acceleration_offset(pbdrv_imu_dev_t *imu_dev, uint32_t offset) {
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_offset_weight_set(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t)(offset & 0x01000000));
    lsm6ds3tr_c_xl_usr_offset_set(&pt, &imu_dev->ctx, (uint8_t*)&offset);
}

I have not found motivation to test this further because I do not need that much accuracy, but I would be interested to see the results and help if someone else wants to.

[vanczakp]

Pitch or roll, depending on which axis you're tilting along. I'm open to a feature request to return tilt as floating point values.

I definetly want to avoid measuring the accelerations

This is ultimately what the tilt() method is doing.

Thanks, that would be great if you could do it!

I would recommend:

• Use acceleration and calculate the angles yourself, that way you are not affected by gyro drift like rotation() and you are not limited to integer precision like tilt()
• Calibrate the accelerometer with an offset e.g. somthing like [Feature] User IMU calibration ideas #943 (comment)
• Take an average of at least 10 accelerometer readings

The above should get you to 1/10 deg accuracy without problem, I checked this by attaching laser pointers to a technic hub.

• In case you need more precision you could calibrate it more precisely, e.g. like described here https://www.nxp.com/docs/en/application-note/AN4399.pdf
• In case you need faster reaction time or want to compensate for different temperatures or things like that and you are not afraid of writing some C functions and compiling your own firmware, you should be able to e.g. set a low-pass filter on the accelerometer on a hardware level. If I am not mistaken you can also add a calibration offset here https://github.com/pybricks/pybricks-micropython/blob/master/lib/pbio/drv/imu/imu_lsm6ds3tr_c_stm32.c#L430 with something like

uint32_t pbdrv_imu_get_acceleration_offset(pbdrv_imu_dev_t *imu_dev) {
    uint32_t offset = 0;
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_usr_offset_get(&pt, &imu_dev->ctx, (uint8_t*)&offset);
    lsm6ds3tr_c_xl_offset_weight_get(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t*)((uint8_t*)&offset) + 3);
    return offset;
}

void pbdrv_imu_set_acceleration_offset(pbdrv_imu_dev_t *imu_dev, uint32_t offset) {
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_offset_weight_set(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t)(offset & 0x01000000));
    lsm6ds3tr_c_xl_usr_offset_set(&pt, &imu_dev->ctx, (uint8_t*)&offset);
}

I have not found motivation to test this further because I do not need that much accuracy, but I would be interested to see the results and help if someone else wants to.

Will check it when it comes, thanks for the advise!

[vanczakp]

@laurensvalk please check the [email protected] mailbox. I sent you my version of 42146 controls. I would like to see what you think!

[vanczakp]

@Debenben would you please share the angle calculation of yours you mentioned (1/10 precise)? I would really appreciate it.
I placed a technic hub into the main boom (for ballast and the tilt sensor does not have accelerometer).
Thanks in advance!

I would recommend:

• Use acceleration and calculate the angles yourself, that way you are not affected by gyro drift like rotation() and you are not limited to integer precision like tilt()
• Calibrate the accelerometer with an offset e.g. somthing like [Feature] User IMU calibration ideas #943 (comment)
• Take an average of at least 10 accelerometer readings

The above should get you to 1/10 deg accuracy without problem, I checked this by attaching laser pointers to a technic hub.

• In case you need more precision you could calibrate it more precisely, e.g. like described here https://www.nxp.com/docs/en/application-note/AN4399.pdf
• In case you need faster reaction time or want to compensate for different temperatures or things like that and you are not afraid of writing some C functions and compiling your own firmware, you should be able to e.g. set a low-pass filter on the accelerometer on a hardware level. If I am not mistaken you can also add a calibration offset here https://github.com/pybricks/pybricks-micropython/blob/master/lib/pbio/drv/imu/imu_lsm6ds3tr_c_stm32.c#L430 with something like

uint32_t pbdrv_imu_get_acceleration_offset(pbdrv_imu_dev_t *imu_dev) {
    uint32_t offset = 0;
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_usr_offset_get(&pt, &imu_dev->ctx, (uint8_t*)&offset);
    lsm6ds3tr_c_xl_offset_weight_get(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t*)((uint8_t*)&offset) + 3);
    return offset;
}

void pbdrv_imu_set_acceleration_offset(pbdrv_imu_dev_t *imu_dev, uint32_t offset) {
    struct pt pt;
    PT_INIT(&pt);
    lsm6ds3tr_c_xl_offset_weight_set(&pt, &imu_dev->ctx, (lsm6ds3tr_c_usr_off_w_t)(offset & 0x01000000));
    lsm6ds3tr_c_xl_usr_offset_set(&pt, &imu_dev->ctx, (uint8_t*)&offset);
}

I have not found motivation to test this further because I do not need that much accuracy, but I would be interested to see the results and help if someone else wants to.

[Debenben]

Hi @Debenben, I cant recreate the blocks of yours. In the for position range... I cant add the position after get #. How did you do it?

Hmm, this ist actually the one point where I also struggled. In the end I just copied the block from tic-tac-toe example. 

[Debenben]

@vanczakp Sorry for taking some time to answer. Did it work as expected?

• I tested the new firmware and results look quite good.
• I saw there was an error in my python code, I fixed it in the code above by adding list()
• In case you want to average, I would recommend to put the value aquisition in its own task without sleep and let it run as fast as possible and only sleep in print function. In case that is still relevant I can show you in more detail.
• Not sure if you noticed, but I thought I'd mention it: When you position the hub in the crane, make sure the angle of the main boom is the "roll" angle. The convention pybricks uses is like that on a plane: first heading, then pitch, then roll. You want to first apply the angle that the crane is tilted sideways due to it standing on a slope, this is therefore "pitch". Afterwards you apply the "roll" as position of the boom around the mechanical axis which is pointing along this slope. If you mistakenly take "pitch" as the angle of the boom, the roll angle becomes the rotation of the boom along the booms forward axis. If you do it the wrong way your roll angle gets unstable when the boom is pointing up since it is then your heading which you cannot measure with gravity. If you do it correctly the same happens to your roll angle (the boom position) when the crane has fallen over and is lying sideways, but I guess that is not a use-case.
• The imu has an integrated temperature sensor which would require changes in firmware in order to read out. I do not think it is worth the effort but I thougth I'd mention it in case temperature is a big problem for you.
• The external tilt sensor from lego unfortunately only outputs integers. A little improvement is possible by using sensor.read(3) instead of sensor.tilt() to get full 360 degree instead of just -45 to 45.

@laurensvalk I guess my problem was that I tried dragging the position block when the text input was active (I guess it is only dragging text and not the block in that case). The text-selection mouse cursor when hovering over the input box is a bit misleading because you first have to click in order to select text, I think it would have helped me if it was dragging or selecting mouse cursor instead. In my opinion one could even hide the functionality to rename the iterator behind double-click or long-press since renaming is some esthetic improvement useful in nested loops while getting the value is essential.

[vanczakp]

hello @laurensvalk ! No problem.

• It did work as expected, but the tilt sensor in the technic hub is more accurate. After 5 minutes when there is no drift anymore the tilt sensor's value range was around 0.05 (min max of few minutes measurement with one sec sampling rate) compared to the accelerometer's 0,1 range.
• regarding the roll pitch: I have to check it If I get it right but I get what it should mean and I have to check if I did right.
• The external tilt sensor accuracy is a pity. I wanted it to use for calibrating the actuator and the spanner cable of derrick boom when start up. I have the form to link the actuator movement to the cable but it depends on the angle a lot and 1deg is not enough, On the other hand the value I get from it is way too unstable when the boom is moving, it can jump +/-10 degrees easily then back... I'll do the floating ballst version with moving derrick boom but first the V-frame which requires static derrick boom.

I spent the last few weeks to make the crane more robust, I think I reached the max I what someone can achieve. Main problem is when the crane is in balance, standing on a completely flat ground, and I rotate the turntable, I can measure the imperfection of the bearing via getting different angles from the superstructures. I realized my floor is not close to flat at all (some area has 0,8deg slope). Rotating the crane on slope gives you even more strange angles as the turntable tries to push back the hole structure to balance. I must do a DOE and see the and the impact of different slopes on the measured angle (two hubs (90deg rotated to each other) measures the floor angle )
On the other hand I just realized If I change the ballast weight then I would need different gain for the control curcuit. So I just questioned myself if it worth it or not. Its getting too much, regardless I have all the knowledge to do it.