Feature / Improvements discussion

[junwoo091400]

About

This issue aims to keep track of the discussion on the features / improvements we would like to include in the release after v1.14. Original discussion was held on May 30th during maintainers call.

Feel free to add ideas in the thread below, and let's keep this up to date 🤞

List of potential features for v1.15

• PX4 build via colcon (ROS 2 compatibility & ease of use): ROS2 PX4 Colcon build notes/ideas #21668
• Updating docker containers for ROS2 Humble #21720

[nikhilsnayak]

I would like to suggest a feature where PX4 frame is converted to ROS2 frame and vice versa using some wrapper automatically without needing to use external libraries

[DronecodeBot]

This issue has been mentioned on Discussion Forum for PX4, Pixhawk, QGroundControl, MAVSDK, MAVLink. There might be relevant details there:

https://discuss.px4.io/t/px4-maintainers-call-july-04-2023/32943/1

[Brendan-D-Kearney]

I had just run into an issue where I couldn't get the drone in offboard mode, QGC was giving an error that there was no valid position estimate despite position control mode working correctly. It would be useful if when a mode switch is denied PX4 gives a more detailed analysis on what checks failed in order to deny the mode switch. This will greatly speed up troubleshooting.

[pmaddams]

I think it would be great if PX4 supported encryption with WireGuard (apache/nuttx#9362).

[AlexKlimaj]

I propose we jump to 2.0 instead of 1.15. Break apart the different vehicle types into separate builds, simplify modes, start moving high level control into companion computers.

[WarriorHanamy]

I think it would be great if PX4 supported bidrectional dshot

[avcuenes]

I think it would be great .Changing commander state machine logic to behavior tree logic. It would be more human readable

[avcuenes]

I think Integration of GPS/INS would be better tightly coupled systems .

[julianoes]

@WarriorHanamy there is an open PR...

[julianoes]

@avcuenes have you seen this?
http://docs.px4.io/main/en/config/safety_simulation.html#failsafe-state-machine-simulation

[avcuenes]

Yes I see but this is just about failsafe. For example, arm logic , Mode change logic can be good with behavior tree

[bresch]

I think Integration of GPS/INS would be better tightly coupled systems

@avcuenes This is already something we've been discussing with @dagar for some time. There is however quite some work to do so it's probably a long-term project.

[avcuenes]

@bresch Thanks. And also, we can improve system identification. We can generate and give chirp signal to vehicle like Ardupilot
https://ardupilot.org/copter/docs/systemid-mode-operation.html

[VTOLDavid]

I'm not up to date on the current features of 1.14, but these are the features that I think would be super interesting after flying a few hundred hours VTOL in 1.12 and 1.13:

• Flight mode locking by parameter. I have nightmares of customers opening the flight mode selector in QGC and selecting Acro instead of Loiter.
• Do not slow down on landing if you are far from take-off and in manual mode. If you have a battery emergency and the terrain is lower than take-off, you would lose a lot of time descending at landing speed.
• Being able to program landings at other altitudes in the mission at the correct landing speed without using a rangefinder. At the moment (AFAIK) you will crash if you plan a landing over altitude and run out of battery while descending from altitude to the landing point at landing speed if the planned landing point is far below the take-off point.
• Sensorless terrain following as in Arduplane for airplanes.
• Limitation of the minimum orbit radius by parameter for airplanes. In the current implementation you can limit the roll angle but not the radius. If the roll needed to maintain a small radius is greater than the maximum, the controller will saturate and you will get erratic flight turning the orbit point, even crashing if your aircraft is not able to maintain altitude and maximum roll for a long time.