Week 4: Coding Period

This week marked a focus on completing the remaining PRs from last week. I also finished adding a new IMU block and worked on general share() and read() functions.

IMU Block

An IMU (Inertial Measurement Unit) is a sensor commonly found in drones that detects the orientation and the angular velocities of the robot.

It is essential for writing our own control systems for drones. I started the work on the block. For testing how it worked I used the visual_lander simulation. Since mavros already has an inbuilt IMU in its models. Constructing the block template was just about reading the processing the data already gotten in an appropriate manner.

IMU Block

The code is as follows:

import numpy as np
import rospy
from sensor_msgs.msg import Imu
from tf.transformations import euler_from_quaternion

data = []

def callback(msg):
    global data
    # Get the orientation list from the IMU sensor
    orientation_list = [msg.orientation.x,msg.orientation.y,msg.orientation.z,msg.orientation.w]
    # Convert orientation obtainted into values of roll, pitch and yaw
    (roll,pitch,yaw) = euler_from_quaternion(orientation_list)
    # Convert val;ues in Radians to Degrees
    roll = roll * (180/3.14159265)
    pitch = pitch * (180/3.14159265)
    yaw = yaw * (180/3.14159265)
    # Obtain Angular Velocities from IMU sensor
    angVel_x = msg.angular_velocity.x
    angVel_y = msg.angular_velocity.y
    angVel_z = msg.angular_velocity.z
    # Store all this data in 'data' variable for use in main function
    data = [roll, pitch, yaw, angVel_x, angVel_y, angVel_z]
    # ----- Lines only for demo purpose -----
    rospy.loginfo("Orientation\nRoll = {0}\nPitch = {1}\nYaw = {2}\n".format(roll,pitch,yaw)) # These are not included in the block's code
    rospy.loginfo("Angular Velocities\nWx = {0}\nWy = {1}\nWz = {2}\n".format(angVel_x,angVel_y,angVel_z)) # These are not included in the block's code

def main(inputs, outputs, parameters, synchronise):
    global data 
    auto_enable = False
        enable = inputs.read_number('Enable')
    except Exception:
        auto_enable = True

    rostopic_name = parameters.read_string("ROSTopic")
    rospy.Subscriber(rostopic_name, Imu, callback)

    while ((auto_enable or inputs.read_number('Enable')) and not rospy.is_shutdown()):
        if not data:

        outputs.share_array("Out", data)

And the output:

IMU Output

General Share and Read

The other major task done this week was creating a general read and share function. Before this in Visual Circuit we had separate functions to share the output of blocks.

For e.g. in order to share an image we had to write share_image(...), similarly for an array share_array(...) and on the other end to read then we had to include specific functions such as read_image(...) and read_array(...) as well.

This was something that could be improved to make it simpler for the users. The reason this was done separately was that while sharing something we have its data type, hence it can be general purpose, however while reading it we don’t know what kind of data type we’ll be getting hence the need for specific functions. We need the exact data type while reading because when the Shared Memory Buffer is read it is specific for the supplied data type.

The solution was creating a new buffer that contains the type of the data being supplied. Since numpy had data type strings of type "<i8", "<U6" etc. We simply make a new object to store the data type of whatever data is being supplied, since this data is always stored in a String format it is known how to decode it on the read end. Then once we have the data type we can use it to decode the actual data.

This solution had a few bugs in it as well namely what would happen when the data type changed? This was an issue especially with the string data types. Usually numpy gives a data type of "<U1" to a string that has only one character. However even when the number of characters increases, as this data type doesn’t change we can only read one character.

There were again two approaches I tried to fix this issue:

  1. Simply allocating a larger buffer by default to the data types
  2. Overwriting the buffer whenever the data type changed

After discussing with my mentors, we decided to go with approach no. 1 as it was faster than the second one.


No new issues were raised this week.

Pull Requests


Summary Report

4 minute read

Late nights, excitement and learning are how I would describe the GSoC period in a few words. These past two months have been a lot of fun, from starting off...

Week 11: Coding Period

1 minute read

Going by the suggestions of my mentors, I spent this week working on the documentation of the blocks and some updates to my blog.

Week 10: Coding Period

1 minute read

This week I looked into MultiProcessing Conditions and finished the video of the FSM.

Week 9: Coding Period

1 minute read

This week saw the completion of the FSM video and the solution to the block size bug.

Week 8: Coding Period

1 minute read

I made more progress with the documentation and some other auxillary bug fixes this week.

Week 7: Coding Period

1 minute read

Another pretty busy week for me personally. This led to a bit of slowdown in the work done. However I started with the documentation editing through Jinja an...

Week 6: Coding Period

2 minute read

This week was quite hectic for me. My college started offline after a while, due to travelling and a few other events the time I could spend on Visual Circui...

Week 5: Coding Period

1 minute read

This was a week where I started to work on the Finite State Machine that I had mentioned in my proposal.

Week 4: Coding Period

3 minute read

This week marked a focus on completing the remaining PRs from last week. I also finished adding a new IMU block and worked on general share() and read() func...

Week 3: Coding Period

2 minute read

This week I finally finished the remaining templates from last week. I also managed to upload my created videos to the JdeRobot YouTube Channel.

Week 2: Coding Period

1 minute read

This week was about identifying and solving some bugs I had noticed during usage of the tool. I also started with the work template updation.

Week 1: Coding Period

1 minute read

This week marked the official beginning of the coding period. Going by last week’s set goals I started on the video creation part first and foremost.

Week 3: Community Bonding

less than 1 minute read

This was the last week of community bonding, however due to other commitments in college I had a hard time working on Visual Circuit.

Week 2: Community Bonding

1 minute read

In my previous posts I had highlighted the challenges I faced while installing Jde Drones and getting code running on it. Next after these steps was to solve...

Getting Code Running on Drones

1 minute read

After I got the drones running now it was time to actually write the code to solve some exercises. The goal for this week of the GSoC period was to get 1-2 a...

Installing JDE Drones

2 minute read

Getting started with my GSoC period, one of my goals during the project was to make drone applications using Visual Circuit. JdeRobot’s Academy already has s...

Back to Top ↑