I don’t know if I would say that anything was added for the third demo that wasn’t in place for the earlier ones. But I think the significance of the videos is that they show an almost complete domination of the 2D space inside this particular simulation environment.
And from a high level view, we were able to do that with basically two tools. First, we used SMACC to chop up our problems into little bits, with individual states, and then we mixed and matched the reuseable behaviors found in SMACC’s Nav2 client.
See here for our current list of reuseable client behaviors…
And with these tools, developers can easily and rapidly develop their applications, while also knowing that as their application grows over time, SMACC can handle it. “It” meaning that you can add more states, more levels of hierarchy, more orthogonals, and more client behaviors, without SMACC breaking. So that you can make that robot do whatever you want it to do.
I’m hoping that ROS developers start using the state machines shown in the videos here as their starting point for application development. Simply copying and renaming the state machines before starting to hack away on them and make them their own.
In this demo it is shown how you can combine the SMACC built-in navigation behaviors with a custom asynchronous control behavior for your mobile base.
For example, in this demo we have a new behavior that is called CbPureSpinning. That behavior performs basically a PID control algorithm in the yaw variable to make the robot spin some angle delta. This behavior is fully described in a single class (so it is easy to understand and reuse) and runs asynchronously inside SMACC in its own thread and that directly interacts with /cmd_vel and /tf (via other SMACC built in components)
Notice in contrast, that SMACC built-in navigation behaviors essentially make requests to the remote nav2 stack.
Yes @DavidW , you could create your own basic controllers inside behaviors like that one and switch between them depending on the state of the race.
A more advanced solution would be integrating a ros-control controller manager into a SMACC component. You could switch between controllers using a behavior “CbSwitchController” depending on the context (or state) of the mission (for example, some aggressive controller or some precise controller). With this approach you would also get the benefits of using roscontrol in your implementation.
