RADIO_STATUS message filtering on Solo #470
Conversation
Solo evidently doesn't set msgid on the RADIO_STATUS message to the correct value, causing those messages to be ignored. This handles that message specifically and ignores sysid for the Solo. Also, added a break for HEARTBEAT_FIRST messages in the switch in notifyDroneEvent() to avoid getting 2 connection events when first connecting.
| @@ -172,6 +173,26 @@ public SoloComp getSoloComp() { | |||
| return soloComp; | |||
| } | |||
|
|
|||
| @Override | |||
| public void onMavLinkMessageReceived(MAVLinkMessage message) { | |||
There was a problem hiding this comment.
The message id is correct, it's the system id and component id are set to a fixed value.
and
The change here actually skips to message ID verification to allow the SiK message to be processed. Not sure why that isn't working on Solo. It work for ArduCopter/ArduPlane etc
There was a problem hiding this comment.
Later: You may need to look at this code for why the message is filtered https://github.com/dronekit/dronekit-android/blob/develop/ClientLib/src/main/java/org/droidplanner/services/android/impl/core/drone/autopilot/apm/ArduPilot.java#L394
DroneKit has way to many extends of classes, it gets really confusing at time 😜
There was a problem hiding this comment.
This doesn't fix the filtering for Solo. Solo gets msg_radio_status, not msg_radio. It's filtering the message because it's not included as a Mavlink exception message.
There was a problem hiding this comment.
For this to work with Solo, need to add a separate case for MSG_RADIO_STATUS in ArduPilot (if you're disinclined to have the processing for that message in ArduSolo like I have it now), and implement the filtering exception in ArduSolo.
There was a problem hiding this comment.
I would be expecting RADIO_STATUS should be handled in GenericMavLinkDrone (not ArduPilot) as its a common MAVLink message https://github.com/dronekit/dronekit-android/blob/develop/ClientLib/src/main/java/org/droidplanner/services/android/impl/core/drone/autopilot/generic/GenericMavLinkDrone.java#L601
Either solution would work, but I think when I added the exception method the idea was that is should be used to override extra messages that you need to let through. (You may need to use processRadio... method to normalize the values)
The code for filter messages was adding as part of the plan to allow sys_id other than 1 to work.. That's the next step at least.
| @@ -257,7 +278,11 @@ public void run() { | |||
| @Override | |||
| public void notifyDroneEvent(final DroneInterfaces.DroneEventsType event) { | |||
| switch (event) { | |||
| case HEARTBEAT_FIRST: | |||
| case HEARTBEAT_FIRST: { | |||
There was a problem hiding this comment.
If we don't have a onMessage received overloaded in this object, does the 'double connect message' problem go away?
There was a problem hiding this comment.
Turns out it does. I'll also investigate why I'm getting double disconnect messages as well.
There was a problem hiding this comment.
Actually, the problem goes deeper than that. Whatever changes happened here cause the Solo to not know it's connected. I'm connected, getting radio messages, telemetry, etc, but Drone.isConnected(), returns false without that extra HEARTBEAT_FIRST message processing in there.
There was a problem hiding this comment.
Interesting. So much indirection with the use of extends can make the code hard to follow! It's would almost be better if the GenericMavLinkDrone object received all messages first and then call a potentially derived processOnMavLinkMessageReceived implemented in specializations to help with the synchronization issues we are seeing. (i.e. the checkIfFlying call is obviously not happening on first connection before anything else)
Solo evidently doesn't set msgid on the RADIO_STATUS
message to the correct value, causing those messages
to be ignored. This handles that message specifically
and ignores sysid for the Solo.
Also, added a break for HEARTBEAT_FIRST messages
in the switch in notifyDroneEvent() to avoid getting
2 connection events when first connecting.