Accept onboard computer heartbeats as telemetry #10194
Conversation
|
This looks reasonable and can be extended for an OBC datalink failsafe after. Can you please rebase? |
okalachev
force-pushed
the
obc_heartbeats
branch
from
249040c to
d0c29f1
Compare
okalachev
changed the title
|
@TSC21 , thanks, I'll look. |
okalachev
changed the title
| if (msg->sysid != mavlink_system.sysid && hb.type == MAV_TYPE_GCS) { | ||
|
|
||
| /* accept only heartbeats from GCS or Onboard computers */ | ||
| if (hb.type == MAV_TYPE_GCS || hb.type == MAV_TYPE_ONBOARD_CONTROLLER) { |
There was a problem hiding this comment.
Is there any reason we can't drop this check entirely now?
There was a problem hiding this comment.
What if there is a heartbeat from another drone (in a swarm network), charging station, or any other device? Should it be considered as a telemetry link?
I don't think so.
| @@ -56,7 +56,7 @@ static constexpr const char reason_no_offboard[] = "no offboard"; | |||
| static constexpr const char reason_no_rc_and_no_offboard[] = "no RC and no offboard"; | |||
| static constexpr const char reason_no_local_position[] = "no local position"; | |||
| static constexpr const char reason_no_global_position[] = "no global position"; | |||
| static constexpr const char reason_no_datalink[] = "no datalink"; | |||
| static constexpr const char reason_no_datalink[] = "no GCS datalink"; | |||
There was a problem hiding this comment.
How about ground control instead of GCS?
There was a problem hiding this comment.
I don't see a huge difference, but I can change it.
|
A few minor comments, but overall looks good. |
|
@TSC21 , I found the bug. The problem starts, when multiple telemetry "sources" are on the same Mavlink instance, so this is the same So, I don's see an easy solution yet, looks like a lot of telemetry logic should be changed. |
|
@okalachev that probably means we need a different |
|
I guess the maximum number of topic instances are So, maybe not to use multitopic for that. Instead, to add system and component ids to |
Well I was thinking on limit the telemetry sources based on type and not on sys+comp id. But I guess that would make more sense yes. Can you propose that in a new issue as a RFC? Probably better to have a discussion about it first before one commits to it. |
|
You mean to write an RFC for adding sys and comp ids to I'm not sure this is so large change to make an RFC. |
It's a conceptual/structural change/feature that needs to be discussed. |
|
Could you please rebase? Thanks! |
|
Unfortunately, it doesn't make sense for now, because this change introduces a new bug, that I described in previous messages. I don't see an easy solution yet, without rewriting |
|
@okalachev what's the status of this? Have you thought of a way of bringing this into a state that does work? |
|
The PR is not totally incorrect. It's rather incomplete. But I accept that we can bring a more complete solution in a new PR. Please fill free to close it or maybe we can iterate from here. |
|
Revisiting this idea - #10933 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Closing as stale. |
This PR solves #10042 problem, that
STATUSTEXTmessages are not passed, when there is no GCS.Also, this is a partial implementation of #7985.
I pass
telemetry_status, when OBC heartbeats received, but I changed the commander logic, for not considering OBC as a datalink.So
NAV_DLL_ACT,COM_DL_LOSS_T,COM_DL_REG_Tare only about GCS link, not OBC (not renaming for backwards compatibility).The OBC failsafe params, like
NAV_OBC_DLL_ACT,COM_OBC_DL_LOSS_T,COM_OBC_DL_REG_Tcan be added later.@LorenzMeier , @TSC21 .