davetcoleman
commented
7 years ago Then the simulator can run faster than a fixed loop-rate. Would you be interested in adding such a feature?
ROS time was implemented to allow seameless switching between using realtime and simulation time (which can be faster or slower than realtime). However, in ros_control_boilerplate we don't use ROS time much because it does not have good realtime guarantees as far as I can remember. In particular, it does not handle system clock changes in time (such as time server, time zone change, etc). I'm thinking your desires might be outside the scope of this package, but if you could implement a patch that does not break the realtime qualities than I think it might be an interesting addition
add a ROS service through which users can set the simulation into a desired JointState
Sounds like Gazebo's spawn robot joint state service :). This concept is very simulation-centric, and impossible in the real world. While I am interested in allowing the initial state to be changed easily (such as moveit_sim_controller I do not think changing it on the fly is within the scope of this... in a realtime loop having extra ROS message buffers is not good.
Could all these features be added to moveit_sim_controller instead?
I'd like to have a faster-than-realtime planning framework that is distributed across several ROS nodes.
To that end, I suggest to extend this simulator with a mode in which updates get triggered through a ROS topic. Then the simulator can run faster than a fixed loop-rate. Would you be interested in adding such a feature?
Related, I'd like to add a ROS service through which users can set the simulation into a desired JointState. Again, would you be interested in adding this functionality?