Project Title

Project Description

Status

Path Planning Optimization

The current path planners have been developed using very few assumptions about the world. This is key to their generality but results in slow path planning. In an industrial setting, assumptions about the world can be made which would result in much faster path planning. Path planning needs to be performed in the 100 ms for most applications. Slower path planning would require planning in parallel with other non-motion tasks (this is not out of the question)

Not Started

3D Pose Estimation Reliability Study

ROS' ability to segment, recognize and estimate the 3D pose of objects based on sensor data is one of it's unique features. All of this capability has been developed for the complicated problem of service robots in the home. In a manufacturing environment both the objects and the environment can be manipulated (within reason) to make this problem easier. That's not to say that we have the ability to specify single parts on a homogenous background, those applications have already been solved. To be unique ROS-Industrial will have demonstrate pose estimation in more complex, yet constrained, environments. The reliability of ROS to perform this task is critical to many new applications and must be quantified. Such quantification will reduce project risk by identifying failure rates and environmental aspects that must be controlled.

Not Started

Interactive Grasp Planning

The grasp planning group has demonstrated an interactive grasping application. The application allows the user to specify (in rviz) a desired grasp. The application gives feedback to the user indicating when the simulated gripper has encountered an object and also whether the arm kinematics allow for the gripper pose. Such an application not only makes a very neat interactive demo, it would also have applications in tele-robotics with industrial manipulators.

Not Started

Mobile Base Integration

Mobile manipulation will enable many new applications. Many of the robot vendors are providing mobile bases for use with their manipulators, but there is a lack of integration. It is left up to the integrators to write the desired software. If ROS-Industrial can provide a library for integrating a manipulator and mobile base, this would provide functionality that is not currently available. To be most useful, the library would have to provide task level functionality(i.e. positioning of the mobile base and manipulator with a single command).

Not Started

Generic IO Interface

A generic interface is needed for networked inputs and outputs. In a standard automation cell, IO is generally connected to the master controller via one of the common field buses (EthernetIP, DeviceNet, Ethercat, ControlNet, Modbus, etc). The vision of ROS-Industrial is that the PC running ROS could function as the master controller (at least for IO that does require real time control). In order for this to occur ROS drivers for the various network types will have to be created or wrapped in nodes. The goal of this task is to develop a higher level of abstraction that defines IO generically and would allow for communications on any type of network. Such a level of abstraction is possible because despite the greatly number of networks and the difference, they have the same basic structure for device addressing.

Not Started

Industrial State Machine

The high level function of a robot workcell can easily be described in terms of a state machine. Several standard modes of operation exist, including: manual, automatic, faulted, fault recovery, homing, etc. Furthermore the sub-states of these modes and the transitions between modes can also be standardized. A high level state machine structure does not exist in the typical robot programming languages and therefore must be re-implemented for every robot work cell. Creating a high level structure would remove this re-impmentaiton cost and allow developers to focus on the sequencing of events that are specific to every installation. In addition, common modes of operation such as fault recovery can be made more robust as compared today where fault recovery is done in a more ad-hoc manor.

Not Started

Automated CAD to Environment Model

ROS performs all of its path planning using a combined static and dynamic environment model. For many applications much of the robot cell can statically be defined based upon CAD models. The current method of importing CAD models requires individual models to be imported and positioned in the environment model (or URDF, which is better?). The model and placement is typically captured in a CAD assembly, but importing a whole CAD is problematic. The environment model would treat the assembly as a single model, creating a single convex hull for the whole cell. Such a convex hull would include much, if not all of the robot workspace, resulting in a robot in constant collision with the environment model. The process of importing a robot cell into the environment model needs to be streamlined by either providing one of the following: a method for importing a CAD assembly, an automated method for determining a set of convex hulls for a single model (this might be useful elsewhere and would result in a robust solution regardless of assembly configuration), something else?

Not Started

Field bus Support

Direct access to IO by ROS is limited by the types of IO networks/field buses that it supports. Currently, only Ethercat is supported. EtherCat is not as broadly supported by device suppliers as some of the other field buses (DeviceNet, ControlNet, Profibus, Modbus). Support for a more popular field bus would enable the use of a larger pool of devices

EtherCAT support

Work Cell Layout Tools

The layout of a robot workcell is more of an art than a science. Several factors drive the workcell layout, but most critical is the robot ability to reach all desired locations (position and orientation). The more dynamic the workcell the more likely educated guess are to be employed. A key reason for this is that the robot work envelope provided by vendors does not accurately define the true robot work space which includes robot position and orientation. Other factors, such as, joint limits, collisions, tool geometry and arm configurations affect the true robot workspace. A tool is needed to evaluate the robot workspace and aid in the robot placement.

Not Started

Robot Cell Self Mapping

Developing a robot work cell model can be problematic. Although 3-D models of work cells typically exist, they often don't contain every detail. In the worst case, using a 3-D model alone could result in a robot collision because the path planners do not know about all objects in the workspace. 3-D sensing technology gives us the ability to make detailed 3-D maps of our surroundings. Such a map of a robot cell would contain more detail than any 3-D model. A project is proposed where a robot mounted 3-D sensor is used to view it's surrounding and develop a detailed 3-D model. Key questions includ how detailed of a model can be generated, how does sensor noise affect model accuracy, to what extend 3-D (CAD) models are required to fill in holes .

Not Started

Industrial Robot Simulation

Each robot vendor sells a simulation environment. For the most part the software allows one to setup a virtual environment from 3D models and execute robot programs (simulating the actual controller execution). These environments are tremendously useful for evaluating cycle times and testing the positional limits of the workspace under static conditions. However, the software does not simulate sensor feedback (at least not complex sensors), so the robot behavior under dynamic conditions that require sensor integration are not easily simulated. Other vendors (mainly delmia) sell general simulation software that includes some level of robot simulation. Their ability to simulate complex sensors (particularly 3D sensors) is uncertain. The gazebo simulator in ROS, with it's sensor simulation capabilities, could provide a better simulation solution for integrating complex sensors.

Spring 2013

ROS-Industrial Messaging

ROS-Industrial will provide libraries to simplify connections (especially on those controllers that support C/C++). Part of this library includes a simple messaging protocol that mimics ROS messages but allows them to be sent over a Ethernet connection. A similar approach is taken in ROS Serial. It would be nice to standardize on a protocol that has wider support. A quick look has found the following limitations: The ROS Serial handler code that runs on the embedded system provides a lot of functionality for automatically negotiating topic connections. The ROS-Industrial approach must keep in mind the capabilities of all robot controllers. The auto-negotiation process would have to be implemented on several controllers. It is not clear whether all controllers would be capable of this. Instead, ROS-Industrial will implement a fixed set of topics/services. The ROS Serial executable code will not be used, but the protocol defined in ROS Serial will be. The ROS Serial protocol does not handle arrays well. Since the main message that is sent between ROS and the robot controller is the trajectory message, which includes arrays, this functionality must be verified/cleaned up/fixed. Dynamic memory allocation on the robot controller is to be avoided (memory leaks will cause dangerous problems on the robot). Verify that the ROS Serial serialization code does not require dynamic memory allocation.The ROS Serial or protocol subset should be capable of being complies and loaded on the robot controller. We currently have access to the Motoman controller, so this will be our test bed.

Not Started

OPC Integration

OPC defines a data access protocol for many industrial systems. Most UI's use OPC clients to access data on industrial systems (robot controllers, PLC, etc…). While OPC is standardized, the data (i.e. IO, robot state, etc…) and the user interaction (start, stop, reset, etc...) is specific to each application. The ROS-Industrial approach is to standardize the data and interaction interfaces so in some ways ROS-Industrial is a superior approach. However, OPC is deeply rooted in industrial systems. Providing roes-bridges for OPC servers and clients ensures that we will be able to leverage existing tools. Human Machine Interface (HMI) development package are the best example of a tool that many people are used to and will not give up easily. Supporting the HMI tools in ROS-Industrial is very important

Not Started

Evaluating Path Execution Accuracy

A key differentiator/selling point between robotic systems is path execution accuracy. This includes spatial accuracy (how closely does the robot follow the desired path) and temporal accuracy (does the robot reach the desired point at the desired time). This will be something that robot vendor and integrators will ask about. For some applications the path execution is critically important (like welding). For other applications only the end-points are important. Other applications require high path accuracy in order to ensure the robot does not collide with the environment. Formal testing of the path execution should be performed on every system. For the most part, path accuracy will be a limitation of the ROS/robot interface and will not be affected by the ROS planners themselves

Not Started

Broadening Vendor Support

The amount of vendor support for ROS-Industrial could make or break the program. Interfaces implemented by the vendors are likely to be far superior to those implemented by outside developers, both in robustness and level of access. A key aspect of ROS-Industrial is that it provide a standard ROS interface for industrial robot platforms. This removes the current vendor lock-in that exists with robot manufacturers.

Fall 2012

Dynamic and/or dependent joint limits

Joint limits should be dynamic. Festooning limits are a typical example of the need for dynamic joint limits. Due to festooning constraints, joint limits are reduced from the hard limits. If fixed limits are used, then much of the workspace of the robot can be lost. Often times, the joint limits due to festooning can be based upon the current robot pose, resulting in less restrictive joint limits when compared to static limits.

Not Started

Task Level Interactive Motion Planning

Basic automatic path generation for surfaces and/or curved lines (i.e. automatic rastering over flat planes or cylindrical surfaces, weld joint following). This would be a super set to the idea of waypoints. It would give meaning to the abstract command: paint this wall or weld this pipe joint . If you provided functionality for surface approximations, maybe second-order parametric surfaces, the user could break up any surface into a set of solvable approximate surfaces (similar to FEA). This would be nice for painting, washing, sand blasting, etc.

Not Started

PLC Drivers

The vision of ROS-Industrial is as a cell level controller, a task typically performed by a PLC. Initially most people won't be comfortable with this architecture and will require the ROS controlled robot to be a slave to a cell level PLC. In such a case a ROS-Bridge to the PLC (perhaps over OPC) will be required. Even in applications where ROS is the cell level controller, access to a slave PLC may be required, so the development of a PLC interface will still be useful

Not Started

Tf Simplification

ROS' tf (transform) capability is very powerful. It provides the ability to dynamic define and query any arbitrary transform. The flexibility of tf is likely to confuse most robot integrators who are more used to a fixed set of coordinate systems (base, tool(s), objects(s)). A ROS-Industrial library that wrapped the tf library and provided for the most common coordinate systems in industrial applications would make the tf system easy to understand (even thought it might limit its flexibility). Advanced users would always have the option to use the tf functionality directly

Not Started

Teach By Example

A key barrier to the introduction of robotic automation into small and medium size manufacturers is the need for engineering support. In the case of low volume, dynamic manufacturing environments the engineering required in order to adapt or change to manufacturing needs is cost prohibitive. In order to overcome this hurdle, robot automation interfaces need to be simplified to the level of a factory technician. This requires removing the need for any code development and limiting the amount of configuration that must be done. Ideally, a type of task could be demonstrated for the robot and the robot would understand and be able to replicate the task. While in general, this may be very difficult, for a small subset of tasks this is achievable. A project is envisioned where a robotic system could perform part kitting at a generic level. The specific kitting task is demonstrated to the robot. The robot analyses the demonstration (probably as a set of kit states ) and then applies an abstract kitting program to accomplish the task.

Not Started

Workcell Calibration

There are several calibrations that are required for an industrial robot workcell. These may include the calibration of a tool point, the position of fixturing, or the location of a an external sensor. There are two current approaches to this problem. The first approach is an all in one calibration similar to how the PR2 is calibrated(see here for a possible solution. The all in one approach is best for a usability standpoint, but sometimes fails to find all the desired calibrations. The second approach is to perform each calibration independently. The best supported calibration is robot to sensor transform calibration. There are two known libraries. The first library is the turtlebot arm calibration library. While it was developed for the turtlebot, it is generic enough to be applied to any robot/camera combination. The general procedure requires a checkerboard placed in front of the sensor and then the robot touches off the four corners. The robot FK is used to determine the corner locations in the robot frame. The transform is then calculated to the camera frame. NOTE: The wiki page has the incorrect repo location (>fuerte). The correct page is on githubhere. A second approach is a little more user friendly. The second approach attaches a checkerboard to the robot end-effector and moves it around in the robot frame. See here for the code. There is some clean up to be done on both packages, but ultimately, the best calibration routine should be chosen. The performance of each calibration routine is not known.

Needs cleanup/refactoring