Guided value slider

[DonLakeFlyer]

Fixes #10743

See Issue for details

[DonLakeFlyer]

I'm lost. Creating a new pull didn't make it go away either.

[HTRamsey]

can you rebase locally and see what happens?

[DonLakeFlyer]

I already re-pulled the version you rebased tossing my old one. Trying to rebase that again just says it's up to date.

[DonLakeFlyer]

Let me try making a whole new branch

[HTRamsey]

I would drop my rebase and do a merge just to see if one of the older commits didn't rebase well

[DonLakeFlyer]

Stupid appveyor/ci#3585

[HTRamsey]

So I have no idea why the android builds fails to find gstreamer sometimes, but rerunning it works I think, I will look at it tonight. It might be related to the download from gstreamer's servers

[HTRamsey]

That's one of the things I will add to #11639
Edit: Nvm a quick google search gave me the answer. I can fix later today

[arnaudjuin]

That's one of the things I will add to #11639 Edit: Nvm a quick google search gave me the answer. I can fix later today

Any success or hint ?

[HTRamsey]

That's one of the things I will add to #11639 Edit: Nvm a quick google search gave me the answer. I can fix later today

Any success or hint ?

Sorry I've been working 15hrs the past few days and ran out of time. I will be able to do it tomorrow at the latest

[DonLakeFlyer]

@JMare Can you retest?

• Tick marks which are above/below allowed values are grey
• Indicator is always centered
• Fixed problem with setting below min alt

[JMare]

Nice! Away from my computer for a few days, will test on Monday

…

On Thu, 4 Jul 2024 at 3:26 AM, Don Gagne ***@***.***> wrote: @JMare <https://github.com/JMare> Can you retest? - Tick marks which are above/below allowed values are grey - Indicator is always centered - Fixed problem with setting below min alt — Reply to this email directly, view it on GitHub <#11641 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3Z5KWAHFELUOZNNBYVAQLZKQX4JAVCNFSM6AAAAABKCMAKPOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMBWHA3DAMZWGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[Davidsastresas]

I added a few commits addressing some issues testing with Ardupilot.

The only one I think should be discussed is the last commit, about changing altitudeAMSL to altitudeRelative. Before this one, the slider would represent the altitude AMSL, even though the label says "alt (rel)" and it always represented relative altitude. @DonLakeFlyer was this a mistake or this brokes PX4 functionality? From what I saw in the code the issue explained above should affect PX4 as well, but I could have missed something.

Other than that I think it should be fine now.

The new slider looks amazing by the way, great job, thank you!

[DieBorr]

Hi, I have been taking a look to the slider, I really like it, seems really nice with the actual UI. However there is something that at least for me does not make sense and is that the horizontal flickable is visible when there is a width resize, I don't know if it has been made on purpose, I have a commit ready to push if you confirm that if it wasn't intentional. Correct me if I wrong but I can't figure out a case where the horizontal flickable needs to be visible in the slider.

PD: as I look the screenshot I think that we can also bring the altitude text steps to the left so the flickable does not overlap them.

[DonLakeFlyer]

horizontal flickable is visible when there is a width resize

Ah, right that is screwed up. It isn't tracking contentWidth correctly on the flickable

[DieBorr]

#11663 solves overlap and makes some margin between text and slider border.

[DonLakeFlyer]

I'm gonna merge this in and then fix the horizontal thing in another pull...

[JMare]

@DonLakeFlyer, Tested, and fixed the issue I saw previously - looks good.

The only thought I wanted to raise - which isn't specifically related to this change is:
When doing a change alt, QGroundControl sends the new altitude as an offset from the current altitude.
This offset is calculate by taking the new desired altitude and subtracting the current altitude.

One consequence of that is that if the vehicle is climbing or descending while you do the altitude change, there is an inaccuracy.
For instance, in Ardupilot SITL, if you do a changealt to 25.0m while you are climbing, you may find the vehicle actually settle at 25.5m. I can imagine this would be worse with high climb rates or low telemetry rates.

Its a minor thing but do you know if there is any reason the normal relative altitude couldn't be sent rather than an offset?

[DonLakeFlyer]

Its a minor thing but do you know if there is any reason the normal relative altitude couldn't be sent rather than an offset?

If I remember correctly it's because PX4 firmware side does change alt as a delta offset. Let me look at the code again. Maybe better to send absolute all the way till it gets to mavlink and then adjust there. That way at least ArduPilot would get a good alt.

[DonLakeFlyer]

Yeah, I looked at the code. I can reverse this so that an absolutely altitude flows through until the last minute instead of an offset. That way at least ArduPilot can get a solid alt change in the case described above.

[JMare]

Nice yes I think that would be a good change, happy to help with testing. (or coding, but it sounds like you have it covered)

[DonLakeFlyer]

I had this backwards. It's ArduPilot that needs the offset change not PX4. Let me see if there is some different command I could send to get an absolute altitude change.