Documentation

/NGOS

/Signals

/Shells

/Cmds

/Ctrl

/HALs

/Conf

/Params

/Behaviors

/Receiver

/GPS

Next Chapter

The NG Operating System

What features does the NGOS have?

{i} The NGOS allows near-realtime closed-loop control of a Quadcopter's attitude and altitude stabilization while using the remaining processor time for a non-preemtive task scheduler doing fair round-robin of cooperative non-realtime tasks. ;-)

It uses a modular, plugable extension framework for closed-loop control algorithms, called Controllers, and allows for several of them implemented at the same time using a simple abstract programming interface. This allows simple extensions of the system's closed-loop control algorithms by peoples not used to firmware and system programming.

The modular controller framework is coupled with a modular configuration framework, allowing each Controller to have a different set of Parameters in different Configurations.

The system allows multiple shells and their spawned commands to be used concurrently on the different physical i/o devices. The shell command interface is also very modular and allows developers the fast addition of new commands for debugging and testing purposes. Controllers and Configurations can be manipulated online using one of the several shells.

The Controllers output the results of their calculations to a physical abstraction layer called Hardware Abstraction Layer (HAL) which uses a similar modular framework as the controllers. Different multicopter models (eg. QuadCopter, OktoCopter et all) can be implemented and flown using different HALs.

The above is tightly coupled with a behavior system which allows the user to configure arbitrary behavior rules using simple behavior conditions and behavior actions using on of the shells.

For a detailed list of the features check out the Features page!

Why do we call the Firmware an Operating System?

You are right, it's a firmware... :)
... but it has become a firmware with many, many operating system like features!

The firmware does hardware probing on startup and activates hardware depended interrupt handlers. It's split into user, system and irq context, the closed-loop controller is running on the system level, the user mode shells have to use system calls to use privileged opcode. Furthermore it has a timer scheduler and a task scheduler with a process table, it has a device table and it has tools to inspect all of them. The firmware's device-probing dependent interrupt handlers could be called drivers. The started consoles implemented as cooperative shell tasks in user context (which are able to fork off commands) executed by a round-robin scheduler conclude the operating system like features.

An Introduction to the NGOS

NGOS Startup

During startup the firmware probes for known hardware on the different busses. It then marks known and found devices in a device table as detected and allows the rest of the software and the user shells to inspect this information and to activate and deactivate parts of the firmware's code.

The firmware initializes and activates all devices found while probing, if not configured otherwise. It starts the timer scheduler and activates behavior triggering. The last thing a newly started NGOS system does, is to start the task scheduler and spawn several shell tasks on the different i/o devices.

NGOS Realtime Closed-Loop Control

The realtime processes of the system get started from a timer interrupt, which switches from irq to kernel context and then executes a timer scheduler. This timer scheduler schedules a 1ms closed-loop controller process, which triggers the configured closed-loop controller's process method. Depending on the controller's flight-state, it will start to manipulate the motor output signals.

Spinup and Flying

Now flying is a simple thing in terms of the software. A behavior condition triggers (eg Throttle/Yaw stick bottom-right) and a special behavior action (eg. ctrl_enable_motors) gets called which then changes the flight-mode from LANDED to SPINUP. The flight-mode variable represents the controller state machine. As soon as it's no longer LANDED the configured Controller starts manipulating the motor output signals. The Controller will switch to the FLYING state after spinup and controller activation. When it reaches LANDED again, the motors will switch off.

Future versions will use more flight-states. Different NG closed-loop controllers can act differently on the various flight-states.

Documentation/TheNGOS (last edited 2012-06-24 20:34:03 by kroimon)