Kristian Klausen
Some background:
For some coordinated flights we are doing, we are in need of using RTK GPS as navigation source. By using ardupilot, the obvious method would be to connect it here, and let the filtering and sensor fusion with IMU be done in ardupilot and get the results into EstimatedState using mavlink.
However, for various practical and operational reasons, we would like to investigate skipping ardupilot and using the RTK data directly in Dune for guidance. Since we will still (want to) be getting the other data from ardupilot, we need to differentiate the data going to the path controllers.
A couple of options:
1. Have a state in the ardupilot api, so to fill in RTK positions rather than position from ardupilot when creating EstimatedState
2. Create a new message type, and alter the existing PathController code to accept another message, rather than EstimatedState
3. Dispatch a second EstimatedState filled by RTK positions, and change the guidance-controllers to use the ProxyPathController class to filter EstimatedState messages coming from a certain entity.
1 is not ideal, as data from ardupilot comes more often than RTK. In addition, there is no good mechanisms for reporting loss of fix, and how to report the source of the data (rtk vs gps)
2 is what we're doing for copters now, but here all the controllers have been rewritten. For fixed-wings, we would like to utilize more of the existing code. Creates some issues in code maintainability with upstream.
3 requires the least friction for code maintainability, but I believe it forces filtering of the correct EstimatedState message in several tasks?
Any immediate thoughts? This is more a question about code maintainability than functionality.
Regards,
Kristian
Ricardo Bencatel
Hi Kristian,
When you mention the ArduPilot API, you are referring to the ArduPilot task in DUNE, correct?
There is the intention to brake the ArduPilot task into several tasks with distinct roles, as the interaction with another system through MAVLink and the generation of EstimatedState messages. The development of the feature you need could be part of this effort, introducing some logic in the EstimatedState generation task to select the data from the MAVLink or the RTK channels.
The ProxyPathController class can be used instead of the PathController class in the guidance task(s) you need the filtering. The Control\UAV\LOS task is one example. If you do not set any filtering parameters, a task using the ProxyPathController class will behave exactly the same as if using the PathController class, except for the filter computation penalty.
Cheers,
Ricardo
--
You received this message because you are subscribed to the Google Groups "LSTS Toolchain" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lsts-toolchai...@googlegroups.com.
Visit this group at https://groups.google.com/group/lsts-toolchain.
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/f3ff8da2-8644-46ef-b861-e7650dc6b763%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kristian Klausen
Yes, I'm referring to the ArduPilot task.
We've been talking about that (breaking up the ArduPilot task) for some time, are there any new development efforts being put into this? If so, that would be a good solution :)
Regards,
Kristian
Ricardo Bencatel
Hi,
I think this is waiting for someone with time or a pressing need. But it would be a better solution for your problem than the ProxyPathController approach, as there would be only one source of “EstimatedState” messages, and all the final checks of which state should be used would also be concentrated on that task.
Further, IMO tasks should not mix navigation functions with control or guidance functions.
Cheers,
Ricardo
To view this discussion on the web visit https://groups.google.com/d/msgid/lsts-toolchain/b08f91e1-0b4b-4c86-b2b3-41c2db9b7c0f%40googlegroups.com.