At first I thought this was great, and superlight replacement for the RPi 2 in Navio applications. BUT. Chip is the single core processor (5-7 times slower than RPi 2), and has HALF the ram at 512Mb, so if you are running anything besides ArduCopter/ArduPlane ect… like image recognition software, VPN, or your own Python scripts that it could affect the performance of the autopilot!
Wouldn’t want computing lag to knock my 6lb machine out of the sky. But that being said, if you’re platform is super tiny (suggest less that .55lbs :D) you might want to try and integrate this little guy instead since it only weighs 9g!
Yes that’s true at first look. Maybe it is only something special for smaller drones which don’t need much more than APM running…
But I’m thinking about other combinations for bigger drones. For example effectively using Navio like a “smart Pixhawk node” in an onboard distributed computer system. In simple words a Navio+PiZero together with either multiple other PiZeros and/or full Pi2s.
The PiZero is so small, still with the GPIO/SPI/I2C capability, that it can be used everywhere a tiny tinkerboard like the Teensy would have been used, but runs a full Linux OS, and is much cheaper! That is fantastic, some really smart sensors and failover logic could be implemented.
Maybe it’s not worthwhile in the end besides mini-quads. But I certainly have on the horizon some attempt at a distributed computing platform, like ROS, running with fully autonomous and redundant distributed components. Something like I guess they have in large passenger airlines already. thinking about delivery drones, and things which are not allowed to fall out the sky and cause damage over public places/people
My first project will be to work out which directions are possible for mounting, to get the smallest possible flight controller. Probably a short ribbon cable or directly soldered connections. Which is best depends, which is why I am sure a 3D printed case will be necessary. For example we could tilt the board up and over to consume the same space which is lost because we have PWM headers and the GPS connector sticking up. Then the Navio is no bigger than it’s own original size
This is very interesting. I’ve been playing around with the idea of splitting out tasks to isolate arducopter to insure nothing interferes with its operation. I really need the processing power for my auxiliary functions. The needs of ArduCopter are much less, but its operation is critical.
I use screens to isolate stuff, and insure nothing interferes with anything else, but the worry of a lock up is still there with multiple things running on one piece of hardware.
My plan is to strip the extra bits off a pi2, and use this for auxiliary functions. I was going to use a raspi A, but this looks like a much better approach.
Mine still didn’t arrive. I think the only people who really got one were those who were subscribed to or luck to pick-up the RasPi Magazine. In reality it is not a 5 dollar computer, for example in Germany they want three times the price (still not a lot though) including tax.
As soon as mine arrives I will work-out the orientation/mounting possibilities and upgrade my 250 racer quad. In fact I was hoping this minimization would enable an even smaller example to be built.
I have 2x Pi Zeros. Now just waiting on my Navio2 to arrive. I’ll be looking at using multiple Pi Zeros linked together. Possibly the first zero is running the flight controller software and the other zeros are doing other processing.
There is a lot of hype about Raspberry Pi Zero recently, but we do not share it fully.
Raspberry Pi Zero is not powerful enough to run APM:Copter at 400Hz reliably. It is just the same as it was with overclocked A+/B+ . You can run Rover or Plane, but you will have almost “Zero” processing power left for any other task, even establishing an SSH connection might be an issue.
Can you elaborate your thought about pizero beeing not powerfull enough to drive navio2 & apmcopter ?
IIRC pixhawk processor is a STM32 168 MHz Cortex M4F CPU (256 KB RAM, 2 MB Flash)
erle brain 2 is a BeagleBoneBlack and is supposed to run both APM and ros ?
and what firmware is inside navio2 ? is it open source ? customisable ?
While waiting for my navio2 to arrive, I loaded a debian jessie lite firmware onto my pi zero and then hooked up a HMC5843 3 axis compass to test if I could hook up a i2c device and read it using NodeJS. Loaded node and pi is reading compass data fine.
Not exactly related to the navio2 hardware I know, but I’d never done any nodejs i2c work before
I’d still like to get the realtime kernel loaded onto my pi zero The link from the docs section on this site does not seem to work on a zero
Whilst we are waiting, yes NodeJS is a very interesting topic because it’s designed to abstract the host/environment and now has hardware abstraction both on Linux and Windows IoT (Microsoft appear to be very committed to that).
The PXFMini is an interesting form factor and price but you have to remember it has no GPS which brings us to the >100 dollar mark again, but without dual IMUs and extra external hardware. Let’s see what a Navio looks like without the bulky pin headers and stand-offs…
We can also do a similar job for the full Pi2. I was thinking about a ribbon-cable attach around a different 3D printed case to provide some heat shielding between the hot Pi chips and the Navio barometer/temperature sensor for example. If the main board is wired-up on top rather than below, maybe that is better for the barometer.
Specifically a “sandwich” case with some heat/RF shielding between too. Like a “double-decker” 3D printed case with copper flash or plate in the middle. The Pi Zero could even be dropped-down close to the board, hopefully thin enough so the GPS connector is still accessible from above. On a full Pi2 of course the GPS connector would be an issue so it would either not be feasible or require some kind of quick release or extension for maintenance.
If I’m reading this right, the idea is a case with heat sinks build in so you can arrange the navio, pi(s), other pcb’s together in close proximity. Am I on the same page? I really like this idea and the possibilities it would provide.
I wish one could purchase pi’s and navio’s without connectors / ports, just bare. Then one could add only the connectors that are needed and eliminate weak points by directly soldering things together, moving ports to more vibe friendly places on the aircraft, etc.
It would require significantly more work. But for real integration that can handle lots of duty cycles, these kind of modifications are a must.
With a case like what you are describing and bare pcbs you could really make a computing platform that would be highly optimized for flight and it’s unique operational characteristics.
Yes exactly. A combination between RF shielding layers which double as heat sinks plus a soft heat conducting layer for internal dampening (thermal adhesive layers - I buy sheets of them for my water cooling mods), and 3D printed PLA or ABS to hold it all together (actually with non-conductive layers in-between we could probably make a design for people to DIY without 3D printers). Probably with integrated gimbal ball base as desired (easy to add or remove when it’s a 3D printed model).
The cold air from props and movement along the side will draw all the heat away from the barometer and other chips. Also cooling on both sides of the Pi, and potentially cooling the Navio although I’m not aware of any heat issues with those types of sensors (perhaps only the PWM chip?).
The Pi Zero already has the pins removed, and there are examples of people stripping the ethernet, HDMI and USB ports off the full PIs. The Navio pin receptor is quite low profile already so maybe for the sake of keeping the warranty on the most expensive item we should not attempt to remove that.
Perhaps my quick diagram has too many heat sinks (could do away with the ones along the top. It’s difficult to express the whole length of the design in one cross-section. Smart placing around the components would obviously be done. It looks almost as big as the full version in this quick diagram. I really mean super compact, super low, just slithers of material between the components (as thin as effective = needs experimentation).
Then of course we can vary this design, with the PiZero flat, and also sticking-up vertically or to the side like a T (one row of pins connecting to top and other to bottom of Navio may also be neater). Depends on the drone frame design and the overall results to heat disapation and shielding (the flat one most likely being the best all round).
p.s. of course we cannot completely cover the barometer chip and LED. All these limitations need to be factored into the design.
I’ve got a partially stripped pi here that I need to finish, I’m going to move usb connections off board and it will be complete. It’s a pi b+ that I plan to use for some auxiliary tasks. If the mods work, I will do the same to my pi 2.
The removal of components takes some patience. Naked boards would be nice, less heating up the componets unnecessarily. Thus my comment earlier.
For the sake of brain storming I’ll add this to the mix…
Integration of a pitot system would also be a nice addition. On some configurations sampling the baro pressure from a static area away from low pressure created by the props is crucial. The baro cover could be integrated into one of the composite layers. With a generic tube connector that could go to a 3d printed thingy that collects the pressure.