Page Comparison

Overlooks other managers and forwards queries/data to respective drivers/managers.
For Milestone 1, it basically needs to act like a 1:1 mapping between input and output. Later on, Milestone 2 onwards, it needs to be a more “intelligent“ being.
May run RTOS (after Milestone 1)

...

Table of Contents

minLevel	1
maxLevel	6
outline	false
style	default
type	list
printable	false

🤔 Problem Statement

In the Zero-Pilot Architecture, System Manager is the highest level entity. System Manager parses controller inputs, overlooks and orchestrates the conversations between other managers, and manages the state of the drone.

Milestone 1 Implementation

For Milestone 1, System Manager is a simple class that has a manual flying mode. Here is a list of available functions with the System Manager class for Milestone 1.

Function Name	Purpose	Return Type
Public Functions
fly_manually	Puts device in manual control mode, gets data using SBUS, and executes commands on the motors using PWM Out driver.	None. Void Function.
Private Functions
set_control_mode	Sets the control method of the device. Mainly for state-keeping. In the future, it will notify AM about this change.	None. Void Function.
set_arm_mode	Sets the arm mode of the device. Mainly for state-keeping. In the future, it will notify AM about this change.	None. Void Function.
set_flight_mode	Sets the flight mode of the device. Mainly for state-keeping. In the future, it will notify AM about this change.	None. Void Function.
get_control_mode	Returns the current control mode on the device.	CONTROL_METHOD alias for int
get_arm_mode	Returns the current arm status on the device.	ARM_MODE alias for int
get_flight_mode	Returns the current flight mode set on device.	FLIGHT_MODE alias for int
execute_input	Executes passed data on the motors	None. Void Function.

Milestone 2 Implementation

Goal: Integrate Attitude Manager and Telemetry Manager by threading them so that the two managers run in “parallel”.

Current State: System Manager directly sends RC data to motors after converting it to percentages. Data is not processed at all. Watch Dog is called by System Manager every loop. Complicated arm/disarm fail-safe in place.

Key Notes:

Make sure to allocate enough time for each manager so that its processes have enough time to execute
May have to implement a queue for data
May have to implement interrupts

ZP 3.5b SM Rearchitecture

The purpose of this rearchitecture is to introduce dependency injection such that it is no longer hardware dependant. Will support a gtest friendly build and a hardware friendly build via injection.

The following are the list of present assumptions in place for each interface rearchitectured SM will deal with.

RC Driver:

Will support a ->get() method in the interface
Stucture of respond currently unknown, for now assume it has roll, pitch, yaw, throttle
Will also support a ->is_data_new() method in the interface

Inter-Manager Queue Driver:

Will support a ->pop(), ->get() and a ->push()
Only ->push() is relevant for SM
Will push any messages that need to go to AM

Attitude Manager:

Agreed structure for queue messages from SM to AM is attached below:

Code Block

language	cpp

typedef struct {
    int8_t roll;     // Roll percentage
    int8_t yaw;      // Yaw percentage
    int8_t pitch;    // Pitch percentage
    int8_t throttle; // Throttle percentage
} RCMotorControlMessage_t;

Reference Material

Link to previous SysManagers

Link to a simple SysManager https://github.com/UWARG/SimpleSystemManager/blob/master/Core/Src/main.cpp

Miscellaneous Notes

Watch Dog: an electronic timer that is used to detect and recover from errors within embedded systems. Within a specific time period, the system has to notify the Watchdog that it is still operational. If the Watchdog does not receive this notification then it assumes there has been a failure and places the system into a known state (usually error state, in this case, disarm (I believe)).

Versions Compared

Old Version 1

New Version Current

Key