This page details the high-level design behind the autopilot code.

TODO: draw better state machines, write better descriptions and update things to match what was dicussed during the last meeting.

Path manager

• The sensors relevant to the path manager are the GPS, altitude sensors, and anything responsible for communicating to/from the ground.
• As with the lower level, this architecture is also interrupt based.
• Not sure how we should manage loop period. Should this be run more or less often then the lower level loop ? And how to keep loop periods constant when we have 2 separate loops running.
• Gps stuff comes around fairly slowly and can be fairly inaccurate. As mentioned in Asana, seems like a good idea to fuse measurements made by the lower level with it to figure out what is going on. I don’t think this was implemented in PicPilot.
• The PicPilot does a ton of really cool waypoint tracking stuff. I think most of it is fine to port over.
• A couple things not included in these documents: Battery level checkers, led managers... Not sure where these things should go.
• Autonomous takeoff/landing is still a whiles away, but not sure how it would fit into such an architecture. Probably want another state machine that takes control from this one when we deal with take offs/landings.
• Not sure how often data needs to be sent to/received from the ground. We should make sure that uncertainty is accounted for when figuring out how often to run this loop. Surely FreeRtos gives us methods for doing things like this.
• Actually, I’m having second thoughts about having ground communications be part of this module. What does path managing have to do with ground communication anyway ? Maybe a third module should exist, feeding this one with relevant ground data and figuring out what to give the ground.

Attitude/airspeed manager

• The sensors relevant to the attitude manager are the IMU and the airspeed sensor.
• This architecture is purely interrupt based and we need spend no time polling.
• The “trigger new measurements” state exists to begin the I2C/uart/spi/whatever exchanges with the appropriate sensors. These exchanges should all be interrupt based so we are free to process data in the mean time (this is different then PicPilot, where IMU data is polled for).
• Some sensors are faster than others. The “trigger new measurements” state is simplified. Ideally, we have various tasks assigned to FreeRtos that all fire at set periods to trigger the given sensor’s measurements.
• The control period should be the slower of: the fastest sensor’s refresh rate or the time it takes to perform all the computations ( not quite sure how to keep things at a regular period, considering there is a higher level state machine also running??? Freertos surely has ways for this to work).
• Any time we don’t have a new measurement (if we even run that fast), maybe we should extrapolate what’s going on based on previous measurements.
• Looks like most of the data processing algorithms used by the PicPilot can be ported. Pid gains have even already been tuned for Spike it seems.
• Stall protection / verifying whether the higher level is asking for garbage belongs in this module.
• The whole “gather new instructions” and “Communicate results” thing might not need to actually be operations done. We may want to have key things shared between higher and lower levels. This was done across multiple chips via DMA on the PicPilot. Things would be much simpler here since we’ve only got one big autopilot chip.
• Autonomous take offs/landings should be opaque to this module. If a higher level module tells it what speed and attitude the plane needs to be at, this module just obliges, having no idea whether we’re at 10 000 feet or about to land/on the ground.

Sensor interfaces

void Sensor_Init(void);


void Sensor_BeginMeasuring(void);


SensorStatus_t Sensor_GetResult(SensorStruct_t *SensorStruct);

Where Sensor status should be 1 of:

• SENSOR_SUCCEEDED if data is available
• SENSOR_BUSY if data is not yet ready
• SENSOR_FAILED in case of some kind of failure.

Some notes:

• I think we’ll have to do something different for the devices responsible for communicating to/from the ground.
• None of these functions should be blocking.
• The “Sensor_BeginMeasuring” function should simply trigger some sort of interrupt (and DMA if we’re really fancy) based exchange between the chip and the relevant sensor and return right away.
• The “Sensor_GetResult” function should also return right away. Mostly this is just a way to access the data. We could avoid having this function entirely if we share data globally between the sensor interfaces and the state machines, but then we sacrifice modularity… anyway, discussions for later.
• For this summer, I don’t think we need to go any lower level then writing these header files for each sensor. The unit testing framework will allow us to get data out of these functions without them having any “guts”, so we can build from here.
• There is an argument to be made to returning some sort of error code from the sensor to indicate what went wrong. I’m not a fan personally, when things go wrong, does the software sit around and try to fix it or do we just assume the sensor is unfixable. Anyway, it’s a discussion we should have.
• We might find it useful to add a 4^th function to the interface: “Sensor_Calibrate” which might either load calibration values we stored earlier or execute a calibration or something… Anyway, not really relevant to this summer.

RTOS

The main autopilot systems are built on FreeRTOS, an open-source Real-Time Operating System. FreeRTOS gives us the ability to run multiple concurrent tasks on a single embedded system, each of which has a priority and can "block" for a period of time while they wait for data. At any given time, the highest priority task that is not blocking will be running.

A few notes about developing for real-time systems:

• Treat timeouts as a design error. Most blocking OS functions on the autopilot allow (or require) specifying a timeout for the blocking operation.

Autopilot Drivers

Required:

• GPS
• XBee
• Altimeter
• IMU
• Interchip
• EEPROM

Optional:

• Airspeed
• Battery
• Ultrasonic

Safety Drivers

Required:

• PWM
• PPM
• Interchip

Autopilot Logic

Required:

• Task management
• PID
• Waypoint management
• Navigation
• Telemetry
• Autonomous level
• EEPROM storage
• Startup codes

Optional:

• Sensor fusion
• Landing/take off
• Multi-vehicle

Safety Logic

Required:

• Anonymous level
• Safety switch
• PPM disconnect
• Startup codes
• SPI heartbeat