Rework Remote ID settings to new style

[DonLakeFlyer]

This should be a UI only change as opposed to a functional change. It is also mostly just a stylistic changes as opposed to any user model changes. Things should work the same behind the scenes. The older style UI is currently left as still available from App Settings.

Validation reporting in the ui is not yet supported. There are a bunch of problems with the way validation in the current codebase is split across C++ code and qml code. To fix correctly it's going to require some fairly involved changes. That will come in a subsequent pull.

This is a replacement for #11228.

[DonLakeFlyer]

Looking for help from folks that know Remote ID ins and outs to test this.

[julianoes]

I wish I knew the ins and outs of Remote ID, or maybe not 😄.

I think it looks nice this way. Does it collapse into one column on smaller screens?

[dakejahl]

I can test this tomorrow or early next week as well

[Davidsastresas]

If @dakejahl isn't able to test it I think I could manage to set up a device and test on a few days. Also @BluemarkInnovations might be able to assist on testing. Thanks!

[DonLakeFlyer]

Also in working with this more I'm getting a better understanding of how it all works. With that I think although this pull is functionally correct. It is incorrect from a usage standpoint. The current concept in QGC is that Vehicle Setup should be used for one time things. Stuff that you would set on a vehicle when you are first configuring it. Whereas the settings in the toolbar dropdown are for things which may need to be modified from one flight to another.

Given that I think the majority of these setting are one time setup stuff which should only be in Vehicle Setup (or maybe still in App Settings like they are now). The toolbar dropdown should include the broadcast options for Self Id where you identify the flight purpose which can change flight to flight.

Could folks give their opinions on this?

[Davidsastresas]

@DonLakeFlyer what you suggested makes sense to me, so I am alright with the change. Thanks!

[DonLakeFlyer]

what you suggested makes sense to me, so I am alright with the change. Thanks!

Ok, after this pull is verified to work I will merge this in. And then in another pull I will break this apart into App Settings stuff and toolbar indicator stuff in the right places.

[DonLakeFlyer]

Does it collapse into one column on smaller screens?

It scrolls horizontally/vertically as needed. Once this is split to App Settings and Indicator Settings it will end up being much smaller.

[dirksavage88]

Are the artifacts built using a newer version of Ubuntu? I am getting this error when running the artifact executable in ubuntu 22.04:

./QGroundControl-x86_64.AppImage 
./QGroundControl-x86_64.AppImage: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.32' not found (required by /tmp/.mount_QGrouneE5g5f/usr/bin/../lib/libexiv2.so.28)

[DonLakeFlyer]

Are the artifacts built using a newer version of Ubuntu? I am getting this error when running the artifact executable in ubuntu 22.04:

@HTRamsey ?

[HTRamsey]

It's built on 20.04. I think that might be from building with GCC 13, probably I need to use like 12 or 11.

[DonLakeFlyer]

@dirksavage88 I rebased to the Linux fix. Hopefully it will work for you now.

[dirksavage88]

Looks okay to me. I am not sure what to look for in regards to EU settings, but the FAA looks the same just with the layout change.

One thing to note is that in the new UI you are not able to set the Location type Live GNSS source to a serial port (if not the default UDP port). One would have to configure it in the Remote ID under application settings.

[DonLakeFlyer]

One thing to note is that in the new UI you are not able to set the Location type Live GNSS source to a serial port (if not the default UDP port). One would have to configure it in the Remote ID under application settings.

Oops, I screwed that up. I'll take a look at that part again.

[DonLakeFlyer]

One thing to note is that in the new UI you are not able to set the Location type Live GNSS source to a serial port (if not the default UDP port). One would have to configure it in the Remote ID under application settings.

I'm going to fix this in my subsequent pull (instead of here) where I reorganize what's on App Settings and what's in the toolbar indicator.

[DonLakeFlyer]

I'm going to merge so I can get going on the next phase of this work. @dakejahl Why don't you wait until a get this next pull in and then you can test that.

[BluemarkInnovations]

If @dakejahl isn't able to test it I think I could manage to set up a device and test on a few days. Also @BluemarkInnovations might be able to assist on testing. Thanks!

@DonLakeFlyer I will have look next week. If it is just moving the GUI to a different part of QGC, I think that is fine.

[BluemarkInnovations]

So I had time to review, My focus is more on the regulation side than the UI. It seems that in this PR the same functionality is moved to a different place. So that is fine by me.

However, there is likely an issue with the tamper resistance requirements. The FAA has accepted the F3586 with additions. These additions are found here: https://www.federalregister.gov/documents/2022/08/11/2022-16997/accepted-means-of-compliance-remote-identification-of-unmanned-aircraft

1. The remote identification system shall protect the part 89-required broadcasted message from being altered or disabled by any person.
2. The remote identification system shall incorporate techniques or methods that reduce the ability of any person to physically and functionally modify or disable any aspect or component of the remote identification system that could impact compliance with the remote identification rule.
3. In applying Section 7.5.2 of ASTM F3586-22, the applicant shall determine whether masking the specified items from user input adequately provides the functional tamper resistance protection specified by this means of compliance, and if it does not, shall incorporate additional functional tamper resistance techniques or methods in accordance with this means of compliance.

Bold part is mine. Now in the current implementation PR, I see the following issues w.r.t. to tamper resistance.

a) if no RID module is attached to the flight controller, the RID status icon is not shown. That seems to be non-compliant.
b) the current implementation allows the user to change RID settings e.g. the pilot location. It would be much better if some parts of the RID settings can be protected by a password, so only the drone manufacturer can change that. Examples are: region setting (including EU category and EU class). Pilot location settings.

I have audited my products regarding RID compliance and have been in talks with the FAA regarding RID. Although the tamper resistance requirement is a grey area, I can say -based on these discussions- that very likely the current implementation allows too much freedom for the end-user to disable or alter RID transmissions that results in non-compliance. (Hence it is non-compliant, because it is the responsibility of the manufacturer to enforce compliance in F3586.)