“An obvious application of orthogonality is in splitting a state in accordance with its physical subsystems.” – Harel (1987) pg. 14
Orthogonality, one of the three additions to state machine formalism originally contributed by Harel in his 1987 paper, is absolutely crucial for the construction of complex robotic state machines. This is because complex robots are, almost by definition, amalgamations of hardware components such as sensors, cameras, actuators, encoders, sub-assemblies, etc.
In SMACC, Orthogonals are classes, defined by header files in their respective state machine, created by the State Machine upon start-up, then inherited by every Leaf State in that state machine, that serve as a container for clients, client behaviors, othogonal components, maybe shared pointers. For the most common use cases, they contain one Client, and either zero, one or multiple client behaviors in any one state.
They also function as namespace (I like to think of them as a last name), that allows you to specify and diffentiate between multiple instances of the same client in one state machine. For example, imagine a robot that has two arms, that both use their own instance of the SMACC MoveIt Client found in the SMACC client library, each running in a unique orthogonal (like OrLeftArm, OrRightArm).
The typical case, is that each device, such as an imu, a lidar scanner, a robot arm or a robot base, will be managed in it’s own orthogonal.
Let’s look at the examples below, and remember from the naming convention page, that…
- OrCommLink = Communications Link Orthogonal
- ClRadioDataLink = Radio Data Link Client
- CbFrequencyHop = Frequency Hop Client Behavior
To see Orthogonal code, here are some examples from the sm_reference_library..
Othogonals an regions of the brain
One more advanced concept I’d like to encourage developers to consider, is to expand the concept of orthognals beyond that of completely physical “hardware” subsystems, and in some situations to think of orthogonals as being analagous to regions of the brain, particularly in use cases that call for data structures that are simultaneously used by multiple orthogonals.
An example use case would be something like an orthogonal that’s similar to the visual cortex (OrVisualCortex), that integrates data from say, a camera orthogonal (OrCamera), a sonar orthogonal (OrSonar) and tactile feedback (OrContactSensor), that allows a a hypothetical robot’s 3D perception system to work in both well-lit and low-light environments.