Proposal for adding a dynamic simulation mode into the dVRK

[nicolapiccinelli]

Hello @adeguet1,

This pull request is part of a larger project aimed at adding a hardware simulation mode to the dVRK. The simulation mode here is forwarded from the arm_proxy to the specific arm implementation. It is necessary to disable roll calibration of the MTM if the hardware simulation is enabled. I also included a new folder called sim inside the shared folder, which contains the configuration files needed for running the hardware simulation mode.

See jhu-cisst/mechatronics-software#38
See jhu-saw/sawRobotIO1394#17
See #240

[adeguet1]

In the current implementation, the system class creates the arm class, PID and IO if needed. There is currently one simulated mode defined in the system JSON configuration file, KIN_SIMULATED. In this mode, the IO component is not created and the PID sets the measured values directly from the setpoint. For dynamic simulation, there is no code yet but this idea was to create a PID like component that would just talk to the dynamic simulator (Isaac, AMBF...). We could consider adding a HW_SIMULATED defined in the top configuration file instead of having to propagate the is_hw_simulated flag from the bottom (AmpIO) to the top.

[nicolapiccinelli]

In the current implementation, the system class creates the arm class, PID and IO if needed. There is currently one simulated mode defined in the system JSON configuration file, KIN_SIMULATED. In this mode, the IO component is not created and the PID sets the measured values directly from the setpoint. For dynamic simulation, there is no code yet but this idea was to create a PID like component that would just talk to the dynamic simulator (Isaac, AMBF...). We could consider adding a HW_SIMULATED defined in the top configuration file instead of having to propagate the is_hw_simulated flag from the bottom (AmpIO) to the top.

I agree that it is a bit convoluted to have the simulation mode propagated from the bottom. I did not want to change things too much at first. However, a few settings must be turned off in the MTM logic when working with hardware simulation. This could be a solution: introducing the new simulation mode and then checking at the IO level that the port type is set correctly. The issue is that the user has to change the configuration twice to change the mode.

Do you think we can hook the connection to external simulators at the hw level so that we retain the whole control pipeline? @adeguet1

[adeguet1]

Could we schedule a Zoom meeting? You can email me @jhu.edu