Week-6
Week-6
TurtleSim ROS Demo:
This demo required connection of blocks through ROS topics. Each of these blocks connect to a ROS Topic and it either publishes or subcribes to a topic, then it does further processing on the data and publishes it to another ROS topic for the other block to read. For the TurtleSim demo, 3 blocks were required:
- Motor Driver
- Odometer
- PID Controller
New Wire(Message) Type:
On the ROS-based communiation, I got the following feedback from my mentor:
“The idea is good and it is already in the roadmap for VisualCircuit, but after GSoC. I mean, for now we have enough exploring the new hardware approach of “programming” robot intelligence (just like a circuit) and playing with it for increasingly complex behaviors (PID, FSM, deeplearning based perception…) with robots. We have many things ahead to learn with it. With more experiences using VisualCircuit we will gain deeper understanding about its advantages and limitations when programming robot behaviors this way.
The ROS exploration is just intended as you are proposing, just using it for the wires and even using the new communications in ROS2 (using DDS…). There are more communication paradigms, such as ROS services which also deserve more careful study and maybe do not fit with the VisualCircuit philosophy. ROS wires also open the door to even remote blocks inside a circuit. I think it is better to stick for now to local blocks and fast wires, as they may be a better approximation to real circuits. Shared memory may be seen as a 1-buffer message communication, ROS wires may have buffers…
In addition, we will not support the whole set of available ROS messages. We will focus for now on a bounded set: basic sensors and actuators messages (cameras, laser, odometry, speed commands, etc).
In summary I would stick to current POSIX_IPC shared memory wire design. And we may face the ROS wire’s design once we got far more experience using VisualCircuit with real behaviors, after GSoC.”
After the feedback and discussion, it was decided that as the ROS-based communication implementation is already done. We will keep it in VisualCircuit if someone needs to use it. For now we needed to create a new wire implementation which supported multiple ROS message types. For each message type a new wire would be required which would increase the complexity of the tool. So, I came up with a generic wire implementation which basically accepts a numpy array of ‘<U6’ type strings. In this way the common ROS messages we need to support can be sent by using just this one wire.
Link to Issue and Pull Request
TurlteSim Demo Shared Memory:
The ROS based turtlesim demo was converted to the VisualCircuit wire implementation using the new wire type. Instead of communicating to ROS topics, only some of the “driver” blocks connected to ROS topics while the other exchange of data was done locally through VisualCircuit wires. The main reason for this was to get a better estimation of execution time of each block and faster processing times.
Changing extension from .ice to .vc:
The icestudio projects are blocks needed to be converted to visualcircuit ones. The extension was to be changed from .ice to .vc.
Sample Blocks:
Some sample block were created which provides a base if someone wants to create new blocks in the future.