Clone wiki

YAUVC / Home

Welcome to Yet Another Unmanned Vehicle Controller project

Description

Unmanned vehicles have common needs: energy to think and move around, sensors to interact with their environment, communication skills and servo control. It really doesn't matter if the vehicle is going to fly, float, dive or crawl. In most cases all of the above requirements are present in one form or another.

This project is about a modular flight controller. It was made modular so I could work on one module without worrying about breaking down the rest of the system. I wanted to be able to upgrade a module with a new sensor, component or capability as much as I wanted the whole system to configure itself every time a new module was plugged. Finally, I wanted the system to be able to handle redundancy, just in case the user plugged more than one of the same module, like two pilots, or three sensor modules.

Some details

To guide the system development I followed some guidelines:

  • A generic micro controller module should be developed.

  • The connection between modules should follow some kind of standard, permitting them to communicate easily.

  • The addition of extra hardware to a module should be easy. For that to be true, the generic module should make most of the popular interfaces available to a 'sub module' where the new hardware should be installed. This submodule should be plugged to the back of the generic module and that should be the only requirement for it to work.

  • No module should have the same function as any other module on the system, unless redundancy was required.

I also wanted:

  • Generic modules to be cheap and easily replaceable. I had to select a micro controller to use in them. Out of my ignorance I chose ATMega328p.

  • Generic modules to be able to use different micro controllers, as long as they followed the same communication protocols and made available the same services to the sub modules, in the same pin order.

  • Any hardware installed in the system to be easily replaceable by newer, better versions in a way that the rest of the system would not notice the difference between the new and the old one. Backward compatibility.

This sounds much like an Arduino, but with some basic differences:

  • The ATMega328p micro controller has two SPI interfaces, but Arduino blocks one of them with the serial connection. I wanted both interfaces working: one to use as the main connection to other modules and the second one made available to any hardware installed in the submodule.

  • I wanted every byte of flash and RAM available to the firmware, so the Arduino bootloader was not an option and was removed.

  • I wanted full control of all the firmware code. Hidden code was also not an option. All the C++ code used in the system was (re)written and placed in open source classes.

To make all this work I had to develop and test some standards:

  • The physical generic module size should be standard, be as small as possible, and should include a connection to the main bus and a connection to the submodule.

  • The connection to the main bus should include power lines, communication lines and the possibility to reset a misbehaving module.

  • The connection between a module and a submodule should have as many interfaces as possible, following a standard pin order.

  • The submodule physical size should be as small as possible, but big enough to hold the necessary electronic components required for a vehicle control system, like sensors, GPSs etc.

  • The communication between generic modules should be done using a simple, popular interface. I had to decide between SPI and I2C. The second one seemed to be the obvious pick, but after reading horror stories about locked I2C buses, I decided to use the SPI interface.

  • As both interfaces transmit only a byte at a time, I needed a protocol to be able to transfer floats, longs or strings between modules. This protocol was written in C++ and is also a system standard.

Links to other pages:

SPI_Protocol

Updated