3D Robotics

3689706926?profile=original90,000 lines of code in one month! From the PX4 blog:

We have upgraded today to NuttX 7.18 on PX4/master. This is a major upgrade from NuttX 6, which we had been using for several years almost unchanged. PX4 did grow exponentially in 2016, adding significant resources to our ability to drive the software development and flight testing. This allowed to take on the monumental task of re-validating the operating system. NuttX has evolved significantly in the last years, offering fixes, new functionality and support for new hardware like the STM32F7.

We always saw the technical strengths of NuttX and its interesting to note that a major company like Sony adopts it for products and talks about it at ARM Tech con. Every Pixhawk is flying the PX4 middleware and NuttX and so it might still be amongst the most widely adopted products running it.

The team has been very active the past month, leading to a record contribution level. Although note that this is a very incomplete way to look at PX4 - you also need to factor in PX4/ecl, PX4/matrix, PX4/DriverFramework, etc, to get the full picture. This one repository is just the "glue" that brings it all together.

Cortex M7 vs. Parrot Bebop 2.

It is interesting to note that the CPU load running flight control on the STM32F7 on a single core is comparable to the CPU load  on a much faster single core of a Parrot Bebop 2:

Below is the load on Bebop (percentage in the list is a single core)

  • Mem: 66516K used, 230236K free, 0K shrd, 15268K buff, 22992K cached
  • CPU: 10.3% usr 21.7% sys 0.0% nic 67.4% idle 0.0% io 0.0% irq 0.5% sirq
  • Load average: 1.53 0.80 0.32 3/113 1221 PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND 1200 1187 root S 36468 12.2 0 26.1 px4 /home/root/ /home/root/px4.config

And here is the load on a Cortex M7 (STM32F7, complete system load)

  • Processes: 21 total, 4 running, 17 sleeping
  • CPU usage: 31.33% tasks, 1.39% sched, 67.28% idle
  • DMA Memory: 5120 total, 1536 used 1536 peak
  • Uptime: 91.005s total, 61.744s idle

The similar number despite of the advantage of the Parrot Bebop 2 in clock speed makes sense: Flight control consists of many short interleaving tasks and sensor driver access for which Linux is not designed specifically, while the NuttX RTOS is. It also sheds a light on why prosumer drone manufacturers like DJI and Yuneec as well as Intel have retained an independent microcontroller for flight control in their models. Qualcomm is offering a smart hybrid approach by running PX4 on the DSP of the Snapdragon SoC, leaving Linux to run computer vision.

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • @Julien, I had a very similar comment on the blog post itself when it was done. Interestingly I went there now and my comment vanished. I find it pretty disrespectful to remove comments that makes no attacks and just contributes on the technical side, even if it's a counterpoint. I hope it was just a problem with their blog system....
  • Developer

    Interesting.

    ArduPilot has recently started to move away from Nuttx/Px4 drivers, citing inefficiency and code bloat, but maybe the latest version of Nuttx addresses that.

    http://discuss.ardupilot.org/t/calling-all-testers-new-ardupilot-se...

    Quote

    Advantages of the new system

    The new device driver system has a number of major advantages over the old one
    * common drivers with our Linux based boards
    * significantly lower overhead (faster drivers) resulting in less CPU usage
    * significantly less memory usage, leaving more room for other options
    * significantly less flash usage, leaving more room for code growth
    * remote access to raw SPI and I2C devices via MAVLink2 (useful for development)
    * much simpler driver structure, making contributions easier (typical drivers are well under half the lines of code of the PX4 equivalent)
    * support for much higher sampling rates for IMUs that support it (ICM-20608 and MPU-9250), leading to better vibration handling

    That said. I like the PX4 high level design and abstractions, if not so much the implementation.

  • Comparing the performances this way really doesn't make sense.

    There are lots of arguments in favor of running the flight stack on a microcontroller or DSP but these numbers are not one of them. These numbers could show for instance that the Linux port of PX4 is inefficient (I am not saying it is), especially if they come from drivers efficiency (more numbers on that would be appreciated).

    As of counting lines of code, well... pure nonsense.

  • comparing apples with bananas.

    what m7 pls?

    there are quite a few out in the wild - running very slow or up to 400mhz.

    more interesting is the resulting jitter on the time axis ...

  • Indeed. Pretty meaningless. On that basis I maybe wrote 5000 lines of code today. Not to disparage the PX4 Dev team, but enough with the Github hype.

  • "90,000 lines of code in one month!"

     I certainly do not wish to minimize the fantastic work of the PX4 dev team, but with all due respect, Chris, your interpretation of that post when it comes  to line of codes is meaningless at best,e.g.: One monster commit just for the diffs.

    Next, 10 Million lines of code in 1 day.  On my Linux upgrade ...

    One monster commit just for the diff · PX4/Firmware@e05a8aa
    PX4 Autopilot Software. Contribute to PX4/Firmware development by creating an account on GitHub.
This reply was deleted.