This page lists a few ideas we have for expanding the functionality of ROS-Industrial nodes. We welcome your suggestions on any of these items. Or, feel free to suggest more features!

Communications

• reset service to reset comms with robot controller

• specify ports to use for connection to remote robot (not just IP address)

Robot Parameters:

• provide a pair of services to get/set named "parameters" (i.e. variables) on the robot controller
  • this could be used to set application-specific constants (e.g. job/task name, position-queue variable/index, etc.)
  • or could be used to change robot-driver behavior (e.g. broadcast rate of status messages)

• on initialization (or reset), the ROS node could push down specific ROS parameter values to the robot, allowing control of robot-side parameters from the ROS parameter-server infrastructure

Cartesian Position/Commands

• publish robot's internal version of its cartesian position/velocity/acceleration
• command robot motion to specified cartesian points

  • alternatively, command linear robot motion between specified joint points

• singularities and redundant kinematic solutions (i.e. "configurations") may be difficult to handle in a generic manner

• will require services to set robot-side BASE and TOOL frames to match their ROS equivalents

Diagnostics / Logging

• get_robot_info service to get descriptive info from the connected robot

• echo robot_state, position, and other values to ROS [[diagnostics|diagnostics] framework

  • for user-level feedback and historical analysis

• add Publish Topic to broadcast a list of active robot-side error messages

  • this allows easier display of _current_ vs. _historical_ messages

Motion

• add flag to control behavior when motion commands are interrupted
  • queue - execute new command _after_ current motion completes
  • interrupt - immediately begin motion to new command
  • stitch - overlay motion commands using trajectory timestamps
  • stop - stop current motion and log an error
  • ignore - ignore new motion command and log an error
  • ... ?

• add parameter (or service) to control position-streaming buffer size in the robot-side driver
• add function (service or C++ utility function) to wait for the current motion to complete
• allow single-step execution of trajectories

  • stop after each point, waiting for a manual start_motion call

• all reverse motion along trajectories

• add set_drive_power service to enable/disable robot drive power

• add start_motion service to resume motion after a fault or pause

• Line tracking support? (Expose Robot's line-tracking features in ROS)

• Add ability to switch motion modes on the fly. Currently, the method of control (Position, Velocity, something real cool I don't even know about) is hidden from the user. In some sense this was desired because the approximate function of the robot should be about the same, but sometimes the motion mode is important. The current method of switching motion is through changing the driver code (server and client). Ideally a single server/client combination would be able to support multiple modes of control. See this discussion for more details:

State Feedback

• set feedback publish rates (for position and status)

Fault/Mode Change Behavior and Recovery

• The recovery from a mode change or fault on a robot controller should be standardized.
  1. Mode(Auto/Manual) or Fualted change - When in auto, the robot is under remote ROS control. A switch to manual or faulted condition (like e-stop)should result in the following:
     1. Any currently executing path should be cleared
     2. The robot state/status and other non motion related tasks should continue to run
     3. The robot mode status should indicate the change
     4. Any motion commands should be ignored or failed if a service type
  2. Auto mode recover - When a robot mode is changed back to auto, it should result in the following.
     1. Upon returning to auto mode, the robot should not move and wait for incoming motion commands.

Logging

• Messages generated on the robot-controller should be logged into the ROS framework, to facilitate debugging and status-monitoring from remote PCs.

  • this logging should include all common message sources:
    1. robot-controller-generated messages
    2. ROS robot-side driver messages (e.g. user code)

    3. NOTE: different methods may be required to capture these different message sources

  • ideally, each message should be logged when first generated/received

  • set_remote_logger_level service to control logging of remote robot messages

Other

• add topics to control robot-connected I/O