This week I did a revision of VO node code to try to improve the running times of last week. This is a hard process but if we intend to use this program to detect collision in real time it is needed, since we need the result promptly and the delay mentioned before can put the Atlascar in risk of collision. I altered a few things in the code, related to the markers and the collision topic to improve the code. In the end I did another few tests to determine how the node behaves. I realised that, as expected the code starts to bottleneck when the number of targets is higher than approximatly 24. The code takes an average of 0.01 seconds to process each target's calculations and after a few tweaks it took an average of 0.137 seconds while displaying all the markers. With the marker display restrition metioned last week it took an average of 0.04 seconds. Althoug these numbers seem good, performance wise, they relate to the average running time and when a higher number of markers are needed to be displayed the code runs really slow and then it can't keep up. It is important to notice that these numbers are related to this specific bagfile and it may not be a good representation in other cases where multiple targets can be detected. There are too many factors that may cause even more delays in the code, such as speed of the Atlascar and/or its surronding objects, LIDAR range, surronding enviornment, and more. Afterall this was just a beta test of the code performance and in the future many more test will be needed.
I also took in consideration the case mentioned last week where some of the targets' points could be closer to the Atlascar than it's centroid. So to counter this I added to the Target message topic, published by the GNN, the minimum distance of each detected target. I also calcuted the maximum distance and the maximum and minimum angle of the points of each target, however I didn't include them in the message topic since I am not needing them now.
After an email exchange with Professor Jorge Almeida, he alerted me about some possible errors in the velocity information published by the GNN related to the Atlascar egomotion. This was unexpected and made me rethink the velocity aspect of VO node, since it heavely depends on this information. He stated that due to the Atlascar egomotion the target's velocity will be affected with a false sense of movement that would cause false information. Luckily he already did some work in this subject and I found some of his packages in the lar toolkit so I started looking into his code to try to understand how can I use in my work. My fears of code bottleneck started to appear again, since by adding another node to the project it can reduced performance even further.