A Brief Introduction and History:

ZeroPilot (ZP) is the successor to PicPilot, and is WARG’s in house flight control software. Historically, ZP has interfaced directly with the HAL libraries provided by STM32. For the 2022 Competition Season, multiple files interfaced directly with the hardware…

2022 Competition Safety Chip Architecture

So far has been fine since we have use the same chip, but as we begin the port to nucleos and as we begin to develop into a future of chip-shortages and buying whatever chips we can, there begins to arise a need for a hardware-interface layer between ZP and the chip interface itself.

Enter LaminarOS (LOS), WARG’s new custom OS designed to interface between Zeropilot and STM32 Chip.

1 A Brief Introduction and History:
2 Overview of System Architecture
3 LOS Interface
- 3.1 LOS_Link
- 3.2 LOS_Telem
- 3.3 LOS_Comms
- 3.4 LOS_Pos
- 3.5 LOS_Actuators
4 LOS Drivers (currently just existing under subdirectories in LOS_Interface)
5 LOS Core

Overview of System Architecture

Our ZeroPilot firmware acts as the instruction layer. With this new proposal, ZeroPilot acts as a high-level processor agnostic software stack designed to interface with LaminarOS. LOS should handle all the hardware interfacing and acts as a custom middleware/HAL library between ZP and the processor.

Proposed ZP-LOS-HW Stack

LOS Interface

The interface is the primary layer that will communicate with ZP. These interfaces should define common structs (or data types) that will remain platform agnostic (i.e. pitch, roll, yaw, user stick inputs, link status, etc). This layer should contain all the communication between ZP, that is to say: this should be the only layer which is externally accessible. Generally, LOS_Interface will call LOS_Drivers, but in some occasions may directly interface with LOS_Core (i.e. GPIO, LED’s, debug, etc.).

Hopefully, we can get mailboxes / rtos / something working so that these interfaces are non-blocking, but for now…

LOS_Link

LOS_Link should be the interface through which all RC_Link communications happen. The choice to make LOS_Link separate is mainly driven by the fact that tele-op must always work, and the less we can modify working code the better.

// example of struct which may be passed by LOS_Link
struct LOS_Link_t {
  uint8_t inputs[NUM_RC_INPUTS];  // passes number of RC Inputs
  float   link_quality;           // link quality metric (if it exists)
};

LOS_Telem

LOS_Comms should handle the REST of the communication (that is not the RC_Link) between ZP and ground from firmware. This is also a file that generally should not be changing much.

// example of struct which may be passed by LOS_Telem
struct LOS_Telem_t {
  // start with attitude telem
  float pitch;
  float yaw;
  float roll;
  float motor_out[4]; // 4 motor outputs to be seen
  Location_t pos;     // position output
  Location_t targ;    // target position (if autopilot)
}

LOS_Comms

Air-Air Comms with CV should go through the LOS_Comms interface.

LOS_Pos

Position data passes through here. Not sure if this should be before or after sensorfusion…

LOS_Actuators

Motor outputs pass through here.

LOS Drivers (currently just existing under subdirectories in LOS_Interface)

These files house all of the drivers for specific sensors! It is in the middle layer between LOS_Interface and LOS_Core, and can access LOS_Core directly.

BMX160
VN-300
PPM Receiver
Telemetry drivers
SD Card (for logging)

LOS Core

These are the core files which interact directly with the HAL Libraries. They will be used by LOS_Drivers and LOS_Interface files to access bare metal components

LOS_Core_Tim
LOS_Core_I2C
LOS_Core_SPI
LOS_Core_USART
LOS_Core_SWD
LOS_Core_GPIO

Embedded Flight Software

Laminar OS