What is the standard workflow for using drake with real robot?

user_12825127 0
Viewed 84

I would like to use Drake to control a real robot (Franka panda or Kuka iiwa). For simulation, the standard workflow would be build a diagram first and then use the Simulator to simulate the diagram. However, for the usage in real robot, I haven't found an example on how to run the built diagram. A close example would be ManipulationStationHardwareInterface. However I haven't found code on how to actual use this interface. Do I need to manually generate the context and run the diagram in a while loop? Or maybe I still need to use the Simulator and use the AdvanceTo method? If I use the Simulator, would there be addtional setting for synchoronization? What's more, how to control the loop frequency of the running diagram?

Thank you in advance!

drake
1 Answers

The ManipulationStationHardwareInterface is indeed a reasonable example to look at. We have an updated version of the coming to Drake soon, too.

The basic steps are:

  • Run the robot's driver as a different process. Some of the drivers we use are public and are hosted here: https://manipulation.csail.mit.edu/station.html .
  • Send / Receive messages from your main controller thread to/from your driver. The LCMPublisherSystem and LCMSubscriberSystem are right in Drake. The ROS/ROS2 equivalents are here: https://github.com/RobotLocomotion/drake-ros (The ManipulationStationHardwareInterface + manipulation_station_simulation file in Drake shows an example of splitting up a Diagram for control + simulation into two processes using this message passing.
  • Timing: in the simplest case (typically ok for hardware) all of the executables are running with simulator.set_target_realtime_rate(1.0) and then simulator.AdvanceTo(big number). In other words, they all synchronize their clocks to the cpu clock, and don't try to synchronize explicitly to a clock passed via message passing. That sort of synchronization is possible, too, but I recommend the simpler version first. In this simple version, each system (e.g. your controller) is set to update with some periodic update -- say 100Hz -- and will run its computation using the most recently received subscribed messages and publish at that rate.
user_95100200
Related