Hello. First of all, I am not a native, so please excuse any awkward expressions. I am seeking assistance with setting up an ESC telemetry-based notch filter.
I am using a T-Motor integrated propulsion system and have installed a T-Motor Datalink v2 to configure ESC telemetry. However, upon reviewing the LUA script, it seems that the RPM update rate is 100Hz. Also, since the communication speed of TX1 on the T-Motor Datalink is 115200 bps, I estimate that the transmission rate at the script’s maximum packet size is around 90Hz. Thus, with the current conditions, it appears that 100Hz is close to the hardware limit.
However, the Ardupilot ESC Telemetry Based Harmonic Notch Setup documentation states the following:
The rate at which the harmonic notch frequency is updated has a big impact on noise in the PID loops. Slower update rates mean that the frequency has larger step changes which result in what is called shot noise. Faster update rates reduce this and is the primary reason why using bi-directional Dshot with ESC Telemetry reporting of RPM benefits the system overall.
By default, the update rate is 200Hz, and where the source of frequency information is slower than that - for instance, when using ESC telemetry where the maximum rate that can be sustained is about 100Hz - ArduPilot will slew the frequency changes at 200Hz to avoid large steps. The slewed rate is the rate that is reported by ESC telemetry, although the raw rate can be seen in the logs as well.”
Here are the areas where I would appreciate your insights:
Would the RPM source of 100Hz for the ESC telemetry-based notch filter be an issue for a copter with an MTOW of 10kg?
I tried to assign a notch filter to each motor’s RPM by setting INS_HNTCH_OPTS = 2. Could this setting be problematic, or would it be better to set INS_HNTCH_OPTS = 0 to average the RPM of all motors, thereby reducing rapid filter movements?
TX2 on the T-Motor Datalink has nearly 9 times the bandwidth of TX1. Could using the TX2 port improve the RPM update rate?
I lack knowledge of control systems, so I am unsure how significantly a sudden change in the notch frequency would impact the control loop. Is this a serious concern?
According to the Ardupilot documentation, if the RPM update is slow, the notch filter changes will be slewed at 200Hz. Are any settings required to enable this?
Would the RPM source of 100Hz for the ESC telemetry-based notch filter be an issue for a copter with an MTOW of 10kg?
No
I tried to assign a notch filter to each motor’s RPM by setting INS_HNTCH_OPTS = 2. Could this setting be problematic, or would it be better to set INS_HNTCH_OPTS = 0 to average the RPM of all motors, thereby reducing rapid filter movements?
The setting you are using is better, should be fine
TX2 on the T-Motor Datalink has nearly 9 times the bandwidth of TX1. Could using the TX2 port improve the RPM update rate?
No idea
I lack knowledge of control systems, so I am unsure how significantly a sudden change in the notch frequency would impact the control loop. Is this a serious concern?
For a large copter not so much, I think you will get good performance with this setup
According to the Ardupilot documentation, if the RPM update is slow, the notch filter changes will be slewed at 200Hz. Are any settings required to enable this?
After setting up the above configuration, I conducted a flight and have a few questions for which I would appreciate your assistance.
The first image shows the IMU spectrum from the previous flight, where a noticeable noise spike originating from the motors and propellers can be identified.
The second image is the IMU spectrum from this flight. It appears entirely different from a typical multirotor IMU spectrum. It resembles one recorded on the ground, yet it is indeed a log recorded in flight.
The differences between the two flights are as follows:
Logging Method: The first flight used batch logging, while the second flight recorded using raw IMU logging.
Notch Filter: The first flight used a throttle-based notch filter, while the second used an RPM-based notch filter. I don’t believe this would have had a significant impact.
Wiring Adjustments: Between the two flights, I re-organized the wiring connected to the flight controller.
For both flight logs, the FFT window size was set to 1024. Reducing the FFT window brings the spectrum closer to that of the first flight log, but with reduced frequency resolution, making meaningful analysis challenging.
Thank you for your response. I also have three additional flight logs recorded with raw IMU data, which I can upload if needed. These flights show the same issue in the filter review as described above.
Initially, I suspected this issue might be noise characteristic of the ADIS16470 sensor. However, other sensors (IIM-42652 and ICM-45686) exhibit the same behavior.
Aside from the difference in resolution, the graph appears quite similar to the one with a Window of 256.
Fortunately, the notch seems to be tracking well, though it’s curious that the peak at the motor RPM has completely disappeared. If this result is accurate, would it be advisable to increase the LPF frequency for the gyroscope and accelerometer?
If you using the new INS_RAW_LOG_OPT you don’t also need LOG_BITMASK raw IMU bit. Pre+post on all gyros is probably just a bit too much logging. Do either all gyros or pre+post on primary.
After carefully rechecking the logs, I did indeed find frequent data loss in the IMU. I will apply the adjustments you mentioned and conduct another test flight. Thank you!
Before configuring for this flight, I thoroughly reviewed the documentation to prepare, but past habits led me to select the raw_imu option in the log_bitmask as well. This likely had a significant impact on the amount of IMU data loss. Visible guidance on this topic could be helpful for others as well.
It can be seen because you are transforming “mountains” into “valleys”.
That is not what you want, you want to make the “mountains” disappear without creating “valleys” at their place.
That’s correct. Filters inherently introduce delays, so it’s best to use them only as much as necessary. However, since the depth of a notch filter is less related to delay, I applied the commonly used -40dB attenuation.
Now that I think about it, a deep notch could indeed reduce the response at the frequency. From this perspective, would it be better to reduce the notch attenuation to create a flatter post-filter?
Indeed! I have confirmed that significant phase delays occur in the notched areas due to attenuation. The statement that the notch bandwidth has a greater impact applies more to smaller copters with higher RPMs. In this case, where the propeller RPM is lower (close to 30Hz), it’s clear that the notch attenuation also significantly affects the delay in transmitting the aircraft’s movements.
Thank you for the valuable insight and advice!
