Gimbal/Joystick: implement rate commands

[julianoes]

This pull request changes the behaviour of the joystick Gimbal Up/Down, Left/Right commands. Instead of sending an angle and increasing that angle with a step (using repeat) we now send the angular rate.

The way it works is that we:

1. Send the angular rate command when either button is pressed.
2. Keep sending that command at 2 Hz to allow the autopilot to stop again with a timeout.
3. Send a last command with rates set to zero when the button is released again.

We should probably allow a user to adjust the angular rate commanded which is currently hard-coded. I'm not sure where the right place for this would be.

Fixes #11956.

[HTRamsey]

@julianoes could you set the parent of the GimbalController to be the vehicle and then remove the deleteGimbalController() from the vehicle class? If not I can make a separate PR to do so later.

Edit: Gimbal needs a parent too

[julianoes]

Feel free to add commits @HTRamsey. I'm not too sure what you mean.

[HTRamsey]

Okay will do. Just FYI when you do something like in this picture, it sets the vehicle as the parent of the GimbalController. When QObjects are deleted, they also delete all of their children automatically

[julianoes]

I think that's actually on purpose:

qgroundcontrol/test/Vehicle/RequestMessageTest.cc

Lines 43 to 44 in 617b651

	// Gimbal controller sends message requests when receiving heartbeats, trying to find a gimbal, and it messes with this test so we disable it
	vehicle->deleteGimbalController();

[HTRamsey]

Oh I guess that function can stay then, although the parenting stuff should still be done

[julianoes]

Done @HTRamsey.

[HTRamsey]

Nice thanks. QmlObjectListModel _gimbals; isn't created dynamically with a parent but since GimbalController calls _gimbals.clearAndDeleteContents() it should be fine

[Davidsastresas]

I will check this on the next few days, sorry, but I read that matter about making it automatically get destroyed with vehicle destructor, and that was actually a workaround to fix tests, at least in 4.4 for the way tests were done this hack was needed, I don't remember exactly the details but I wanted to mention in case you guys find the same issue. Thanks!

EDIT - I actually saw you dealt with this on the next messages. Sorry I posted this response too fast!

[Davidsastresas]

Good catch the gimbal parent front. It wasn't being deleted until now right? so we had memory leaks if vehicle disconnected, not huge but we had, right? EDIT - Sorry I read the whole thread and indeed we were calling that clearAndDeleteContents(), it was alright. Good catch anyway, we should be setting parents on those, Thanks!

I checked your solution for rates, very elegant as usual! I like how you managed to control the timer to avoid timeouts. I tested in SITL Ardupilot and it works great. Indeed this is much much nicer than having steps, this feels much more natural, yet you still have somehow precise control to just move a few degrees.

I added the rate used by buttons to the Settings panel in cfdadfd, only visible if we have joystick connected and active:

I was tempted of using the same speed used for click and drag, but I thought a particular setup could benefit of different rates for both, so I made a new setting for buttons specifically.

On the other commit I fixed the buttons that got broken by the QGCButton restyling, text out of sight

Having confirmed this works correctly, we should update click and drag to use rates too. I was tempted to do it now, but I remember we had some issue in android, apparently android is not processing press and release as desktop, so that was the fundamental issue with click and slide for android, so I think we can address that maybe other time in a different PR.

Thanks Holden, Julian!

[julianoes]

Amazing, thanks @Davidsastresas! And great that you could test it with ArduPilot and it works!