Mavsdk: Allow sending STATUS_TEXT message

[sanderux]

To inform the user from an onboard secondary computer i would like to be able to send STATUS_TEXT messages to the flightcontroller. PX4 is configured to relay these to other devices. I would like to be able to set the SOURCE_SYSTEM to the MAV_SYS_ID of the flight controller so QGC doesnt see the message as a different vehicle.

[julianoes]

So, I would argue that your onboard computer should have the same system ID as the flight controller, however, a different component ID. This way, the message should show up correctly on QGC.

[JonasVautherin]

That's opening an interesting question: should the SDK make a difference between "clients" and "servers/sensors"? Or should we just split those functionalities in different plugins?

For instance, let's say I have a sensor that sends telemetry. Should it have its own component ID in the system and use a TelemetryServer? Is it fine to assume that no two components will send the same MAVLink messages, or should the client be able to choose which component it is interested in with this particular instance or the Telemetry plugin?

In other words, should this STATUS_TEXT go in a TelemetryServer kind of plugin?

[sanderux]

So, I would argue that your onboard computer should have the same system ID as the flight controller, however, a different component ID. This way, the message should show up correctly on QGC.

That is indeed how it should be, but i doubt it is.
As for the system_id, i'm not sure PX4 will handle correctly communicating with the same systemID if, for instance, you request a mission list.

But having a ONBOARD and CLIENT mode is probably a good idea.

[julianoes]

That is indeed how it should be, but i doubt it is.

That's what we should work towards rather than workarounds for the SDK for this.
If we can't use MAVLink sysid and compid as designed, everything falls apart. If PX4 handles something incorrectly, then we fix it.

[julianoes]

Should it have its own component ID in the system and use a TelemetryServer?

A sensor belonging to "the system" has the same system ID and a different component ID.
A ground station (or SDK thing) should not have to worry if a telemetry message originates from a Pixhawk with internal sensor or an additional thing with another component ID. By looking at the MAVLink message you could distinguish it but I doubt we usually need to know.

Or maybe I misunderstood what you meant?

[sanderux]

scenario 1:
Flightcontroller (FC): SYSID: 1, COMPID: 1
Secundary Board Computer (SBC): SYSID: 1, COMPID: 2
A. SBC requests mission list: PX4 does not handle a request from the same SYSID correctly
B. SBC sends STATUS_TEXT message: PX4 relays properly, even if from same SYSID

scenario 2:
Flightcontroller (FC): SYSID: 1, COMPID: 1
Secundary Board Computer (SBC): SYSID: 230, COMPID: 2
A. SBC requests mission list: PX4 handles it properly
B. SBC sends STATUS_TEXT message: PX4 relays properly, QGC thinks there is a different vehicle

Our current code in Dronekit:

# settings
mavlinkID = 230
fcID = float_to_int(vehicle.parameters['MAV_SYS_ID'])

def sendMsg(txt=''):
    global mavlinkID, fcID
    vehicle._master.mav.srcSystem = fcID
    msg = vehicle.message_factory.statustext_encode(10,"DSPS: %s" % txt)
    vehicle.send_mavlink(msg)
    vehicle._master.mav.srcSystem = mavlinkID
    print "DSPS info: %s" % txt

[sanderux]

I believe things should work as intended and we should work towards fixing everything that doesnt work. But i also think an SDK should give the freedom to whatever you like, such as defining exactly what SYSID/COMPID you want to use for a specific case.

[julianoes]

A. SBC requests mission list: PX4 does not handle a request from the same SYSID correctly

Let's fix this.

[julianoes]

Let me add some context. The problem is that the SDK has a concept of system, and it will have the same problem as QGC for a message which is from another system. This means that the message won't even end up in the plugins and can't be consumed. If we change that, everything around multiple vehicles falls apart.

[JonasVautherin]

Thanks for the reports above! Are they known issues for QGC and PX4, or should we open new ones?

But i also think an SDK should give the freedom to whatever you like, such as defining exactly what SYSID/COMPID you want to use for a specific case.

That's probably a philosophical question, and at least a design choice. If I design a library for manipulating JSON documents, it will probably be limited to parsing and writing _valid_ JSON documents. One may want a way to generate invalid documents with my library, so that they can read them with a buggy parser. But I would consider it a perfectly valid choice to say that my library only supports valid documents.

Same applies here: I wouldn't want to add a way to e.g. insert typos into MAVLink messages because QGC has a bug an reads "amtitude" instead of "altitude".

We need to think carefully about the implications of adding complexity into our API, and in this case it may be much better to actually fix the bugs than to support them :-).

EDIT: I hadn't refreshed and missed @julianoes answers above :sweat_smile:.

[sanderux]

The problem is that the SDK has a concept of system, and it will have the same problem as QGC for a message which is from another system. This means that the message won't even end up in the plugins and can't be consumed.

Could it not look at the component id, i think all systems are fine with a different component id.

I am not sure what the current status is of the systemid bug in px4, i will check

[sanderux]

There is also the concept of the targetID, if set to 0 it should always be forwarded by routers and consumed by clients.

[sanderux]

@JonasVautherin i think a better analogy is a TCPIP wrapper, and if you would allow changing the header of the packet. There is nothing wrong with the format, and if it is your intention to have any reply be sent to a different ID then why would that not be allowed. If it is needed programmers will find a way anyway and start hacking stuff. If you make it clear that it is normally not the way it should work i see no reason to limit then from doing so

[JonasVautherin]

Good points there, indeed.

Again, I'm not saying that it is bad to add those features. I'm saying that it may require some work, and it may have an impact on the design. So if the need right now is a workaround, I'd rather fix the bugs.

[sanderux]

Unfortunately we need it backwards compatible

[julianoes]

There is also the concept of the targetID, if set to 0 it should always be forwarded by routers and consumed by clients.

Correct.

Unfortunately we need it backwards compatible

Let's try to do a very specific hack for this case then. Something like:

if (sysid ==  230 && COMPID == 2) {
    // HACK
    do_something();
}

Now, where exactly is the SDK in your setup? That's to figure out what do_something() needs to do. Or what's your "networking" setup?

[sanderux]

SDK runs on Secondary Board Computer (SBC).

SBC -serial- Pixhawk -serial/radio- GCS
SBC -4G- GCS
SBC -WIFI- GCS

As you see we have 3 methods of communicating to the GCS

[sanderux]

Wiring diagrams are listed here: https://www.verticaltechnologies.com/info/tech-specs-wiring-and-electronics

[julianoes]

Ok, and Pixhawk is forwarding everything using the -f flag?

I don't understand which messages exactly need to get changed. And what's used to forward traffic on SBC?

[hamishwillee]

Without reading the story here, I assume discussion must also apply to new STATUSTEXT_LONG.