Controller
The processing (Lobes) part of Controller Hardware
Topics
- communications
- hardware
- controller
- lobes
- architecture
Processing control
Most of the processing that happens on a standard actuator controller are hidden proprietary firmware that enhances the properties of for example actuator control. It could be a closed-loop motion control that incorporates some PID control or other algorithm to make the actuator stable and responsive.
In more advanced controllers, the user is exposed to an interface where basic parameters can be adjusted for these internal algorithms, such as PID constants, max power draw, max RPM etc.
From the perspective of OctoMY™, our model of processing control is more advanced than what is common for standard controllers.
OctoMY™ comes with it's own controller firmware that supports this more advanced model which is described in greater detail in the dedicated articles here. It is the hope that in the future other controller vendors will supoprt the OctoMY™ way of doing processing.
Lobes
OctoMY™ introduces the Lobe. Lobes are named after the distinct regions in our brain dedicated to a spesific task. Lobes represent a concept that simplifies the generalization of processing such that it can be performed on a dedicated controller or be emulated off-board.
A lobe is defined as taking input from one or more sensors and user controls and then generating output to one or more actuators. For example, the most basic example of a lobe is the "Car Steering" lobe.
Car Steering Lobe Example v1
- Input: Throttle position (from remote control input)
- Input: Steering angle (from remote control input)
- Output: Motor throttle (brushless motor ESC)
- Output: Steering servo (RC servo)
In this basic example, the Lobe isn't really doing much work. It simply takes whatever throttle input value it gets and passes it on to the motor. Likewise, it does the same for steering angle, it is sent directly to the steering servo.
The key is that the lobe sets up some expectations to the user; this is made to control any car-like robot. Now a fancy user interface with a seering wheel and foot pedal can be created to match. Further, the decision making of the Lobe is encapsulated into a single unit that can be made to run in different environments. If you have a controler that is not able to run a Lobe, the Lobe processing will be performend in software in the OctoMY™ Agent outside the controller. If the controller supports Lobes, then the processing can be moved to run on-board the controller itself with some benefits:
- The Agent is freed up to focus on other stuff
- Less error-prone operation as signals don't travel as far
- Less power draw
- More snappy operation
- More resilient operation
Since Lobes are well defined, it also means that you can now create elaborate simulation environments where lobes can be tested in software before being deployed.
Now let's add some features to the example Lobe above to make it more interesting:
Car Steering Lobe Example v2
- Input: Throttle position (from remote control input)
- Input: Steering angle (from remote control input)
- Input: IMU (inertial measurement unit) NEW
- Input: GPS (global positioning system) NEW
- Output: Motor throttle (brushless motor ESC)
- Output: Steering servo (RC servo)
Now we added an IMU and a GPS that will provide the controller with real-time approximation of speed, acceleration, direction and more.
Now the lobe processing can be updated to perform things like: * Traction control (burst throttle if movement of vehicle does not match wheel speed) * Adaptive throttle sensitivity (less throttle at lower speed for example) * Adaptive steering sensitivity (less steering angle at higher speed for example) * Adaptive steering correction (make rapid adjustments to steering angle based on vehicle direction vs direction of travel to avoid spinning out) * Drift mode (detect slip, adjust steering to favor an angle that is in the sweetspot for drifting)
This suddenly went from a basic toy to a full blown race-car.
Now you can see the benefits of the Lobe, it allows for encapsulating and generalizeing real-time processing into units that can be simulated and run in different environments.
Lobe types
For lobes to work they need to be well defined as described in the example above.
Lobes therefor have the following properties:
Property | Description | Example |
---|---|---|
ID | Lobes need to be uniquely identified somehow, so that everyone in the OctoMY™ ecosystem can tell them apart. | fgjmw3456yu8efbjne84 |
Nickname | Since random ID strings are difficult to remember for a mere meatbag, we also allow Lobes to set a nickname so that users of the OctoMY™ ecosystem can easily recognize them. | Basic Car Steering |
Version | Lobes are software, and healthy software will be updated with improvements over time. The version number ensures that compatability can be maintained between different controllers and versions of OctoMY. In the best case, versions are compatible, in worst case, the user is told to update. | v1.0.0 |
Interface | The interface is the exact inputs and outputs the lobe needs to work. Some may be optional (such as the GPS and IMU in the example above) | See the Car Steering Lobe Examples above. |
Implementation | The implementation is the actual software that performs the processing on inputs to generate data for the outputs. | See the Car Steering Lobe Examples above and section about implementations below. |
Lobe implementations
So now we arrive at the raisin in the sausage, how exactly should lobe implementations be maintained?
The Lobe manager software will allow the user to design a lobe interface with all the desired inputs and outputs specified and then "export" that interface.
This will output a set of source-code header files in C++.
The header is the exact programming interface that must be met to implement the lobe logic.
The user will then include the header into their own project and develop the logic code.
OctoMY™ Lobe manager provides a toolchain to version-control, build and test the lobe on all supported platforms through the use of Docker and finally deploy the lobe in the lobe zoo.
Users may produce as many lobes they want for themselves,
Lobe control interface
Lobe definitions management
bool lobesSupported();
bool setLobe(ACTUATOR_INDEX index, const QByteArray &lobeData);
QString getLobeTitle(ACTUATOR_INDEX index);
QString getLobeVersion(ACTUATOR_INDEX index);
QString getLobeID(ACTUATOR_INDEX index);
Lobe state management
void getLobeEnabled(ACTUATOR_INDEX index, bool enabled);
Lobe control example
ArduMY implements IController
.
ArduMY is the reference implementation for lobe support in OctoMY™, and supports all Lobe features.
The ArduMY implementation will implement Icontroller
in the following way:
lobesSupported()
reportstrue
to signal that lobes are supportedsetLobe()
will ingest any compatible lobe machine code for index and reporttrue
to signal successful ingestationgetLobeTitle()
reports the title parsed from lobe blob that was set for indexgetLobeVersion()
reports the version parsed from lobe blob that was set for indexgetLobeID()
reports the unique ID parsed from lobe blob that was set for indexgetLobeEnabled()
reports the enabled status for the lobe that was set for index