Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mavlink: Fix forwarding of messages with target system/component id #12559

Merged
merged 2 commits into from
Aug 13, 2019

Conversation

maowen
Copy link
Contributor

@maowen maowen commented Jul 25, 2019

Mavlink does not correctly forward messages that have the target_system or target_component routing fields in the message.

Some investigation revealed that the Mavlink::forward_message function is incorrectly utilizing the mavlink_msg_entry_t.target_system_ofs and mavlink_msg_entry_t.target_component_ofs fields. These offsets are intended to be used relative to the start of the message payload. But, as implemented, these offsets are incorrectly being used relative to the start of the message. This pull-request corrects that problem.

I also correctly made use of the mavlink_msg_entry_t.flags field to determine if a message contains a target_system or target component field. The previous check incorrectly assumed that they would always be non-zero if present.

See here: https://mavlink.io/en/guide/routing.html#c-library-mavgen

Quote:

The MAVLink v2 generator for the C library has been updated to make it easier to get the destination system and component ID from the payload (when these are assigned). Specifically, the mavlink_msg_entry_t structure contains flags to tell you if the message contains target system/component information (FLAG_HAVE_TARGET_SYSTEM, FLAG_HAVE_TARGET_COMPONENT) and offsets into the payload that you can use to get these ids (target_system_ofs and target_system_ofs, respectively). The MAVLink helper method const mavlink_msg_entry_t* mavlink_get_msg_entry(uint32_t msgid) can be used to get this structure from the message id.

Test Configuration

All testing was performed on px4_fmu-v5 hardware. The following system setup was used:

Host PC (Custom Mavlink Utility) <--> PX4 TELEM1 (Mode: Normal, Forwarding: Y)
PX4 TELEM2 (Mode: Onboard, Fowarding: Y) <--> Companion Computer App (Custom Mavlink Utility)

Mavlink status

instance #1:
GCS heartbeat: 321687 us ago
mavlink chan: #1
type: 3DR RADIO
rssi: 200
remote rssi: 172
txbuf: 99
noise: 37
remote noise: 74
rx errors: 0
fixed: 0
flow control: ON
rates:
tx: 1.109 kB/s
txerr: 0.000 kB/s
tx rate mult: 0.399
tx rate max: 1200 B/s
rx: 0.062 kB/s
FTP enabled: YES, TX enabled: YES
mode: Normal
MAVLink version: 2
transport protocol: serial (/dev/ttyS1 @57600)
ping statistics:
last: 297.25 ms
mean: 242.86 ms
max: 345.41 ms
min: 86.83 ms
dropped packets: 0

instance #2:
GCS heartbeat: 378442 us ago
mavlink chan: #2
type: GENERIC LINK OR RADIO
flow control: ON
rates:
tx: 20.233 kB/s
txerr: 0.000 kB/s
tx rate mult: 1.000
tx rate max: 921600 B/s
rx: 0.286 kB/s
FTP enabled: YES, TX enabled: YES
mode: Onboard
MAVLink version: 2
transport protocol: serial (/dev/ttyS2 @921600)

Signed-off-by: Mark Owen <maowen801@gmail.com>
@maowen maowen force-pushed the mavlink_msg_forward_offset_fix branch from effddbe to 62bfd6c Compare July 25, 2019 21:25
Copy link
Contributor

@julianoes julianoes left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the change and describing it thoroughly!

@maowen
Copy link
Contributor Author

maowen commented Aug 13, 2019

@julianoes What needs to happen to get this merged?

Should I rebase by branch and do a force push to update the pull request? Or is it good enough to use the github "Update branch" button.

@julianoes
Copy link
Contributor

@maowen thanks for following up! I had not merged it immediately so others have a chance to review as well. Since no one had objections I can merge that now (and should have a while ago).

@julianoes julianoes merged commit e25db01 into PX4:master Aug 13, 2019
bozkurthan pushed a commit to bozkurthan/Firmware that referenced this pull request Sep 4, 2019
…X4#12559)

Mavlink does not correctly forward messages that have the target_system or target_component routing fields in the message.

Some investigation revealed that the Mavlink::forward_message function is incorrectly utilizing the mavlink_msg_entry_t.target_system_ofs and mavlink_msg_entry_t.target_component_ofs fields. These offsets are intended to be used relative to the start of the message payload. But, as implemented, these offsets are incorrectly being used relative to the start of the message. This pull-request corrects that problem.

I also correctly made use of the mavlink_msg_entry_t.flags field to determine if a message contains a target_system or target component field. The previous check incorrectly assumed that they would always be non-zero if present.

Signed-off-by: Mark Owen <maowen801@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants