watonomous.github.io

1. Electrical Division
2. Electrical Division Home
3. Radar Driver Group

[ Electrical Division : Software Architecture ]

Created by [ Frank Yan], last modified on Aug 30, 2020

---

Table of Contents

• Document Overview
• Current Set-Up
• Integration
• Main Tasks
• Nodes
  • Publisher
  • Processor
  • Multi-Radar
  • Visualizer
  • Transform

Document Overview

Everything the radar-driver group does is from scratch as Continental decided to delete all their driver code for the radars (no clue why). To better understand what is going on with the radar driver code this page will give a brief overview of how the driver code works. The individual nodes have their own pages and are accessible through this page. 

Current Set-Up

As of S20, this is how the software stack is built:

[{.confluence-embedded-image width=”1200”}]{.confluence-embedded-file-wrapper .confluence-embedded-manual-size}

Integration

So how does everything work? When the radars are first powered on the radars will send data via the Ethernet cables. However, in order to have the radars communicate with the car and/or your computer, there needs to be a way to receive whatever data the radars are picking up. The node responsible for this is the publisher. There is one for each radar and this node gets the raw data from the radars. This gets the network information, does the necessary bit-shifting to get the data, and converts the data to ROS messages. This node communicates all this information in a topic called unfiltered_radar_packet.

Now that we are able to get the radar's data and use it in ROS we can select what data we need. The processor node takes the information from the unfiltered_radar_packet topic and cleans up the raw radar data. Like the publisher node, there is one for each radar. The node first organizes the data into groups based on the timestamps of the data. After the data is organized, the node begins to filter out any points that do not meet the pre-defined thresholds. Once this is taken care of, the processor publishes the topic filtered_radar_packet to the next node.

The next node in the stack is the multi-radar. Even though the processor node does some filtering, the filtering it does is only for one radar. There is no way for the radars to communicate with each other and know of each other's existence. The multi-radar node sets up the multi-radar tagging system where the node can identify which radar is detecting objects. This is important for filtering and deleting duplicate points from the multi-radar set up. There is only one node for both radars because this node needs to get both topics from the left and right radars. [As of now this node is still in development and the process of deleting duplicate points is in progress. After more points are dropped, the multi-radar node publishes the final_radar_packet topic to the visualizer node.]

In order to visualize the data the radars are receiving, we need a visualizer. These nodes visualize each of the radar's data into a point-cloud and configures the FOV lines in RViz. It achieves this by converting the ROS messages to the point-cloud messages. It publishes the point-clouds and FOV lines for each radar.

Finally, the last nodes for the software stack are the transform nodes. The transform nodes are not connected because they do not rely on the other nodes and publish the transforms directly to RViz. What the transforms do is it offsets the point-cloud data in RViz to reflect the physical offset with the radars. This makes the visualization of the data more accurate and helps separate the data from each radar.

Main Tasks

Here are some of the main tasks that we need to do with our software architecture:

• Get data clean for perception
• Isolate people/objects
• Differentiate static/dynamic objects
• Get data with radar moving
• Look into EKF (Extended Kalman Filter)

Nodes

Click on the links to see the page to go into further detail about each node. A TLDR is provided for each node underneath the links.

Publisher

TLDR: Converts the raw radar data to ROS messages.

Processor

TLDR: Filter and clean up bad data.

Multi-Radar

TLDR: Multi-radar filtering and tagging.

Visualizer

TLDR: Radar points are seen in the point-cloud.

Transform

TLDR: Offset for the multi-radar.

\

Attachments:

RadarSoftwareArch.png (image/png)
RadarSoftArch.png (image/png)
RadarArch.png (image/png)
RadarArch.png (image/png)
RQTGraphS20Radar.png (image/png)\

Document generated by Confluence on Nov 28, 2021 22:40

Atlassian