- Community Announcement
- Community Q&A
- Project Updates
- General Discussions
- Weekly Overview
- High priority queue
- Specify what you are trying to achieve
- Specify what environment / platform you are using
- Prepare a Link or Document to help understand if possible
- First, ask the question on the Slack or create a Github Issue!
- If you take over 5 minutes for the question, please continue in Slack or a Github Issue.
Patrick had a quadrotor tiltrotor working with some customizations for it to run as a VTOL tiltrotor and take advantage of the existing tilt rotor logic. The last experimental state is on a GitHub branch here: Commits · PX4/PX4-Autopilot · GitHub We can help with build issues offline of the call.
He’s interested because it’s supported by MAVSDK and the tests with the 1.13 release should not run through follow me yet because it was merged soon after. Users who plan to test the new follow me use px4 main. Discussion about version sync between PX4 and MAVSDK. It would be good to query the capability instead of relying on a version tag because e.g. it’s currently not available on flash-constrained targets. The PX4 parameter of the new follow me could be used to detect it.
If the entire interface would be very strictly defined in MAVLink it could be done with a capability flag but that discussion applies to other functionality like should there be standardized parameters or getters for all strictly defined properties that are set through MAVLink? e.g.
There’s an open discussion for this here: common: Set mission yaw mode command by hamishwillee · Pull Request #1297 · mavlink/mavlink · GitHub
During the development of fixed-wing landing with nudging he came across the RC override option that just switches mode upon stick movement (not enabled for fixed-wing by default):
We need to make sure that RC override never kicks in while sticks are in use by the mode because e.g. nudging is available. The mode should in any case be able to decide if override is allowed. Discussion about the user experience with RC override vs enable nudging in all situations and making sure the UX is good in all situations you want to push the drone and evolve away from stick-triggered mode switches.
During development of fixed-wing takeoff improvements he came across the takeoff command requiring an explicit takeoff position. Wouldn’t it be useful to specify the possibility to just command a takeoff with a certain altitude and the vehicle would decide for the loiter position that best suits the vehicle position, orientation, … before takeoff and when it reaches the altitude.
It would be good to discuss this on the MAVLink call because it’s for multicopter and fixed-wing the easiest possible takeoff is starting from the current location reach a certain altitude and stay/loiter there. For the case of a mission the takeoff could be done automatically if not specifically planned.
Discussion about if a takeoff waypoint as such is necessary/useful. E.g. for multirotor the basic takeoff altitude would be enough. For VTOL maybe the steps should be more explicit multicopter takeoff to a certain altitude, transition into a certain direction? For fixed wing there might be the option to plan a runway takeoff but if the vehicle is hand launch that could be left away and it would just continue the direction it was thrown.
The main issue is that the UART pins usually used for serial debug consoles are attached to the ADSB so the console is disabled by default. The MAVLink shell doesn’t work properly when no NuttX level serial console is availble.
Please raise any concerns in:
Discussion based on: High-Priority Queue · GitHub