Next-gen APM, Pixhawk 2 or time to go embedded?

Archive
1

The 3DR Solo looks fantastic from a technical point of view, but under the covers it appears the days of minimal CPU based autopilots are over. The message I see here is we need something like an embedded PC on both the on-board autopilot and require (not just optional) a ground controller of similar or higher spec.

Does anyone know already if the “Pixhawk 2” in the new “Linux based” 3DR Solo drone is:

  1. Going to be available separately.
  2. An open hardware specification so we might find cheaper clones.

I think we are at a junction point, because 3DR appear to be chasing the DJI business model. A lot more money is now being made with premium full featured drones going mainstream thanks to the futuristic DJI Inspire 1 design and successful mass-marketing. It’s just like when Apple took over the phone market, nobody really knew or wanted smart phones before then.

Unfortunately most companies who make this switch-up in gear tend to get greedy and block the non-commercial product lines. I hope it doesn’t mean they stop supporting open hardware, because then I’d prefer to see APM support continuing more along the standard OS route.

Looking at my setup, I don’t really need most of the hardware on the Pixhawk because all devices communicate of some sort over simple serial UART or I2C connection. With that in mind a standard embedded PC like Raspberry Pi 2 could run the whole system and connect to all devices with just a few bits of interface cabling/electronics.

So maybe we’re better off focusing on Linux support in APM, and hopefully somebody comes out with a standard mini-UART/S-Bus/I2C adapter to make it easy for the mainstream. That’s all we really need, the ability to turn any standard mini/embedded PC board into a flight controller (or full “computer” as they now call it).

It’s so compelling I think it’s worth the effort to have a go at it myself. The possibilities with a full PC OS are endless. We could also do live Full HD video compression (with hardware support on some boards) and downlink it over a standard USB wifi adapter, eliminating the RC and FPV radio. This is just what DJI and 3DR have done, but they charge a premium price for their “special” Full HD FPV technology (really just a standard WLAN link).

Anyone have more information/thoughts/limitations on this?

2

I see following the APM Linux (BeagleBone) documentation that the Erle-Brain is exactly a hardware adapter/add-on I was thinking about, but sadly at a higher cost than a whole separate Pixhawk so it’s just not worth it.

What I’m looking for is a board with the minimum interfaces, say standardize on one or two I2C connectors (because it’s a bus) for high speed ESC and sensor/add-on communication (gyro/compass, airspeed, barometer, gimbal, sonar, etc…), SBUS for servos (can also be chained and supports more channels), and 3-5 UARTs for the serial stuff (GPS, OSD), everything else over USB (e.g. radio).

Some of the smaller devices like gyro/compass and barometer could be integrated chips on the adapter board, but not if it brings the whole complexity and price of the solution back to that of another autopilot. Ideally the thing should remain as simple as an adapter so you could even choose to solder together your own with a breadboard, a few electronics parts and connectors.

Many of the parts which require other interfaces could be optimized into a this more powerful PC solution, e.g. when sending digital-WiFi video the OSD is no longer required as such image manipulation would occur in software (actually virtually no effort when a standard video teletext format is used, e.g. MKV file format with parallel data stream = no actual image processing, just the container/streaming protocol).

3

Reading on and checking the source shows the APM BeagleBone seems to have a hit a closing dead-end with the non-RTOS Linux build in 2014. So I was looking at other RTOS and people have the most popular (according to Wikipedia) RTOS Android already running on the Raspi 2, but slowly (at least as a desktop PC/tablet so maybe still quick enough in headless mode).

Then I found the NAVIO+ from EMLID, which is another APM “cape” solution but for Raspberry PI, claims APM compatibility and from a design is much more optimized (compact with more integrated chips). It could be cheaper and could ditch even more of the connectors, but looks the best so far besides price. emlid.com/

But back on the main goal, just an “adapter” for any PC… I found more information about the two I2C buses already available on the Raspberry PI and also that there are I2C to UART converter chips available (if at all necessary) and just about everything (all the other chips for gyro and other sensors) are already I2C capable/sold in I2C variants. So I think the next step is to investigate a pure I2C solution.

4

I2C is not the best communication interface. And if you have many devices on one bus, it’s even more problematic.

If you just want just a flying sensor array, use a Pixhawk. The PX4 developers are basing their first Linux port of the PX4 Flight Stack on that model.

Both RPi and BBB solutions use the PREEMPT kernel for realtime behaviour.

USB is not the best inflight connector. If disconnects happen USB drivers can hang. Simple serial interfaces can be much more reliable. Or SPI for much higher transfer speeds

5

Thanks for the reply. Many other people claim I2C is not reliable or make some other blanket statement, so it seems to be the underdog. However occasionally in these discussions some electronics genius will jump in and set the record straight, and I what they say makes sense.

From what I understood, I2C is so simple and not problematic unless you have another issue somewhere else. It’s almost universally supported and is fast enough for any MAVLink, servo or ESC data requirements even super-fast modes (Afro ESCs are supposed to support native 1KHz update via I2C).

For me SPI falls into the “nice to have” category, more sense on PCB boards and only required when you need a special solution with a lot of speed/full-duplex (perhaps LIDAR 3D point cloud co-processing or something like that). But at the cost of more complex programming and an extra wire from the controller to EVERY device. For the usual Pixhawk connectivity requirements it’s over the top then.

If this is wrong I’ll certainly find out in the early stages and all devices I buy for the adapter will most likely also support SPI so not much will be lost. No need to go into I2C vs SPI here then, there are enough discussions about that on the internet and I am not claiming to be an expert so anyone else please do your own research. If I get this thing working others will make variants with their own preferences for sure.

There are two stages of development I’m thinking of. The first is to use the NAVIO+ shield on a RasPi2 and get experience of the APM development, help-out there. But then I want to simplify the hardware to some brew solution anyone with basic soldering and PCB breadboard experience could hack together in an afternoon. Still all running the APM framework of course.

I expect everything should fit nicely into the existing product via the HAL concept, a lot of good design has clearly been done already. So the conversion should be similar to the existing NAVIO+ example. The rest is already been worked on above the HAL. I noticed, for example, someone is trying to split the ESC support so we can use “better than PWM” connections like I2C, CAN and OneShot125 generically without hard-coded manufacturer specific firmware. I’m looking forward to testing my Afro ESCs at native speed to see what all the hype is about faster controller updates.

The initial OneShot125 request was denied on the DIYDRONES/Git project because people claimed it was not feasible (perhaps fear it was not possible) with the Pixhawk update speed. If that is indeed the issue, the Pixhawk itself, then the RasPi or 3DR Solo “Pixhawk 2” should solve that just by being more powerful.

USB connection was just an idea as a potential workaround to use a full Pixhawk like a slave, before I found the NAVIO+ cape. Somebody should put links to those two boards I found on the APM Wiki/documentation web site. I really look forward to the “Pixhawk 2” announcement and hopefully confirmation from 3DR that the hardware platform (not just the firmware) remains open source.