Dynamic notch filter on IMU_APPS based on Motor RPM

[LucaVertiq]

@James-Strawson
Hey James,

We chatted at AUVSI about getting dynamic notch filtering working. Right now I have all the basic stuff implemented, but am running into two issues.

The first issue is that even in a sandbox I'm having trouble creating an appropriate notch filter. I've looked at how PX4 and Ardupilot do it, but I'm not seeing as much attenuation as I'd expect. Seeing as you wrote the filter library, I was wondering if you had any notch filters already written. My filter knowledge is rather lacking.

The second issue is that ESC telemetry is only reported across the 'mavlink_onboard' topic at 10hz. I think I'd rather have it be a bit faster.

I was wondering if you had any insight into either of these. Here's the repo I've been working off of:
https://github.com/vertiq-luca/qrb5165-imu-server/tree/feature/rpm_filter
It's just mavlink rpm data feeding a low pass filter for now until I can get my notch filter to work, but it does appear to be filtering!

Best,

Luca

[LucaVertiq]

@Moderator bump?

[LucaVertiq]

@Moderator So I was able to get the notch filter working, but I'm still wondering if there's a way to get the mavlink onboard to publish faster than 10hz.

They dynamic notch filter as really improved the VIO on my vehicle which is very prone to vibrations.

[Eric Katzfey]

@LucaVertiq You could add the command mavlink stream -u 14556 -s ESC_STATUS -r 20, for example, to the file /usr/bin/voxl-px4-start to increase the rate to 20hz.

[LucaVertiq]

@Eric-Katzfey That worked perfectly! Thank you. I put all the dynamic notch stuff on my github. I know James mentioned he wanted to implement it.

[James Strawson]

@LucaVertiq Great work!! I'm going to be OOO for a while but as we discussed before I'm happy to review it when I'm back and integrate into the SDK.

[LucaVertiq]

@James-Strawson just checking, are you interested in this at all?

[Alex Kushleyev]

Hi @LucaVertiq , this is cool stuff. I am curious if you were able to do any direct comparisons of qvio performance using unfiltered vs low pass (rpm-based) vs notch (rpm based)?

In order to replicate the same conditions for each test, this would have to be done using mpa playback after collecting mpa logs of just imu data and images.

since the rpm data is not coming from mpa, it cannot be logged / played back using our logger.

However, one idea is to process the IMU data logs using RPM logs using a separate script and then run the playback + qvio to generate new results. The IMU data processing can have different options like the rpm-based notch filter and it would obviously also need to have a px4 log that contains the ESC status.

This also leads to a question, whether the IMU data should be filtered in the imu server or the application that uses the imu, since the requirements for the IMU data may differ for different applications, so it may be best to leave the IMU server publishing the original data. But also, there could be a separate output pipe from the imu sever with the notch filtered imu data..

Anyway, just wanted to check if you happened to get any quantitative results from your testing that show how the filtering helps with QVIO performance. My understanding from working with QVIO in the past was that the best thing to do was to feed unfiltered imu data into QVIO and let it integrate the noisy data. low pass filtering the IMU data too much would actually remove some of the actual components of motion that are important for motion tracking. So i am curious what exactly has improved in your case when you added notch filtering - is the drift vs distance improved or the number of VIO "blow-ups" has reduced?

Lots of questions, but I am happy to discuss this further and see how we can improve performance of our VIO stack

Alex