give velocity commands in hover is a very nice feature.
I actually use RC roll/pitch setpoints to tune PID horizontal guidance gains. But I suppose this will be also possible using speed setpoints?

give velocity commands in hover is a very nice feature.

Giving velocity commands in hover is not done yet. I'm also not sure what the best way is to implement that... (give actual velocity commands or rather move the position setpoint)?

I actually use RC roll/pitch setpoints to tune PID horizontal guidance gains. But I suppose this will be also possible using speed setpoints?

I'm not quite sure I understand... how do you tune guidance gains by additionally adding roll/pitch setpoints via RC? While you can probably tune the PID part a bit it is not the same as flying in nave, as your ff and horizontal guidance ref are zero...

I think we should give velocity commands and use the guidance_h_ref generator with update from speed.
This is consistent with RC_CLIMB mode for vertical control loops.

About tuning: I use roll/pich setpoint to move the rotorcraft from hover position. Then I release the sticks to see how the rototcraft comes back to hover position. This is equivalent to a wind gust moving the rotorcraft in nav mode, so you can see if the tuning is fast but stable, otherwise P and D term of the guidance_h loop can be tuned.
But this test can also be performed by moving the waypoint in NAV mode, without reference generator.

The problem with the current simple gh_update_ref_from_speed_sp that if you can't follow the ref (e.g. not well tuned, wind, etc..), the position setpoint will be further and further away from where you are.
And when you release the stick it will continue flying to the position setpoint that is still further away.
And when you give a zero velocity command you want it to stop quickly... should the new position setpoint be exactly where the vehicle was when speed sp was set to zero? Then it would briefly continue (inertia) and come back to that point.
Also you can't just simply set the the position setpoint to the current position if the speed sp is zero.
That would mean you keep setting the pos setpoint to your current position even if external forces push you away from the original position.

If the "rc_max_speed" is set to reasonably small speed, 4 m/s for example.
Then the reference will certainly stay close to the actual position, even
with wind?
To me that feature would be similar to rc_climb mode: it works well with
"reasonable" saturated speeds.

IHMO just advancing the reference from the speed setpoint does not give satisfatory results (neither for vertical).
It works OK if it's well tuned, but we should think about how we could improve that (ie. stopping where you are when you let go of the stick).

I think resetting a setpoint to the current position when stick released could be useful, but... it can cause other problems. People may think the airframe is tuned well enough (but it isn't), so they switch to nav and have troubles.
Imho at the first step would be reasonable to simply use gh_update_ref_from_speed_sp, but reduce the default max ref speed to, for example, 1,5-2m/s. As soon as they will be unsatisfied with the max speed (which could mean the proper tuning), they can increase it.

Time for a new quadcopter for me.. Then some October wind and my tests can continue... For sure a good development for real flights in real scenarios, nice!

@dewagter, @OpenUAS, @gautierhattenberger, @softsr, @Drumettaz
I would like to merge this rather sooner than later to master, any objections?

THX, will be put to the test again asap