I’m looking to use a raspberrypi-4b-running-ardupilot + FC combination, where core flight control (maintain altitude, land, motor control, etc) logic and functions are handled on ardupilot/linux/raspberry.
I still want a flight controller on board because it’s a cheap and convenient way to grab all the sensors I need in one tidy package (but not because I want it to control flight, I /need/ (for what I’m trying to do) ardupilot to do that).
Is this possible?
What should I look for in FCs when approaching things this way?
Welcome to the Community!
What do you mean with sensor packet?
If you want to use a raspberry pi you need a hat were all sensors are included or how do you want to use it?
Thanks for the welcome
So, by “sensor pack” I mean just that. I want to
Run ardupilot as the core software package controlling flight.
Put at its disposal access to the sensors it’ll need (barometer, accelerometer, GPS, ultrasonics, magnetometer if relevant etc). I know I can buy them separately and hang them off the GPIO pins, but I was hoping for a simpler design that uses a cheap and cheerful flight controller with something like serial access instead.
I can’t use raspberry hats. There’s a long reason behind it (I’m not building a drone, I’m building kubernetes clusters on drones) as a swarm control plane, so imagine not one but, say, 3 raspberries that juggle a linux (e.g. docker) container with ardupilot in it. It’s a deep topic and I’m happy to talk more about it. The point here just being that I need something sitting beside all three raspies and wired to all three, or something x 3, with one set of sensors attached to each and every raspberry. It also need to scale from a cost point of view, so popping a navio2 on each one is a non-starter.
It’s between buying the combined set sensors ardupilot needs to be happy independently and wiring them sinultaneously to all three raspies - or buying a single FC with such sensors, and letting ardupilot talk to it via bus.
Thoughts?
EDIT: I’ve also yet to play with how ardupilot will control the ESCs (I’d like to see if PWM via GPIO pins is something it can do… or if I have to put an FC between them).
Ok, this is interesting.
First: I don’t know how(and i’am probaply not the one who can help you with this but let me try to help you) but i have some
This is the thing i wondered about and I just googled it and i found out that you can use Esc’s directly with the Gpio pins
Now to the sensors: There are cheap Hats with (barometer, accelerometer, GPS, ultrasonics, magnetometer) available for 15€ but you said you couldn’t use hats so you could use An Arduino conected per usb wich has all sensors (Here you can read how)
But the main problem is the software because you probably need a custom firmware… (I have no idea)
I’ll have a bit more first hand experience in a few days trying to drive some HW30A’s using using pigpio. I don’t expect that to be rocket surgery, and I expect that’ll work.
The subsequent step will be seeing if ardupilot can do it without having to cut new code. That’s where I’m less confident things will fall into place.
Thank you for the answer re cheap hats… I haven’t seen things cheaper than 50-70 pounds…
Can you link to an example of said cheap hats carrying IMU & friends?
I have a draft blog post I haven’t made public yet that explains it better which I can share off-forum (or on-forum once I’ve hit publish ;)). In a nutshell, I’m aiming to use kubernetes as a swarm control plane for both flight control software and payload software.
At the core of it is the idea that a flight controller should be an app, not a thing. And that a drone should be no less smart than my smartphone.
My endgame goal is a comprehensive open source “integration” project which relies heavily on best-of-breed existing open source projects, that integrates all the components of the stack (reference drone hardware, reference compute hardware, OS, kubernetes, ardupilot, SITL components and any dependencies, SDK, even open compatible reference CADs for 3d-printable parts like the frame), to allow any engineering student on the planet to start cutting a swarm application in the shortest amount of time without having to reinvent flight control, distributed computing, or spend two years on integration. It’s also by no means confined to air drones (same compute platform applies to marine), and automated ground service stations are also in scope but further down the road.
Each drone is a 1/3/more sized kube cluster. A swarm is a federation of clusters. Then use custom resources to control swarm free resources (read: available drones that have not yet been assigned a task towards a requested “fleet behavior” object) and kube operators/controllers to program behaviors.
This is an approach that takes 90% of the reinventing distributed computing work out of doing the same swarm application programming using the dronekit approach.
Awesome thank you.
Order placed. ETA 37 covid-19 years. Not sure what that translates to in dog years
I’m out of daylight… will look more at GPS options tomorrow. Banggood has some $10 SPI options.
Meanwhile… built arducopter successfully several times and started getting familiar with the arducopter codebase - to try and get PWM happening over GPIO… the dev familiarsation guide on this website is fantastic. Very grateful to whoever put in the effort into documenting…
Navio 2 pretty much does what you want to do i guess. It runs Ardupilot on a rspberry and uses a sensor hat. If not, than i do not understand what you are trying to achieve.
Yes it would work but It is way to expensive with 168€. Especially for three drones (already for one drone)
If this works you could go further(even if this isn’t the goal) and make a sub 40$ mini flight controller with way more than 2mb flash
Imagine you could use a raspi zero with 20€ sensors (including GPS) you would have an 35€ mini flight controller with more than 2mb flash
Technically, navio2 is very much what I’d need. Costwise, their approach doesn’t scale.
What I want needs to scale with cost and be tied to the cost of the compute platform.
Think about the solution cost of a 50, 500 or 5000 drone solution when each drone’s compute pakcage is 3 $50 raspberries with two $10 sensors.
Now think about its cost when its compute package is 3 $50 raspberries with a $370 hat each.
See the problem?
On the proviso that the result may not end up being the lowest latency racing drone in the world, unless I am missing something, everything has already been commoditised, and everything but the sensor chip and ESCs can be replaced with software.
That’s a really good point.
This actually creates a nice spectrum of possibilities, ranging from a pi zero on the low end to full scale kubernetes on the high end.
For single drone applications, this would open the door to
a. a pi-zero based flight controller - as you mentioned - but where you don’t have kubernetes underneath ardupilot, because of insufficient ram. (you can theoretically run it on Rancher’s k3s micro distribution of kubernetes… but my practical experience of running that on 512MB pi zeros was very flaky from a running out of memory perspective).
b. a single 4gb memory pi (let’s say $100 all up with sensors) flight controller that does have kubernetes.
What good would a container orchestrator do to a single node drone?
There could be some benefits, such as knowing what you develop can be scaled once you’re done prototyping with less work, such as testing that container on a cloud service in a SITL environment before pushing it to your drone(s), or a universal API (the kubernetes api) to orchestrate your single drone’s behavior as an alternative to a specialised one like dronekit.
c. … and, from there, you can of course go 3-way on each drone or more.
Thanks for the Mini Zee reference - that’s precisely the kind of project I was looking for pointers to.
Is there a reason you went with adafruit [ EDIT: I meant APM ] and didn’t use a software PWM implementation?
Python scripts that demonstrate software pwm control of ESCs via GPIO have been floating around the internet for a while…
Yep that was the talk in 2015 … and it has been demonstrated that GPIO are not stable and precise enough , especially when used at higher PWM frame rates as with ESC
I tried different architectures and finally came to the general consensus of using highly performant STM cores with real time chibios and use a Companion Computer (like RPI) for the high level apps
… and it has been demonstrated that GPIO are not stable and precise enough , especially when used at higher PWM frame rates as with ESC