Research Layer

 

The first software layer is where an end user programs their own code—for manipulation, navigation, computer vision, machine learning or some other application. For example, all the ROS packages and Python scripts within the interbotix_XXXX_examples directory (which exist in the repositories that build on top of this one) could be described as 'application' layer code.

​

Application Support Layer

 

The second software layer is optional and only exists to provide Python modules or 'support-level' ROS packages to make it easier for a researcher to work with the robot on a higher level. The main home for this type of code is in the interbotix_ros_toolboxes repository. For example, this is where all the Python modules used to control any of the robots (like inverse kinematics solvers, gripper controllers, hexapod walking-gait pattern generators, etc...) that build up from this repo live. That said, miscellaneous ROS packages like AR-tag detectors, 3D object pose estimators and similar that sits between a sensor's ROS wrapper and the final application could be said to live here as well.

​

Control Layer

 

The third software layer is a ROS package that exists for every genre of robot platform sold at Interbotix and lives in the various repos that build up from this one. It follows the naming convention interbotix_XXXXX_control, where XXXXX is replaced with the name of the robot platform. For example, in the X-Series Arms directory located in the interbotix_ros_manipulators repo, we have the interbotix_xsarm_control ROS package. This can be understood as the ROS package that allows a user to easily control/configure any of the many X-Series arms that we sell. The two main components of the package are the 'config' directory and the launch file. The 'config' directory stores YAML files that describe the parameters for all the actuators and sensors in the robot. The launch file is then responsible for passing those parameters to all the actuators/sensors in the robot and starting them up. In this manner, a ROS researcher only has to call one launch file to start a robot instead of multiple to start every actuator/sensor separately.

​

Driver Layer

​

The fourth software layer contains the ROS wrappers for actuators and sensors plugged into the computer. These wrappers provide ROS interfaces to set or get data to/from the physical actuators or sensors. It essentially abstracts away all the lower-level 'plumbing' code (like serial protocols, register addresses, etc...) so that it's easy for a ROS researcher to get started on their project. As shown in the diagram, the interbotix_ros_core repo falls in this layer. However, third-party actuators or sensor ROS-wrappers (ex., around the Kobuki platform or RealSense camera devices) also fall in this layer.

​

Hardware Layer

 

This describes the physical setup of the robot - specifically, what actuators and/or sensors are plugged into the robot computer. The computer could be an Intel NUC, laptop, Raspberry Pi, or something else - as long as it's capable of running ROS. Below the 'Robot Computer' (on the left side) are the actuator interface, controller, or driver boards, followed by the physical motors. This could be a U2D2 or Arbotix board that controls Dynamixel servos or an Arduino that controls a motor driver that drives some hobby servos. Below the 'Robot Computer' (on the right side) are the sensor devices. This could be an Arduino hooked up to some force-sensing resistors, switches, potentiometers, or a RealSense camera.