A custom action waypoint is an action defined in a waypoint that is scripted and processed outside the flight controller, usually in a mission computer process. The ability to process that action in the mission computer should be coded by the user, or instead using the MAVSDK custom_action plugin implementation (a full-scale example can be seen in the integration tests directory). The custom action command associated, for now, is the MAV_CMD_WAYPOINT_USER_1 but will eventually be replaced with an appropriate MAV_CMD to the purpose. The modifications in the navigator module allow to block the navigator for an amount of time defined on param3 of the MAV_CMD_WAYPONT_USER_1 mission item. The navigator expects to receive a progress status of the action being process, which in the case of not received, will result on the mission continuing to the next waypoint, and a COMMAND_CANCEL to be broadcasted to cancel that same command. The mission will continue to the next waypoint as soon as an ACCEPTED ACK gets sent from the component processing the custom action.
- run airspeed scale estimation always, not in dedicated mode
- add option to apply scale automatically, with extra feasibility check
- add airspeed scale for all 3 possible airspeed instances
- clean up parameters
- add check for data stuck (non-changing airspeed data)
Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
Using mixers on the IO side had a remote benefit of being able to
override all control surfaces with a radio remote on a fixed wing.
This ended up not being used that much and since the original design
10 years ago (2011) we have been able to convince ourselves that the
overall system stability is at a level where this marginal benefit,
which is not present on multicopters, is not worth the hazzle.
Co-authored-by: Beat Küng <beat-kueng@gmx.net>
Co-authored-by: Daniel Agar <daniel@agar.ca>
1. The RTPS IDs are now automatically assigned to the topics
2. Only the topics that get defined to be sent or received in the urtps_bridge_topics.yaml (renamed, since now it doesn't contain IDs) receive the IDs
3. Any addition or removal on the urtps_bridge_topics.yaml file might update the topic IDs - this will require that the agent and the client ID list has to be in sync. This will further require a robustification of the way we check the IDs and the message definitions when starting the bridge.
This allows that all messages (not only timesync messages) that get received on the same system that sent them do not get parsed. As the microRTPS agent is built currently, this will only happen right now if someone sets the same UDP port to send and receive data, or by manually changing the agent topics (which were always autogenerated).
TSC21