Content Comparison

...

• 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

As an example, here is the GPSinterface. Interfaces to all sensors should look very similar.

void Sensor_class Gps
{
	public:

		/**
		* Initialises internal parameters.
		* Should be called exactly once before anything is attempted to be done with the module.
		*/
		virtual void Init(void) = 0;

		/**
		* Begins the process of collecting void Sensor_the sensor's data.
		* This is a non blocking function that returns right away.
		*/
        virtual void BeginMeasuring(void) = 0;

		/**
		* Gets the information 
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:

...

about the aircraft's position (See GpsData_t struct).
		* This is a non blocking function that returns right away, either with new data,
		* or with old data (in case of old data, the dataIsNew flag of the result struct will be cleared).
		* @param[out]		Data 		pointer to the result struct.
		* @return			AAQUAD_SUCCEEDED, AAQUAD_BUSY or AAQUAD_FAILED
		*/
        virtual void GetResult(GpsData_t *Data) = 0;
};

-

• 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.

...