search

ros-controls / joss_paper

6 stars 8 forks source link

Review comments by Adolfo #15

Closed adolfo-rt closed 6 years ago

adolfo-rt commented 6 years ago

I originally misread the target journal, I thought the submission was for JOSER, which is specific to robotics, whereas JOSS is about open-source software in general. We must assume no robotics background in the target audience.

In what follows, I added inline comments to the summary as of e42c26e. Comments are written informally, not meant for direct substitution on the summary.

Summary

In recent years the Robotics Operating System [@quigley2009ros] (ROS) has become the 'de facto' ~standard~ framework for the development of software in robotics. The idea of ros_control originates from the PR2 robot's pr2_controller_manager framework

Note strikethrough ~standard~ above.

The motivation should be more explicit:

  • What is ROS unable to deliver? ability to run real-time code. Most robotics software doesn't require real-time. Control (sometimes) does.
  • What is the relationship with its predecessor, the pr2_controller_manager? robot-specific vs robot-agnostic. Mainly the abstraction of hardware interfaces, making as few assumptions on the hardware and OS (more rt-friendliness) as possible.

with some ideas borrowed from OROCOS [@bruyninckx2001open].

This statement is too vague. The relationship or comparison with Orocos should be more informative. Orocos is a feature-rich framework for real-time robot control, but has a steep learning curve and a much smaller user base than ROS. Informally speaking (not meant for article consumption as-is), we want to ride the ROS wave adding as little encumbrance as possible; we want to solve 80% of the robot control usecases, as addressing the extra 20% would add a lot of complexity.

The ros_control framework provides the capability to implement and manage robot controllers with a focus on both real-time performance and sharing of controllers in a robot-agnostic way. The clear, modular design of ros_control makes it ideal for both research and industrial use and has indeed seen many such applications to date. ros_control is out-of-the-box compatible with 3rd party software such as MoveIt! [@moveit], the ROS navigation stack, Gazebo[@koenig2004design] and others.

I would associate this paragraph to the second figure, and also be more explicit on which pain points are addressed. The figure can be the element around which the framework description revolves:

  • Hardware abstraction: Models hardware resources provided by the robot for controllers to use, e.g., low-level sensors like encoders or force/torque, electric/hydraulic actuators. Ability to mix and match heterogeneous hardware, swap hardware components transparently or even swap hardware with simulation and share everything else upstream, (maybe modulo controller parameters). Additional built-in functionality consists of mechanical transmission models, safety limit enforcing (e.g. joint position, velocity, effort limits).
  • Controllers are hardware agnostic. They specify required hardware resources to be able to operate. Their lifecycle is not static, and controller configurations can be queried/modified at runtime: start/stop, reconfigure (controller_manager). Controllers expose standard ROS interfaces for out-of-the box 3rd party solutions to robotics problems like autonomous navigation (nav stack) and manipulator path planning (MoveIt). You can also implement your own custom controllers.

Consider highlighting the example that if your base+arm robot has a hardware interface, then you need to write zero additional code (only configuration files, albeit a bunch ;) to make the base capable of autonomous navigation and the arm capable of collision-free path planning.

On the paragraphs that follow: The description is a bit arid. I'm thinking how to maximize the capacity to explain what this is all about to non-roboticists. This is one of the reasons I propose above to ground concepts around a diagram, highlighting the different pain points the project addresses.

The backbone of the framework is the Hardware Abstraction Layer, which serves as a bridge to different simulated and real robots. This abstraction is provided by the hardware_interface::RobotHW class; specific robot implementations have to inherit from this class. Instances of this class are then used to interface the robot hardware (including some low-level sensors) to higher-level controllers. This allows higher-level controllers to be hardware-agnostic and easily shareable.

There is a possibility for composing already implemented RobotHW instances through the CombinedRobotHW class.

Not sure if we have to be this specific about class names (what value is it adding?). The Journal guidelines assume that the project has good documentation, API and otherwise. I would not emphasize so much on class names, but the ideas behind those classes.

The latter is ideal for constructing control systems for robots where parts come from different suppliers, each supplying their own specific RobotHW instance. The rest of the hardware_interface package defines read-only or read-write typed joint and actuator interfaces for abstracting hardware away. Through these typed interfaces this abstraction enables easy introspection and increases maintainability.

The controller_manager is responsible for managing the lifecycle of controllers, and hardware resources through the interfaces and handling resource conflicts between controllers. It provides a standard ROS service-based interface for controller lifecycle management and queries.

Furthermore, ros_control ships software libraries addressing real-time ROS communication, transmissions and joint limits. The realtime_tools library adds utility classes handling ROS communications in a realtime-safe way. The transmission_interface package supplies classes implementing joint- and actuator-space conversions such as: simple reducer, four-bar linkage and differential transmissions. A declarative definition of transmissions is supported directly within the robot's URDF [@garage2009universal].

If we talk about URDF, give some minimal context, and expand the acronym the first time it is used.

The joint_limits_interface package contains data structures for representing joint limits, methods to populate them through URDF or yaml files and methods to enforce these limits. control_toolbox offers components useful when writing controllers: a PID controller class, smoothers, sine-wave and noise generators.

The repository ros_controllers holds several ready-made controllers supporting the most common use-cases for manipulators, mobile and humanoid robots, e.g. a joint_trajectory_controller is heavily used with position-controlled robots to interface with MoveIt!.

Finally, control_msgs provides ROS messages used in most controllers offered in ros_controllers.

ros_control was conceptualized by Sachin Chitta at Willow Garage Inc. and initial design and implementation was done by Sachin Chitta (then at Willow Garage), Wim Meussen, Vijay Pradeep and Eitan Marder-Epstein (then at HiDOF) before being released open-source.

ros_control is released as binary packages with each new version of ROS, source code is hosted at the ros-controls Github organization. Documentation on behaviour, interfaces, doxygen-generated pages and tutorials can be found at ros_control and ros_controllers. For a thorough presentation we invite the interested reader to watch the talk given at ROSCon2014 [@rodriguez2014roscon].

Robots using ros_control

Being a mature framework, ros_control is widely applied to both production and research platform robots. A few examples where the control system is implemented with ros_control are:

The list appears to be ordered randomly. Maybe sort alphabetically by company/institute name.

The two figures have significant overlap. One should suffice.

Finally, please add my current affiliation: Pick-it NV

bmagyar commented 6 years ago

Thank you @adolfo-rt ! Your comments were very thorough as always & very useful as always ;)