I have ran into an issue with heli governor underspeed condition. It triggers even if the RPM drops due to external factors.
In my case throttle curve isn’t an effective fallback as there is significant voltage change between fully charged and discharged battery leading to significant changes in headspeed at given throttle setting.
I propose that governor should not disengage during underspeed condition if Heli RCS output is close to maximum as this typically leads to decrease in commanded HRSC output.
I can implement that logic but would like to first get feedback on the idea and especially safety considerations.
I have set ±200RPM range though the in practice the controller keeps it ±30RPM, (telemetry resolution is ~14RPM).
The RPM drop was caused by governor output saturation (throttle=1), that itself was probably caused by some ESC configuration change during avionics tidying (swapping ESC configs is PITA with AM32).
The RPM situation looks to be stabilizing just before the governor quits at ~10:49.
Is there a tool to anonymize a log that keeps it in the .bin format and maybe strip/decimate select messages? As I am working on the heli the logs are quite big, BTW the maximum file size message seems to be wrong, file stripped to be ~5.5MB (5.26MiB) doesn’t fit.
PS I will play with ESC settings after fixing the battery attachment which dissipated a lot of landing energy .
for trimming the log down you can use mavlogdump.py and select only the packets you need exported or trim it based on time stamp. You should export in .csv so it’s easy to work on it and plot using Excel or Octave.
Do I see it correctly, it seems RPM went down (orange line)?
If my assumption is correct then it seems the governor did it’s job correctly until conditions for quitting were met.
Yes. That’s the point I argue about, IMHO the condition is wrong. If the governor is doing its best (outputting full throttle) we shouldn’t drop it for the throttle curve, which most likely has lower values.
Not really, 2 3d printed loops with dovetail attachments,.the first version was PITA to replace as it had internal spacer integrated.
there is currently no protection against rpm input errors on the rpm itself. So the feature prevents the governor from “chasing” non existent rpm drops due to sensor non correct working. If this protection wasn’t there the governor could easily (and very dangerously) overdrive the rotor. Remember there is no logic to manually disengage the governor in such situations, it all relies on internal rpm check to be in range.
It appears that rpm drop was due to low voltage, probably ESC cutting off due to low voltage protection settings?
I think it is safer to keep the logic as it is right now, but in your case I would definitely try using a higher RPM range (provided the helicopter still controllable and flyable at the low end of voltage range).
That is why I would want to limit the action to throttle at 1. when the underspeed starts. IIRC. It should be an option anyways. In my case the only reason RPM error can happen is ESC desync as this is a direct drive heli.
This helicopter has flown down to ~7.5V before, though that was before I reduced RPM. It had issue with too high vibrations (~40 @4800RPM now it is 10-15), I want to put longer blades on it anyways.