At the current state, WB-Toolbox provides an excellent tool for rapid-prototyping. Adding a new feature of changing a parameter are trivial operations since they are done in Simulink.
However, for controlling the robot this workflow requires the presence of a computer in the robot's network that streams the motor references.
We are currently experimenting the usage of Simulink Coder for removing Simulink from the loop for the runtime usage. What we envision is the following:
Start with rapidly-prototyping a controller in the current way
Test everything in gazebo and on the real robot, tuning all the required parameters
Automatically generate C++ code from the Simulink Model
Deploy the generated sources in the robot's pc (head) and compile them
Execute the controller from the robot's head (possibly as a yarp module)
This workflow would also remove all the latency due to the network transport.
Considering that Simulink executes the model in a single-thread, and iCub's head is a PREEMPT_RT-enabled x86 distribution, this might work without many low-level complications.
At the current state,
WB-Toolbox
provides an excellent tool for rapid-prototyping. Adding a new feature of changing a parameter are trivial operations since they are done in Simulink.However, for controlling the robot this workflow requires the presence of a computer in the robot's network that streams the motor references.
We are currently experimenting the usage of Simulink Coder for removing Simulink from the loop for the runtime usage. What we envision is the following:
This workflow would also remove all the latency due to the network transport.
Considering that Simulink executes the model in a single-thread, and iCub's head is a
PREEMPT_RT
-enabled x86 distribution, this might work without many low-level complications.