Week-5

Block Library Extension

VisualCircuit consisted of a few driver blocks from OpenCV such as edge detector, color filter etc. For programming robotics apllications, new block were required to be added to the tool to program program robotic behaviors. These blocks connect to ROS topics and make further processing on them. These blocks consisted of:

• Odometer
• PID Controller
• Motor Driver
• ROS Camera
• ROS Laser Sensor

Link to Issue and Pull Request

ROS Based Communication

I was working on connecting ROS to VisualCircuit and I realized something. Our current wire implementation was basically a structure which looks like this (for a 3 dimensional image):

class MD(Structure):
    _fields_ = [
        ('shape_0', c_int32),
        ('shape_1', c_int32),
        ('shape_2', c_int32),
        ('size', c_int64),
        ('count', c_int64)
    ]

For every type of data, we will need a separate “MD” class and modify the wire class accordingly to deserialize the buffer, like this: np.ndarray(shape=(md.shape_0, md.shape_1, md.shape_2), dtype=’uint8’, buffer=self.shm_buf)

Now in ROS, we have different ‘message’ types. Some examples would be:

‘Pose’ type message: float32 x float32 y float32 theta float32 linear_velocity float32 angular_velocity

‘Twist’ type message (cmd_vel): Vector3 linear Vector3 angular

As every message has a different size, dimensions and type, we would need to create a lot of ‘MD’ structures and modify the Wire class accordingly. I think this will be difficult for someone new to understand as well as develop. I also think it will greatly increase the complexity of the tool. I thought of a new implementation which I will describe below.

New Wire Design:

As ROS already has multiple built in message types and their corresponding serializers and deserializers. It would save a lot of time if we reuse them instead of creating multiple “MD” structures for each message type.

To achieve this I will need to make changes to current wire implementation. We will use ROS Topics instead of POSIX_IPC to communicate between blocks. Two blocks that need to communicate with each other will have a unique identifier which is common among both of them (Wire ID). Now one block will create a ROS Topic with the “Wire ID” as its name and start publishing (writing) messages to it. As the other block also has the Wire ID, it will Subscribe to that ROS Topic and start reading data. So, a ROS Topic is basically acting like a ‘Wire’ now. Also multiple subscribers can read at the same time preventing any race conditions.

This also has an extra benefit as ROS messages can be accessed through “.” operator, just like a class. For example, Pose.x will give me the x coordinate for the robot. While in POSIX_IPC we need to maintain sequence of the array and read accordingly, which is difficult.

The only downside is, POSIX_IPC is faster as compared to ROS communication. But I think ROS communication is fairly fast and won’t affect our performance.

Link to Issue and Pull Request

ROS+Gazebo based Application using VisualCircuit

The next step after creating multiple blocks for ROS was to create an ROS and Gazebo based application using VisualCircuit. As VisualCircuit currently runs on Python 3.8 and no ROS distribition except for Noetic provided support for Python3, so I had to go with Noetic-devel for development. I was supposed to pick a simple robot and program it but I could not accomplish the task within this week. This was because Noetic-devel was new and had no available robots for use or they had issues working properly. I tried Pioneer2dx, Turtlebot3 and a few others but all seemed to have some sort of issue or incompatibility due to being ported from previous distributions of ROS. This task was postponed until a custom robot was added to the JdeRobot custom robots repository.