Need to isolate any ROS library interaction (ROS breaks realtime) behind some abstract c++ interface that we can call “Middleware Binding”
After this first step all the ROS code would be localized in a couple of files and ***all the smacc core core will be free of ROS-Calls***
Some of the functions that would be isolated would be:
- ros::Time::now -> smacc::time_now()
- nh.createPublisher -> …
- pub.publish(..) in the publish status message context-> smacc::publish_status_message(..)
- nh.getParam(..) -> smacc::get_param(..)
- ROS_DEBUG-> smacc::debug(…)
During this stage, we should also…
- Make it more explicit to set the update loop rate
- Be able to set the Signal Detector Rate from a SM Config parameter
- Be able to turn on/off introspection (ROS Debug Msgs) from the SM Launch file
The “Middleware Binding” would be handy to implement several strategies:
- NonRT ROS implementation (the current function calls that make SMACC nowadays fully functional)
- ROS RT
- Dummy RT/empty implementation
Create a Dummy Implementation of the “middleware binding” (this dummy binding would be RT since the code is almost empty: no ros debug messages, no message publishing).
We would lose here many funcionalities (transition topics messages, smacc status messages, ros clients, etc).
The resulting library would almost be boost-statechart with the SMACC c++ API appearance (and concepts).
We would create a very basic example to test realtimeness in this dummy library (we could start from sm_atomic or something even for basic, two states SM with events thrown on entry).
With this basic example and dummy middleware binding implemented in RT we could do a realtime test of our program
We can keep our application working for 24h and check that the transition between two states is bounded clearly (recall the RT charts sent to brett)
Once our basic example is working and demostrated is RT we could start improving the “dummy middleware” to start supporting ROS stuf in realtime (ie: publishing status messages using realtime_toolbox in the same way it is done in ros_control)
Dynamic Casts – Investigate
From Boost Statechart Documentation: Is your library suitable for applications with hard real-time requirements?
Yes. Out of the box, the only operations taking potentially non-deterministic time that the library performs are calls to std::allocator<> member functions and dynamic_casts. std::allocator<> member function calls can be avoided by passing a custom allocator to event<>, state_machine<>, asynchronous_state_machine<>, fifo_scheduler<> and fifo_worker<>. dynamic_casts can be avoided by not calling the state_cast<> member functions of state_machine<>, simple_state<> and state<> but using the deterministic variant state_downcast<> instead.
Question: Is this really an issue?