@destogl @mrobinson
I think it would be valuable to explain what I am hoping to achieve with my participation in this wg. I will try to be concise…
Background:
I develop Robot Raconteur (GitHub - robotraconteur/robotraconteur: A communication framework for robotics and the Internet of Things, developed by Wason Technology, LLC), an augmented object-oriented middleware, and PyRI Open Source Teach Pendant, a Python, browser based teach pendant (GitHub - pyri-project/pyri-core: Python Restricted Industrial (PyRI) Open Source Teach Pendant Core Package). These projects can be used with ROS, but they are often used standalone. Robot Raconteur began when I was a graduate student at Rensselaer Polytechnic Institute in 2010, and I have been continuing to develop it since then. Over the last few years RPI and I have received funding from the USA ARM Institute and New York State, with support from SwRI, GE, and Raytheon. Video on Robot Raconteur: Plug-n-play robot software coordinating robots and sensor from multiple vendors. - YouTube . The PyRI teach pendant began recently as another ARM project supported by the same team.
Robot Raconteur has a number of significant advantages over RMW, the biggest one being its plug-and-play capability. The full description of the plug and play capability is out of scope, but can be discussed elsewhere if people are interested. One important component to the plug-and-play capability is the standardized interfaces for hardware devices that were developed during the ARM project. These standardized interfaces can be found here: robotraconteur_standard_robdef/group1 at master · robotraconteur/robotraconteur_standard_robdef · GitHub . The most important one for this discussion is the robot standard interface: robotraconteur_standard_robdef/com.robotraconteur.robotics.robot.robdef at master · robotraconteur/robotraconteur_standard_robdef · GitHub . We had a number of different drivers already developed before the ARM project, but not standardized, so during the project we improved existing drivers and developed a few additional ones to conform to the standard. Unfortunately COVID hit at a bad time, so not all of the drivers were completed. A list of different available components: GitHub - robotraconteur/robotraconteur-directory: Directory of device drivers, applications, utilities, examples, and documentation projects for Robot Raconteur . One of the more interesting repositories contains a Gazebo based training simulator to interact with a few standard robots: GitHub - robotraconteur-contrib/robotraconteur_training_sim (at the time of this post there is a problem with the conda install, we are working on it…)
The PyRI teach pendant builds on top of these standard interfaces, and can control any standard robot and standard camera. We are working on expanding capability over time. A video on the teach pendant: Open Source Teach Pendant Jog, Save, Playback - YouTube
Robot Raconteur and PyRI can be used in the ROS ecosystem, and I am currently working on including them in the ROS package repository. The core Robot Raconteur package has already been accepted into Noetic, and over the next few months I will continue to work to have the components include in ROS 2 distros.
Objective:
Feedback from industrial partners is they are looking for functionally safe components going forward. The drivers I currently have are not functionally safe or hard real-time. My plan is to begin work on drivers written in C, able to be embedded in kernel-mode or RTOS, and be functionally safe. My goal is not to have them certified immediately, but to develop them in a way that they can be certified over time.
@mrobinson mentioned that it would be worth combining efforts, since developing and maintaining these backends can be challenging and time consuming. If these drivers are written in a modular way, then I will be able to use them and contribute to the development.
@destogl unfortunately I haven’t been able to use ROS control because it doesn’t separate the lower level libraries from the communication layer, so I haven’t done much work with the project.
I have very limited knowledge of functional safety, so I will be learning as needed. This development effort is a medium-term project.
I am also interested in the standardized interfaces for use with the PyRI teach pendant. Right now we have been using proxy drivers to communicate with ROS devices, since each device has its own message interface. For instance, the Rethink Sawyer robot driver wraps the ROS communication and translates from the standardized RR interface to ROS topics: SawyerRobotRaconteurDriver/SawyerRobot.cs at master · robotraconteur-contrib/SawyerRobotRaconteurDriver · GitHub . It would be very helpful if ROS drivers all had the same interface so we didn’t need to maintain individual proxy drivers for each device.
The standard interfaces we have developed may be useful for the developing standardized ROS interfaces. We did reference ROS message types when developing these interfaces, but they are not identical.
