To build any sort of autonomous vehicle, you need a controller. This has to handle all sorts of jobs – reading sensor outputs, controlling motors and actuators, managing power sources – controlling a vehicle of even moderate complexity requires significant resources. Modern cars are a great example of this – even non-autonomous vehicles can have separate computers to control the engine, interior electronics, and safety systems. In this vein, [E.N. Hering] is developing a modular autonomous vehicle controller, known as YAUVC.
The acronym stands for Yet Another Unmanned Vehicle Controller, though its former name – Fly Hard With A Vengeance – was not without its charms. The project is built around the concept of modularity and redundancy. The controller, designed primarily for flying vehicles, has an ATMega328P as its primary processor, into which various modules can be plugged in to handle different tasks.
This design choice has several benefits – having separate processors to handle individual jobs can make sense in real-time systems. You’d hardly want your quadcopter to crash because the battery management routines were stealing CPU time from the flight dynamics calculations. Instead, by offloading tasks to individual modules, each can run without interfering with the others. Modularity does come with drawbacks however — the problem of maintaining efficient communication between modules is one of them. [Hering] also plans to make sure the system can be set up to use multiples of the same module for redundancy – similar to modern flight systems in passenger aircraft that weigh the results of several computers to make decisions.
Much work has already been done – with the YAUVC platform already fleshed out with a backbone design as well as modules for WiFi, accelerometers and GPS navigation. We look forward to seeing YAUVC reaching flight-ready status soon!
Surprised to see it’s not made around the CAN bus – which is perfect for real-time and modularity. At short runs, getting the full 1MBPS would be easy too.
It will use CAN in the future. Changing the standard from SPI to something else will be easy due to the modular design of hardware and code. SPI was selected because ATMega328P has two SPIs and is a very common and highly known IC, making the prototype development less painful. When the other functions are mature, the MCU module will be upgraded, together with the main bus.
Since the advent of STM32 flight controllers, designing a new one around an ATMega seems a bit pointless to me. Multiwii development came to halt a few years ago. Mind you, these guys switched in the meantime from F1 to F3 because of the added oomph(even F7 is here, but imho nobody found good use yet of the additional computational force). In the end the heart of the flying business comes down to “realtime” DSP, and an ATMega isnt made for that. I like the modurlarity, but the trend seems to go to smaller quads and flightcontroller – and with the addtitional space and weight of connectors and a backplane, this thing cant compete. It may be a nice project, and a great learning experience, but i doubt it will find great use in the flying world.
Agree. It’s Yet Another Unmanned Vehicle Controller, not Yet Another Arduino Uno Clone.
One of the biggest road blocks is the highly documented PID (proportional, integral, derivative) control algorithm is WRONG.
It kinda, works but can not get a stable control.