Without lockstep the actual monotonic clock of the host computer is
used. Therefore, this time is likely much more than 20 seconds and the
check if the boot complete happened in time will fail immediately.
Therefore, it probably makes more sense to count the time from the first
mavlink creation.
-moved rc.mavlink to the boards optional rc additions (now it's called rc.board_mavlink) to handle board specific mavlink needs (mavlink over usb, ethernet, additional streams, etc.)
-mavlink module will be responsible to usb defaults, therefore less args are needed to be passed to mavlink module if one wants to use mavlink over usb.
-the way to check if connection is usb is by it's designated variable and not by config mode.
This fixes the regression where we saw this in SITL:
ERROR [mavlink] system boot did not complete in 20 seconds
The reason was that the stream subscription requests were not checked
because the while loop was not running yet because mavlink was not
booted completely.
By moving the stream subscription requests into a function we can run
them even if we don't run the rest of the loop.
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>
Break out Mavlink class constructor logic into set_instance() and set_channel() methods. and add const specifiers and default arguments to Mavlink::mavlink_open_uart().
Since commander handles all telemetry_status the same there is no need to subscribe to multiple instances.
Signed-off-by: Claudio Micheli <claudio@auterion.com>
This removes the confusing ugly magic number of 233 introduced as part
of https://github.com/PX4/Firmware/pull/7670.
Also, the convoluted if is cleaned up using 3 separate bools with some
comments to explain what's going on.
This should not change anything function-wise except that the flight
controller could now potentially also use system ID 233 and not break
forwarding.
Fixes these invalid format strings:
- A `%d` for a pointer (replaced it by `%p`)
- A 0x%08x (and a 0x%0x8!) for a pointer (replaced by %p)
- 2 cases of `%d` for a `ssize_t` (replaced it by `%zi`)
- 1 case of a %u for an `int` (replaced by %i)
- 3 cases of %d for a `long` (replaced by %ld)
- 19 cases of `%d`, `%i`, `%u` or `%lu` for a `size_t` (replaced it by `%zu`)
- An unused formatting argument (removed it)
- A missing `%d` (added it)
- A missing `%s` (added it)
- 2 cases of `%llu` for a `uint64_t` (replaced it by `"%" PRIu64`)
- 6 cases of giving a string directly as format string (replaced it by `("%s", string)`)
- 2 cases of %*-s, which should probably have been %-*s.
(Looks like NuttX accepts (the invalid) %*-s, but other platforms don't.)
- A %04x for a `uint32_t` (replaced by "%04" PRIx32)
Julian Oes