Guidance indi hybrid using ref model causing false velocity reference

[EwoudSmeur]

Now guidance indi hybrid uses by default a reference model. However, the force forward setting works by setting the setpoint velocity vector to a high value, and (if the velocity setpoint is large) forcing the horizontal speed in the direction of the nose to the cruise speed. If the desired velocity suddenly switches to the opposite direction, the reference model velocity vector can pass through zero, causing a desired hover, even though force_forward is true.

As a side note, debugging these issues is quite difficult since the update to nav_hybrid, as a multitude of functions in multiple files are involved. I think some simplifications might be required to be able to understand what is happening.

[dewagter]

Thanks for finding the cause.
We might need 3 states: force-hover, force-forward and automatic/free. For tailsitters the current code might be better (no need to make a large turn), but for quadplanes with hover props off, zero airspeed command should not ever occur.

[gautierhattenberger]

If I got it right, we have several ways to fix that:

• use an appropriate ref model that behaves differently is the norm of the speed vector should be preserved or not
• limit the variation of the speed setpoint variations from hybrid nav
• stop pretending that all hybrids are the same (you don't steer a tailsitter, a quad plane or other fancy things the same way) and make dedicated nav functions (probably implementing one of the previous option)

Regarding the complexity of the GNC layers, I agree that it is complex, but handling so many things from the same framework is also complex. I'm in the process of rewriting the stabilization and a part of guidance (yes, again), to make things a bit cleaner (I hope so, at least). It takes more time than what I would like.

As a side note, the current way to link the INDI guidance with the horizontal/vertical guidance (vertical does nothing, horizontal "push" the thrust with ABI) is really dangerous (and a pain to maintain). If a rotorcraft enters FAILSAFE, it just set the throttle to 0. We broke a quad this morning because of that.

[EwoudSmeur]

Thanks for your comments!

@dewagter The force-hover could be useful for the rotating wing drone. Regardless of the type of aircraft, if there is a force_forward feature it should work.

@gautierhattenberger I now fixed it by taking out the reference model, but then the speed setpoint wasn't used, so I had too add some lines: #3052. If you would like to use the reference model, then indeed a solution like you propose could be implemented, but it doesn't seem trivial.

Would it be an idea to at least combine vertical and horizontal guidance? This separation I always find hard to explain when introducing Paparazzi to others. It's a simplification that doesn't generally hold true, yet we base the structure of the guidance around it. It could also reduce the amount of files and functions one has to be simultaneously aware of.

Also, sorry to hear about the quadcopter crashing. I don't yet understand why it would give zero throttle in failsafe, it would not receive the thrust increment and instead use the stabilization command thrust like normal, no? At the time it seemed like a flexible way of implementing it. How would you suggest to improve it?

[EwoudSmeur]

@gautierhattenberger Maybe a bit off topic but also a bit related, since we calculate angular rates in the guidance (from yaw stick in manual, or from turn rate in automatic guidance) we can feed forward the body rates along with the attitude setpoint. I'm wondering how this can be best implemented. Would it be best to change the StabilizationSetpoint and deal with all the possible options of having an attitude setpoint but no rates, having rates and no attitude and having both?

[gautierhattenberger]

@EwoudSmeur The Horizontal/Vertical separation is clearly inherited from the fixedwing where this assumption is holding most of the time. But even for "rotorcraft" types and associated, the separation exists at the flight plan level, so you can somehow see this as an implementation oriented choice.
Nevertheless, the new approach I'm following now is based on function composition (instead of imperative style modifying global variables...). So it means that at the end you write more or less actuators = stab(guidance(nav())).
For now, I wasn't planning to change the guidance H/V separation (too much work for one step), so it would be act = stab(guidance_h(nav), guidance_v(nav)). If you want something else, you can using the "generated" autopilots (e.g. merging stab and guidance: act = all_in_one(nav).
Regarding your second point, my new design have the options for : attitude (quat, eulers or ltp) or rates, in float or integers. I didn't consider the case for attitude and rates, but why not. There is also a thrust setpoint, absolute or increment, float or int.

[dewagter]

@gautierhattenberger great development.
@EwoudSmeur this can really help to improve control. To me it would be quite obvious what to do when not all is filled. If only attitude is sent you have feedback on att. It att and rate are sent, rates are feedforward and attitude feedback. If only rates are sent, then it should be feedback control on rates. Note that in racing we also use feedforward rate derivatives.