Stateflow with QUARC

At Quanser I am always looking to find new ways to make it easier to use our variety of products. As I developed controllers for the Quanser Qball-X4 Unmanned Aerial Vehicle (UAV) I found myself building large, complex models in order to create sophisticated, autonomous controllers. Designing a fully-autonomous controller for a complex system such as a UAV requires many considerations and safety checks to ensure the system operates safely and as it should. For example, at the start of a mission there are various initialization procedures and safety checks that occur. Then, the vehicle enters into a controlled takeoff. Next, the vehicle executes the various tasks that make up its mission. And finally, the vehicle performs a landing and power down.

These complex sequences of operating modes and transitions between modes requires careful planning and design. The most suitable design structure for this would be a state machine. Well, as I found out first hand, Simulink (although great for realt-time control) is not the best tool for designing state machines. Thankfully, The MathWorks has a blockset called Stateflow, which allows you to insert state machine charts directly into a Simulink model. The Stateflow chart gives you a graphical design environment different from Simulink and designed for state machine development.

Using Stateflow, I can develop state machines easily and quickly. Stateflow also supports code generation (with Stateflow Coder), so that I can generate code and download it to my target of choice (e.g., Gumstix with QUARC). I can also see graphically at run time the execution of the state machine and which states are currently active. Stateflow expands on the traditional Mealy/Moore state machines and provides useful tools such as temporal operators, Embedded MATLAB Functions, Simulink Functions, variables, events, and support for C-code.

In my application, the Qball UAV mission controller, I chose to divide my model into two parts: Stateflow chart and Simulink controller (although the Stateflow chart resides within the Simulink model as a block). In my Stateflow chart I put all of my state machine logic, operating mode/state, temporal operations, safety checks, etc. In my Simulink controller I build my continuous time controllers, plants, communications, and hardware-in-the-loop interfacing. This is just my preferred design methodology. This allows me to decouple my state machine and safety checks from the Simulink model, which makes extending and maintaining the model a whole lot easier. Now, my controller is not burdened with safety checks and operating mode checks dispersed throughout the model since it is all concentrated in my Stateflow chart.

In my final design, I have my main state machine that allows me to arm and disarm the Qball, schedule autonomous tasks such as waypoint tracking, automatically handle transitions between TAKEOFF, FLY, and LAND operating modes, and also concurrently monitor various safety checks. If at any time a safety check fails or timeout occurs, a LAND event is generated that forces a transition from a FLY state to a LAND state so that the Qball is forced to land.

At Quanser we see possibilities for using Stateflow in so many of our applications: haptics and telerobotics, unmanned aerial and ground vehicles, simulations and 3D visualization, rehabilitation robots, communications, large-scale integrated systems, vision-based tracking and localization, and many more. I would encourage anyone to take a look at Stateflow and try to find innovative ways to use it in Quanser experiments. Good luck!

Cameron