Don't override MAVLink behavior in SITL .rc file #12672
Conversation
| @@ -232,15 +232,6 @@ sh etc/init.d/rc.vehicle_setup | |||
|
|
|||
| # GCS link | |||
| mavlink start -x -u $udp_gcs_port_local -r 4000000 | |||
| mavlink stream -r 50 -s POSITION_TARGET_LOCAL_NED -u $udp_gcs_port_local | |||
| mavlink stream -r 50 -s LOCAL_POSITION_NED -u $udp_gcs_port_local | |||
| mavlink stream -r 50 -s GLOBAL_POSITION_INT -u $udp_gcs_port_local | |||
There was a problem hiding this comment.
Does the position and attitude still look smooth in QGC?
There was a problem hiding this comment.
It should, otherwise we should probably adapt the defaults, right?
There was a problem hiding this comment.
Exactly. The default for the position is 5 Hz, which is probably too low. I think that was the original reason to add them here.
There was a problem hiding this comment.
Can we raise it in the mavlink config or would that exceed bandwidth on 57600?
There was a problem hiding this comment.
We need to check. Why not keep attitude and position here?
There was a problem hiding this comment.
I think it makes sense to have consistency between SITL and real vehicles as much as possible. And that way we force users like MAVROS, MAVSDK, or QGC to use the commands to request whatever rate they need.
|
@dagar I would suggest to get this in. |
|
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
|
Thanks for originally proposing this! I'm closing this PR as stale - if you still would like to add this, a new, rebased PR would be most welcome! Our apologies for not being more on top of it earlier. Closing stale PRs helps us to make sure that overall we can drive PRs to completion. |
Describe problem solved by the proposed pull request
While testing SITL I discovered that MAVLink is sending some messages at unexpected rates (#12613). The console output indicates a stream with the "normal" profile on port 14570
However subsequent
mavlink streamcommands override the normal mode for some messages and turn rates up to 50 messages per second.Test data / coverage
I tested the changed SITL setup with Gazebo/QGroundControl and a basic mission. I verified that the normal MAVLink profile is now used by checking QGroundControl's MAVLink Inspector.
Describe your preferred solution
Delete the commands that re-configure MAVLink.
Describe possible alternatives
Mavlink::configure_streamfrom debug to info level