This week some final touches to VO node were made. To tackle the issue of the visual lag on the representation of the Collision Cones I decided to try a few other options on the representation method. I first thought that the lag was due to the update and remove functions which deleted the outdated colliding target's cones. To run these functions a list of all the target's ids was made and then iterated through to check if the respective cone was to be deleted. Since in periods of high numbers of targets this list could be up to 40 ids, I thought the delay was due to the iteration. So this time I altered the update method and used a marker lifetime of 0.5 seconds. This means that if a previous colliding target is no longer a risk, after 0.5 seconds its cone is deleted and if it stil is, the cone is remade. Since the process of remaking the markers is not very time consuming this method should be faster than the previous.
However, after reviewing the data the lag was still present. I started looking around for potential causes, and then altered the queue size of either the subscribing topic and the publisher topic. The queue size is a variable that determines how many message is to be kept in cases the code is experiencing a bottleneck, keeping in mind that ROS uses the FIFO method (First in First Out). By changing the queue size of the markers publisher the problem was still there, which meant that the delay was not due to Rviz lag. By changing the GNNs subscriber queue size to 1 the problem was gone, the Rviz was displaying the cones without any lag. Altering the queue size meant that some GNN messages were disregarded and some targets were probably missed, eventhough only the latest targets were accounted for.
The fact that the lag issue is due to the subscribing part of code and the messages received are a list of multiple targets can possibly mean that the node is not keeping up the amount of information (most likely), or ROS buffer cannot deal with such amount of data at that rate. Simmilar cases were found online when ROS is streaming big messages and lag occured. By "measuring" the size of the message at either end (GNN and VO) these numbers were not consistent, so no conclusion was possible.
In the end the lag was gone and by visually displaying the data (printing the data at 50hz) it appears that only a few messages were discarded in cases of high target "traffic". Some quantitative measurements must be made.
Some adjustements were also made on the Short Term Path node. Since most drivers hardly keep the steering wheel exactly at 0 degrees, the representation seemed fluid, however at first the path was only displayed when the steering wheel was at a value different than 0 degrees, due to mathematical indefenitions (divided by zero) in the trignometric equations used. So I added conditional statements to still display the path while driving straigh forward.
I also added the velocity vector of the car to Rviz representation in the front of the car. However this vector, mathematically speaking, is an approximation. The velocity perceived by the car is based on the wheel turns of the driving axle, so since this axle is at the back and all the points of the car travel at different velocities while turning, it results in minor diferences. This velocity is an approximate measurement of the car's ego-motion and could possibly be used latter on to determine the targets real velocity.
In order to use some the calculated properties I created a topic with the following information:
- Direction (left, right, forward)
- Outer Wheel Angle
- Inner Wheel Angle
- Center Angle
- Velocity vector (linear and angular)
- Turning center point
- Turning center distance