Remote ID showing failed GCS GPS for Live GNSS

[dirksavage88]

Using the bluemark dronebeacon db201 connected over mavlink serial to the FC.

I am using a usb connected GPS module to the ground station and I am showing the live coordinates update in QGC, along with altitude. The GCS GPS still shows failed. Sometimes altitude will show negative, but this only happens rarely.

Not sure if the GPS coordinates are updating fast enough, or the failed arm status has something to do with it. Heading shows N/A, horizontal accuracy around ~13m

• Operating System: Ubuntu 20.04
• QGC Version: main
• QGC build: linux, downloaded the appimage
• Flight Controller: holybro 6c
• Autopilot (with version): Px4 main
• Dronebeacon DB201

[BluemarkInnovations]

This could be an issue of ArduRemoteID release 1.10. Do you have the same behavior with 1.11?

[BluemarkInnovations]

It could also be that the QGC RemoteID function needs to be adapted for PX4. This is what @Davidsastresas said back in the days "In case you are familiarized with QGC, we will implement it as a plugin in the vehicle class, and from there each of the firmware plugins ( px4 and Ardupilot ), might have some slight differences in how they send/receive messages, and this is the only possible extra development that would be needed to add PX4 support, so probably really straightforward"

[Davidsastresas]

It could be the GPS not refreshing fast enough. Are you testing outdoors? if testing indoors this could be the issue. If the GPS data is older than 2 seconds it will be discarded ( as per remote ID specs ) and so the GPS indicator will be red. Also for FAA I think altitude is mandatory, so if altitude is not all right it will fail as well.

@BluemarkInnovations thanks for pinging me!

[dirksavage88]

I will try it outdoors, I vaguely remember it working once indoors but that could have just been luck getting good sat coverage. Testing so far has only been indoors with a ublox m7

This being the issue would make sense, since I got the module to work at one point, so assuming the firmware is working as intended.

EDIT: Unfortunately moving outside did not correct the failed GPS despite the altitude and lat/lon updating at a decent rate. I get really bad coverage in my area even outside. However I could also try to update the module and see if changes anything.

If anyone would like to try it in PX4 you can compile and load firmware based on this branch: https://github.com/dirksavage88/Firmware/tree/remote_id_arm

[BluemarkInnovations]

I discovered that there is a bug in the Remote ID function of QGC. If I don't attach a USB ublox M7 receiver, the Remote ID function seems to cache the location. See attached screenshot. I haven't attached a GPS receiver for weeks, but still it shows a location. So the setup is ArduPilot with Remote ID enabled that is flashed to a Cube OrangePlus and a db201 module.

@dirksavage88 perhaps you have the same bug. Can you verify that you used the correct external GPS port? In my case if I connect first a Cube OrangePlus, the first two serial ports are the Cube. Then the third one /dev/ttyACM2 is the GPS device. If I connect the GPS first, then it gets the /dev/ttyACM0 port. You can easily detect which port the GPS device is: a) looking at the dmesg output b) cat /dev/ttyACM2 in case ttyACM2 is a GPS port it will output raw GPS information.

@Davidsastresas: is this a bug or intended functionality?

[dirksavage88]

@BluemarkInnovations I have confirmed I have the correct serial port and there is nothing else on tty/ACM*. It also looks like the data is updating so it is not stale data from a previous connection.

Looking at our screenshot differences, your GNSS Lat & Long float precision looks different. It's defined here: https://github.com/dirksavage88/Firmware/blob/3c0b8d348765a7470fa0ba422d16c07f3adfa22e/src/modules/mavlink/streams/OPEN_DRONE_ID_SYSTEM.hpp#L94

Not sure if that makes a difference.

[BluemarkInnovations]

@BluemarkInnovations I have confirmed I have the correct serial port and there is nothing else on tty/ACM*. It also looks like the data is updating so it is not stale data from a previous connection.

Looking at our screenshot differences, your GNSS Lat & Long float precision looks different. It's defined here: https://github.com/dirksavage88/Firmware/blob/3c0b8d348765a7470fa0ba422d16c07f3adfa22e/src/modules/mavlink/streams/OPEN_DRONE_ID_SYSTEM.hpp#L94

Not sure if that makes a difference.

@Davidsastresas: can you let us know how to debug? In my opinion the status of the GCS GPS icon (color) should be independent of the Remote ID status. I.e. something of the Remote ID functionality of QGC not PX4 or ArduRemoteID.

[01Sathiya]

Using the bluemark dronebeacon db201 connected over mavlink serial to the FC. I am trying to use my tablet location as GCS location, but unable to esablish the GCS location. can anyone please help me with it.

[Davidsastresas]

Hello all, sorry for the late response. So, first of all, how the GCS GPS indicator works. All of is in remoteidmanager.cc. Also, we have some logging messages enabled, that throw some information about why GCS GPS went red, if it changed from green to red. For that you need to enable remoteidlogging in QGC, and check the console. You can do that clicking the top left QGC icon, going to console, bottom right corner "set logging" and ticking remoteidmanagerlog.

Now about the logic, it starts as red by default. It will only go green if:

• Location type is set to fixed, and the coordinates introduced make sense.
• For live GPS, it needs to be a valid coordinate, the gps data needs to be 5 seconds old or less AND, if selected FAA region, it also needs to have healthy gps altitude ( mandatory as per remoteid specs for FAA ). I suspect the latest point is what was leaving it red on your screenshot @BluemarkInnovations.

Now about when it goes red:

• Location type fixed, if the introduced coordinates are out of range, if they don't represent real world coordinates.
• For live GPS, exactly the opposite conditions that trigger it to be green.

So, in other words @BluemarkInnovations, it is not tied in any way to Remote ID status, GPS indicator is independent to it, and only depends on the GCS GPS status.

It does have a caveat, which is that all the above is evaluated real time each time QGC attempts to send the System id message. And in order for QGC to attempt that, it must have received previously a remote id status message, so QGC knows it is connected to a RID device. And this is what I suspect to be the issue on the first screenshot of @dirksavage88, it would explain it, because it seems the rid coms is red, meaning it didn't receive yet an arm status message from RID/PX4. This could be what is happening as well on the latest screenshot of @01Sathiya .

It probably needs to be fixed somehow. I think the best approach would be to hide all the indicators minus RID coms when RID coms are read. I think that would be what makes most sense.

[Davidsastresas]

PR done to address this, as I do agree it is confusing for users #10704

[dirksavage88]

RID comms status red is fixed in https://github.com/PX4/PX4-Autopilot/pull/21647

But still having failed GPS. I've attached a log file. rid_debug.txt

[dirksavage88]

Update: It looks like I was able to get GPS to show green after updating to v1.11 of Dronebeacon.

@BluemarkInnovations could you comment on the error in the screesnip below?

Version	1.11 (05b4e041)
Board	BlueMark db200
Up Time	0:07:48
Free Memory	140952

Everything is green except arm status: it complains about a missing basic ID messeage?

[BluemarkInnovations]

@dirksavage88 It has been quite busy lately, unable to test the PX4 build myself yet, hopefully tomorrow or early next week.

With respect to your question. In the default settings of the Remote ID module (db201) there is no serial number programmed. The reason is that most vendors will use their own serial number. It means that you have to do that yourself:

• use droneCAN GUI tool using the CAN bus. Set the basic ID info: UAS_ID (can use your own or the provided one) and also make sure you set ID_type to 1 and UAS_type to your drone type.
• use the Remote ID function of the QGC. See https://user-images.githubusercontent.com/18221398/221088101-a3e1c3a8-2028-4447-a53e-bb32634c462b.png Here, you can enter BasicID info and enable it to send this to the db201. If the db201 has not saved a serial number yet, it will use this information and will store it in the device itself. So next time it will use that basic ID information.

Above can also be verified using the Android app: https://play.google.com/store/apps/details?id=org.opendroneid.android_osm In the current settings, the basic ID info should be indeed empty. If you have programmed using the steps above, it should also be received by this Remote ID app.

[dirksavage88]

Do these open drone ID modules really need to check all the boxes on operator ID and self ID? A lot of this info seems redundant. It's just creating streams (some of which have arrays filled with placeholder characters). Seems like waste of bandwidth for just placeholders.

So we are adding 6 streams of which most of the data is either zero or placeholder characters. How much of these messages are actually required by FAA/EU regs @BluemarkInnovations ? @Davidsastresas do you know if Ardupilot has had any concerns over Mavlink bandwidth issues with the addition of these ODID messages?

[Davidsastresas]

As far as I know Ardupilot implementation is working nice so far.

QGC implementation was done following FAA/EU requirements, and adjusts accordingly when you select each region. Not all of the messages are mandatory. Here is the part of the code that sends RID messages:

https://github.com/mavlink/qgroundcontrol/blob/4433837670ef9456f3dc0dcf3e30035326c9fd0c/src/Vehicle/RemoteIDManager.cc#LL156C38-L156C38

So basically the only mandatory message to be sent regularly is SYSTEM, and OPERATOR_ID if europe. You can disable the rest of them in the remote id settings page. The messages are sent from QGC at 1Hz, so I don't think that would be significant for bandwidth usage.

[BluemarkInnovations]

Do these open drone ID modules really need to check all the boxes on operator ID and self ID? A lot of this info seems redundant. It's just creating streams (some of which have arrays filled with placeholder characters). Seems like waste of bandwidth for just placeholders.

So we are adding 6 streams of which most of the data is either zero or placeholder characters. How much of these messages are actually required by FAA/EU regs @BluemarkInnovations ? @Davidsastresas do you know if Ardupilot has had any concerns over Mavlink bandwidth issues with the addition of these ODID messages?

I think there is some confusing here and also some work to be done in ArduRemoteID firmware.

ArduPilot more or less caches all Remote ID messages from the GCS (QGC) and if a message is not set, it will send empty messages to the RID module (for instance selfID and operatorID). It means that the GCS (QGC) only needs to send one OPEN_DRONE_ID_SYSTEM and follow up messages can be the bandwidth saving OPEN_DRONE_ID_SYSTEM_UPDATE message.

The ArduRemoteID firmware checks if various messages present: https://github.com/ArduPilot/ArduRemoteID/blob/master/RemoteIDModule/transport.cpp#L34

So the current PX4 implementation need to send empty operatorID and self-ID messages to get a GOOD_TO_ARM status. It is not a perfect implementation and needs improvement. For the US only the system message and having basic ID info would be mandatory to get a GOOD_TO_ARM status. For the EU it would be system & operator message and having basic ID info to have this arm status. In addition, the arm status check function should also evaluate if the proper broadcast protocols would have been set. (The allowed ones vary per region.)

In my view adding a region parameter to ArduRemoteID and use that parameter in the arm_status_check function for the proper checks per region would be a solution to this.

A comparison of required Remote ID info per region: https://github.com/opendroneid/opendroneid-core-c#comparison

edit: added the region parameter description. Somehow lost in the initial comment.

[dirksavage88]

@BluemarkInnovations thank you for clarifying the required messages. I was able to get your module working in PX4 and it allows arming when all conditions are satisfied.

My other question:for FAA regs the live gnss is required for operator position? Or will take off location suffice? The link with the ruling breakdown by region was a bit confusing on this caveat. I do agree that we should have region parameters in Arduremote ID. The more offloading of these checks to the module is better since the autopilot should only be a consumer of the arm status message and not have to deal with the streams directly. Of course it is also a source of UA position and altitude.

[BluemarkInnovations]

For standard Remote ID the live operator position is mandatory. See https://www.faa.gov/uas/getting_started/remote_id/drone_pilots

In case the module acts as a Remote ID broadcast module, the take-off position could also be used. I have ideas to make a PR for that to ArduRemoteID (using the options parameter), but haven't found the time for it yet...

Most users of Remote ID (manufacturers) want to fly BVLOS and for that standard Remote ID is mandatory. Outside USA, the take-off position can be used (I think).

Very nice to hear you got ArduRemoteID/db201 working in PX4!!

[GlidLov]

yes please, i endorse the idea of "fixed" take off position rather than live. I live in EU. This would render the module, once properly configured, 100% working also with older versions of Qroundcontrol or other GC software which does not have the remote id broadcasting functions.

[BluemarkInnovations]

yes please, i endorse the idea of "fixed" take off position rather than live. I live in EU. This would render the module, once properly configured, 100% working also with older versions of Qroundcontrol or other GC software which does not have the remote id broadcasting functions.

"Fixed" take off position is already implemented. I also want to point out that RemoteID is not a normal add-on like a cam. There are regulatory requirements. In the EU if you commercially produce/sell drones, you need to certify your product at an official notified body. They will test the product and assess if it is compliant to the C-class that you want it to be certified. If you have a privately build drone, it is best to use a certified add-on mentioned in this list: https://www.easa.europa.eu/en/domains/civil-drones-rpas/open-category-civil-drones (bottom of the page)

If you implement your own solution: you are responsible that the RemoteID functionality is compliant and configured in the correct way. There are requirements on having a valid Serial Number with official manufacturer code, requirements on transmit power and omni-directional antenna pattern etc. In the USA you can file you own DoC at the FAA. But at some point in time, I expect that the FAA will ask for an external review/audits too.