Add endpoint grouping #60
Conversation
…ompsys id insertion with mutex.
… group operations.
There was a problem hiding this comment.
Why not use the implementation from upstream right away? mavlink-router@354a5f5
It's considerably simpler.
| @@ -47,6 +47,10 @@ | |||
|
|
|||
| #define UART_BAUD_RETRY_SEC 5 | |||
|
|
|||
| // Static vars protected by a mutex, shared across all instances of Endpoint | |||
| std::mutex Endpoint::_group_sys_comp_ids_mutex; | |||
There was a problem hiding this comment.
No locking needed, mavlink-router is single-threadded
|
re-visiting this this is last 'unmerged' package for the skynode-s. in an effort to clean up and stabilize the relaeses, i would really want to see this guy merged :D |
|
I briefly looked into using the upstream method though found it faster to implement this than to refactor the Endpoint class to look more like upstream's. I'm of the opinion that if we're going to put any more effort into modifications to mavlink-router that we should just abandon this and add the watchdog kicker and named-pipe endpoint generation that the payload-manager uses to the upstream version of mavlink-router. I got
This is roughly what @DanielePettenuzzo and I discussed previously. |
|
thanks! |
Yes the structure is a bit different, and maybe I'm missing something but I still think the upstream implementation could easily be adopted and it's considerably simpler. You can prove me wrong though.
At this point I'm not in the loop anymore about specific differences. |
|
@FrauBluher yes the diff you posted is pretty accurate. Those things can be resolved but will require a little bit of time from Matej or Andrew. We could potentially merge this and then plan to get rid or the dynamic endpoints or upstream them so that we can just move directly to the upstream version and not maintain our fork anymore. |
Yes if I have your word on that. And my comment still needs to be addressed: https://github.com/Auterion/mavlink-router/pull/60/files#r1662352785. |
This endpoint grouping is designed for systems where a software component will send to and receive from mavlink router on two different endpoints. This is what we need for the auterion wfb setup with the wifi radios. We need to specify all ports we send to and receive from AMC. By giving both tx and rx endpoints the same group, mavlink router will just wait to receive the system/component ids on one of the two endpoints and then assign the ids to the entire group since one endpoint will just send out data and will never receive a system and component id.
This PR will then modify also the config generator script: https://github.com/Auterion/recipe-mavlink-router/pull/10 We still need to clean up this PR.
There might be something similar upstream but I would prefer to get this in and then finally plan the mavlink router upstream merge that we have been postponing from 3 years now.
FYI @FrauBluher @alexVinarskis