Brainstorm intermediate layer representations

[Zelberor]

Detailed Description

Brainstorm and compare intermediate layer representations.

Base and research for #486

Definition of Done

Documentation exists about:

• Possible representations (including how and what data can be saved)
  • Persistent entity tracking (Ideas blow)?
  • What attributes have to be tracked:
    • static vs. dynamic| permanent vs. temporal
    • Type/Class
    • Motion
• How perception is supposed to insert data into representations
  • Based on what data
  • How we can make sure that algorithms working with the data are reliable (Data Deduplication?)
• How the other parts of the applications are supposed to use the representation and meet their goals.
• Discuss with other Teams how usable the resulting interfaces are
• Flowchart? Simulator scenarios where the representation might improve the situation (with rough application flow)
• Explore visualization options
• Depending on all above: Time/Work estimates and time to minimum viable product (MVP)

Effort Estimate

Open end

Testability

No response

Dependencies

No response

[ll7]

One of the screenshots I added to discord came from #389

[SirMDA]

https://de.mathworks.com/help/fusion/examples.html?category=lidar-tracking&s_tid=CRUX_topnav

Zwei Gedanken: Unser aktueller Ansatz würde darauf beruhen, dass wir die Bild-Segmentierungen mit den Lidar-Daten (depth_array) verschmelzen und uns hieraus dann die Objekte und 3D-Boxen der Autos erstellen. Im obigen Link gibt es einige Beispiele, hier wäre in meinen Augen auch sinnvoll zu prüfen, ob wir die Kamera-Daten überhaupt benötigen, denn hier wird gezeigt, dass dies auch rein mit Lidar-Daten möglich wäre. Für die Spur-Erkennung werden wir wohl nicht an den Kameradaten vorbeikommen aber für Autos, Fußgänger, Fahrradfahrer würde das glaube ich reichen. Hier ist dann auch der Vorteil, dass wir keine extra Kameras brauchen. Die vordere Kamera würde dann nicht mehr für die Objekt / Hinderniserkennung, sondern für Spurhalten, Schilder, Ampeln etc. verwendet werden und die Lidar-Daten, die wir aktuell bereits haben könnten uns dann problemlos alle Objekte 360° um das Auto geben.

Zweiter Gedanke ist bezüglich den Boxen. Wenn wir nur links und rechts die Segmentierungsdaten mit den Tiefen vergleichen werden wir einen Punkt, und zwar die Ecke des Objektes, das am nächsten zu uns steht, vernachlässigen. Eine Idee um dies nicht zu vernachlässigen wäre folgende: Da wir nicht sicher sein können, dass an den Rändern evtl. die Segmentierungsmaske nicht passt müssen wir jeweils mehrere Punkte verwenden um eine Region zu mitteln (das gilt generell, ob für den zwei Punkt oder drei Punkt Ansatz). Evtl. auch mit einer anderen, eleganteren Methode als Mitteln. Hier brauchen wir dann 6 Punkte: Links oben, Links unten, nähester Punkt zu uns oben, nähester Punkt zu uns unten, Rechts oben, Rechts unten.
Ob wir dann alle zur Weiterverarbeitung verwenden sei dahingestellt. Links wird ein Eckpunkt, der nächste Punkt zu uns wird ein Eckpunkt und Rechts wird ein Eckpunkt. Hier hätten wir dann drei Eckpunkte. Wenn wir hier noch den overall niedrigsten Punkt als "Boden" nehmen und den overall höchsten Punkt als "Deckel" der Box könnten wir uns dann damit eine Box in den Raum projizieren. Den vierten Punkt kann man mithilfe der anderen drei Punkte problemlos berechnen. - Problem bei diesem Ansatz ist, dass wir mit drei Punkten evtl. keine Quadrate, sondern evtl. Parallelogramme. Dies würde bei zwei Punkten nicht passieren, wenn wir uns damit die anderen zwei Eckpunkte berechnen würden. Es könnte allerdings sein, dass wir hier dann eben die näheste Ecke zu uns nicht korrekt bestimmen, obwohl wir eigentlich die Informationen hierzu hätten.

[RoyaLxPole]

Zum Thema Lane Detection: Es wäre an sich möglich die Lidar daten zu nehmen um die Erkennung von den Spuren zu machen, jedoch sind die besten und stabilsten Modelle momentan auf Kameradaten angewiesen, mir ist ein Paper zu dem Thema aufgefallen, das ein Selfsupervised learning Model verwendet, aber das war eher eine Kombination aus 6 Kameras, 5 Radaren und 1 Lidar, was meiner Meinung nach die Grenze der zugelassenen Sensoren für das Qualify überschreitet zudem enorm viel Kapazität der VRAM für die Berechnung braucht und zudem auch sehr langsam ist wegen der enormen Menge an Daten.

[Zelberor]

Draft for the map/intermediate layer can be found here

Still a work in progress but feedback is very appreciated

[ll7]

I think you have designed a great draft.

Before you start your implementation, I recommend conducting ROS-specific research to identify elements that could enhance your architecture. This doesn't mean you should use only existing ROS Noetic features, but they can provide helpful inspiration, and you might find pre-existing solutions.

Examples

• ROS Perception includes object message definitions: vision_msgs
  • Detection2D.msg
  • These messages can include probabilities: ObjectHypothesis.msg
• There are ROS message definitions that publish a local map of probabilities: OccupancyGrid
• Transforming coordinate systems is very common in robotics; have a look at TF2.
• Plan to use the ROS parameter server for all kinds of parameters.

Try to find 2 or 3 team members for feedback because design decisions now are critical.

[vinzenzm]

Props to you for the detailed investigation into the topic. There is loads of information in the Document provided. I suggest to start a similar draw.io project as to our mindmap in order to efficiently communicate the map representation as a UML-class diagram and the data flow chart as a modifieable entity.

One aspect I couldn't find in the document was, that there is currently no Entity in the definition which could represent lane markings. Maybe there should be some sort of Line entity, this could also get used for e.g. the merging of Lidar points, or for entities of which we don't know the depth (row of houses, a wall etc).
Also considering Traffic lights maybe there needs to be some sort of entity state. Which in the case of traffic lights might be red/green/yellow. But for a car this might be brake lights on, right indicator etc.

Regarding TF2: Using tf2 has a big advantage in my opinion:
The usual implementation of a tf2 listener uses a Buffer. It is therefore possible to look into the past and track frames over time. This is also quite efficient because no global graph has to exist. Rather the combined information of multiple broadcasted messages represents the current state. I recommend reading this TF2 Design
However:
There is no possibility to add additional information to the TransformStamped.msg which are passed in the tf-Graph.

Considering this, a very important aspect is to find a suitable ROS-like way to propagate the information to users of the map. A service like structure (users can query the information at a mapping server) is probably sufficient if there is a limited amount of users. A purely topic based system would require the user to store the data and use it when necessary, which could result in outdated data. A tf2 like buffering system sound promising but is probably tough to implement.
Probably there are more possible solutions I didn't even consider yet.

As mentioned in the beginning there is probably already more information in the document than can be discussed in comments on this Issue. Feel free to arrange a meeting with interested members to further discuss entity structures, map propagation etc.

[Zelberor]

Thanks for reading and for the feedback of the draft. For further discussion I will be available on Monday from 13:00 until 15:30.

I agree that a lot of stuff still has to be worked out until we can start the implementation.