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 team@pybricks.com 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]

Hmm, this ist actually the one point where I also struggled. In the end I just copied the block from tic-tac-toe example.  vanczakp ***@***.***> hat am 28.10.2024 19:51 CET geschrieben:     I saw you were using blocks for the crane. I have never used it but own a license so I took the opportunity to try it out for the first time to see if I could rewrite the above in blocks and it is indeed possible like this:  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?     

…

-- Reply to this email directly or view it on GitHub: #1861 (reply in thread) You are receiving this because you were mentioned.   Message ID: ***@***.***>