Noise on servo output when changing mag cal params in QGC

[CarlOlsson]

• Flashed latest master 29795fa95fb07c7e383e73cb725aec60fb88d948
• Powered up the plane (Wingwing with pixracer) and connected QGC on iOS and via wifi.
• Armed to manual mode to start logging
• In QGC, pressed reset to default on the mag0 cal parameters, noticed that every time I pressed it the servos moved on the plane.

The discontinuities in IMU.MagY and MagZ are when I reset the mag cal parameters.

[LorenzMeier]

Can you share the log? In what flight mode was the system?

[CarlOlsson]

Sorry forgot to share the log. I couldn't find it again so did another one, now with ulog. Its here Both logs where in manual mode, Nav_state = 0

[LorenzMeier]

Am I correct to assume that the last spike is due to you tapping / moving the vehicle? If that assumption is correct then the servo response isn't a surprise because you're resetting a sensor and consequently the filter responds, resulting in a control system response.

[CarlOlsson]

The last spike is definitely me moving something. Maybe I'm missing something here but the plane is in manual mode, so no controller is running. Did the test again, log is here Now I am moving the plane around, the flaps are not moving at all since it is in manual mode, every time I press "reset to default" on the mag0 cal parameters the servos move slightly. Nothing major of course, but it is there

[LorenzMeier]

Sorry, I don't understand that log - it looks like the only servo motion is when the RC inputs got moved. Is this the right log file?

[CarlOlsson]

It is the right log, sorry if my description of the issue was unclear. The issue is that in manual mode, when pressing the reset to default button in QGC on the mag0 calibration parameters the servos experience a small spike in the output signal. Sometimes it is big enough that you can see it on the flaps, sometimes it is smaller so you can only hear it.

This is from the log posted above.

[dagar]

Have you seen this recently Carl? If you see it again with a new log (.ulg) I have some things to check.

[CarlOlsson]

Will do a test later today (Y)

[CarlOlsson]

@dagar I can't try this on our test plane with pixracer since I can't calibrate it, it is out of memory on current master.

Is this a known issue?

[dagar]

Partially. The memory used is dependant on how the system is configured. The pixracer is especially bad because it starts so many mavlink instances by default (esp8266, telem1, telem2, usb if connected).

Do you have USB connected? Do you have anything anything connected to telem 2 (set SYS_COMPANION appropriately)? Is logging started at boot or at arm (it allocates a large buffer)?

Most users don't hit this, but there are many short term workarounds. We'll need to provide a better fix after v1.7.0.

[CarlOlsson]

I just tried setting up two systems with current master on pixracers, one phantom wing and one small quad configured with generic racer airframe. On both systems I reset all parameters, so everything default. On the first one I can't calibrate mag due to memory, on the second one (the quad) it was possible to do it but 50% of the times I try to arm I get mag inconsistency error. When trying to debug it in NSH I get

ERROR [uorb] mem alloc failed
update: 1s, num topics: 9
TOPIC NAME         INST #SUB #MSG #LOST #QSIZE
sensor_baro           0    3   68    58 1
sensor_mag            0    2   44    33 1
vehicle_gps_position  0    8    5    16 1
sensor_mag            1    2   44    33 1
sensor_accel          0    2  248   237 1
ERROR [uorb] mem alloc failed
ERROR [uorb] mem alloc failed

Do you have USB connected? Do you have anything anything connected to telem 2 (set SYS_COMPANION appropriately)? Is logging started at boot or at arm (it allocates a large buffer)?

Yes USB was connected since I could not get the wifi module to work on master, no nothing on telem 2, logging is started on arm. I will try to debug it further tomorrow

[CarlOlsson]

Also, maybe it is not related but after I calibrated mag (and not doing anything) I got in QGC: "arming denied, low battery".

[dagar]

Try without USB and set SYS_COMPANION to 0 (at least temporarily).

[CarlOlsson]

Set SYS_COMPANION to 0 -> now I could connect via wifi, tried rebooting and arming 5 times, worked(Y). Only reported issue was mag tout

Will try the servo noise on param reset tomorrow

[CarlOlsson]

@dagar yes the servo noise is still on master logfile

[dagar]

Thanks, that's helpful. It might be the FMU module itself updating params or general param save perf issues.

[dagar]

Actually, it's higher level. Actuator controls is published by the attitude controller.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CarlOlsson]

This should probably be tested once before closing

[dagar]

Please post a fresh log if you see the behaviour again with current master.

[dagar]

@CarlOlsson https://github.com/PX4/Firmware/pull/11485 might be the culprit here. Every time the parameters update the sensors module can miss a sensor update. If a sensor update is missed, the EKF and FW attitude controller miss an iteration.

[CarlOlsson]

interesting! But why would the actuator output change when the vehicle is disarmed and the EKF and FW attitude controller miss an iteration?

[dagar]

Is this still present in master?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.