Daniel and I have been discussing a roadmap with the core dev team over the last week and solicited input from all of our stakeholders in the development community and our core adopters.
What we have come up with is a prioritization of existing shortcomings we would like to address and new features. In contrast to previous years we have not added things on the roadmap that we should be doing - but only things that we know people have committed to contribute.
There will be two main releases in 2019: PX4 v1.9 in March and PX4 v1.10 in September. We had opportunistic release dates in the past, but given the wide adoption of PX4 in the industry today, it is time to go to a regular, reliable release schedule.
PX4 saw in 2018 the mainline adoption of computer vision for obstacle avoidance and vision-based navigation. It is now an area that is as actively developed by professional developers as other parts of the system. It has graduated from being a mostly R&D driven area to something that is now being integrated in products and sees the level of testing and quality assurance required to deploy it in products.
With these new capabilities PX4-powered drones are capable to detect and avoid static obstacles like trees and moving obstacles like other drones and avoid them while continuing on their pre-programmed mission or in the approximate direction the pilot is directing the system in.
Implementing computer vision algorithms that are closely linked with the flight control system requires a communication architecture that is transparent and easy to use - and this is what the native PX4-ROS2 link enables.
2019 is a paradigm shift for PX4: We are moving from a purely microprocessor-focused view to a holistic architecture for heterogeneous systems and make Linux onboard computers first-class citizens. The main mechanism for that is by introducing FastRTPS as a new transport in parallel to MAVLink. This enables native compatibility with ROS2 messaging.
A failure mode analysis of PX4 has been completed in 2018 and the development team is now focusing on hardening the system in the areas that would benefit overall reliability and safety most. While PX4 is performing really well in large-volume products like consumer and commercial drones and has overall great reliability, the goal is to push it up further towards an industrial level of reliability and towards certifiable safety.
PX4 is a pure software project, but has always been linked to hardware, as the Pixhawk reference hardware has been historically designed by the same people that started PX4. That was 2011 with the flight management unit (FMU) v1 - today we are at revision 5, the launch product based on the standard was Pixhawk 4. This brought a new CPU type (Cortex M7) and a lot more resources. This represented a “tick” step. While this is stable and recommended for all new designs, the market and our software ecosystem have evolved: There are new MEMS sensors, more commercial drone companies using the FMU reference designs and new buses like Ethernet. So the next hardware reference design is a “tock”: It doesn’t change underlying technology dramatically, but improves the overall performance, reliability, packaging and product-market fit.
These main features represent firm commitments by individual contributors and companies. Additional features might be added to the release.