- create common uORB::PublicationBase
- uORB::PublicationQueued types are now type aliases
- ORB_PRIO use enum type everywhere to avoid accidental misuse
- PX4Accelerometer/PX4Gyroscope/etc driver libs explicitly advertise on construction, unadvertise on destruction. This is a workaround for any potential issues that might appear when accel/gyro cdev and uORB indexing doesn't align.
* uORB orb_stat() and update(uint64_t *time, void *dst) are now obsolete and have been deleted
* mavlink messages add more advertised checks in streams get_size() check to improve data rate calculation across different scenarios
* Add param for software flow ctl on 3DR radios
* Dont reset telemetry type on radio timeout
* Treat 3DR radio as generic link type
* Rename 3DR to SiK radio
The previous forwarding rules exclude another onboard MAVLink node to
send messages to a specific target.
E.g. a message from a companion computer with sysid 1 (same as
autopilot) with target sysid 190 (for the ground station) was not
forwarded.
With the new rules, anything that is not specifically addressed to the
autopilot's sysid and compid is forwarded.
Open the UART after adding the instance: mavlink_open_uart() might block,
and in that case the parent task waiting for mavlink to be started times
out.
And while waiting for the USB UART device to come up:
- check for _task_should_exit
- check for check_requested_subscriptions()
Side-effects when USB is not plugged in during boot:
- reduces boot duration by 100ms
- fixes duplicate instance name in 'top':
201 mavlink_if0 1 0.000 1328/ 2572 100 (100) w:sig 3
204 mavlink_if0 572 4.221 1632/ 2540 100 (100) w:sig 4
- 'mavlink stop-all' now stops the usb instance as well
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>
Daniel Agar