Last week I worked on reducing the number of targets detected by the GNN, and even though the number of targets were reduced I knew I could improve it even further, so I started this week continuing to work on this issue. In my first attempt I reduced the number of targets by removing them from the initial list of objects detected, if it's number of points was less than 5, however by doing this I was removing information about the detection part of the code, and not the association part. So I decided it was best to keep the information of all the detected objects, but only associate that object to a target if it met the requirements. I also made these requirements more easy to set and tweak, by instead of hard coding them (setting them directly into the source code), specify them in the GNN parameters yaml page. This yaml page was already used by the GNN code to specify some parameters such as the clustering distance (maximum distance between two consecutive points of the same target), the maximum missing iterations, etc. Before, I've only specified the minimum number of points to be a target, but this could mean that an object may have a lot of points but still be very small and not a major risk for the car, so I added a minimum size of an object requirement. In end the number of erased targets was close to 30 in some cases, wich made the visual information much more easy to read (Fig 1)
With the reduced amount of targets displayed on Rviz, the screen was much cleaner and allowed me to detect that the line representation of the targets was not following the points (Fig 2), meaning that the information about these points was not being updated by the GNN. This was a real issue because if this information was not up to date, the initialpose and finalpose data published by the GNN wasn't either, so the velocity obstacle code wasn't correct as well. So I needed to fix this issue in order to continue on with my work. After this issue being fixed I noticed a small decrease on the program performance while running (wich was expected) that got me worried about the possible bottleneck when running the code while the sensor is moving, due to the rapid change of the targets position.
The velocity cone representation was the big objective for this week, so after finishing the GNN problems I started working on the VO python code. I already had the circle representation in the GNN code but I decided it was best to do this in the VO code, since I don't see how usefull it is for the GNN, I also transfered the radius calculation to VO for the same reasons. To do the Velocity Cone I first need to approximate the target to a circle, and this is was already my first issue. I initially thought about setting the circle radius as the distance between the last (or first) point and the center of the target, wich is given by the GNN. However this solution resulted in some issues, mainly because the center point given by the GNN is the predicted center point of the target, wich moves quite a bit, and when the target can't find it's object he starts woundering around looking for it and the circle keeps increasing resulting in wrong information. Then I set the diameter of the circle as the distance between the first and the last point of the target, but still centering the circle in the center point given by the GNN. I'm currently using this option but I'm still woundering if it's the best solution. I've done a lot of research on this matter, but I've only found articles realted to 3D objects and since I'm only working with mainly 2D lines this approximation is very difficult to grasp. I wounder if I calculate the target's convex hull area I can equalize it to the area of a circle and retrieve it's radius, being that the target is not a line. I need to done some more research.
After representing the target by a circle I then need to add the ATLASCAR's approximated circle radius to the target's radius, and this is were things got worse. I calculated the ATLASCAR radius using the distance from its center to one of its vertices but when adding this to the targets radiuses the target's velocity circle fill the entire RViz, wich means that there's no way that the ATLASCAR can move without coliding. Since this bagfile was not made by me, I can't confirm that this is true but it sure points out that something is wrong, probably with the circle approximation.
This week was very important to see the issues I'm going to face in the final stretch of this Thesis, and it finally allowed me to see clearly the usage of Velocity obstacles. Now I need to dig deeper in the research to find an answer to the approximation circle issue. It showed me as well how important it is to refine the data as we can see in the difference between the two velocity circle images
