watonomous.github.io

1. Software Division
2. Software Division Home

[ Software Division : Processing Group ]

Created by [ Rowan Dempster], last modified by [ Henry Wang] on Feb 04, 2020

The Processing module aggregates sensor data and object detections, and tries to make sense of it. The ultimate output is a representation of the vehicle’s local environment. In the software pipeline, Processing is downstream from Perception, and upstream from Path Planning. Historically, the work scope of this team has always been a little poorly defined, but for year 3, work can be divided into one of the following sub-groups.

• High Level Data Fusion (HLDF)
• HD Mapping
• Object Tracking

High Level Data Fusion

We have labeled 2-D data from the cameras and 3-D data from the Lidars. HLDF associates the two datas together to give the labeled 2-D data depth. Read more here https://phabricator.watonomous.ca/w/software/processing/high_level_data_fusion/
Currently, we are working on developing a projecting 2d bounding boxes frustum-style to more accurately match boxes together

Object Tracking

• tracks environment objects using a Kalman Filter. See more in the subdocument here Object Tracking

Architecture

Current architecture of Processing nodes:

[{.confluence-embedded-image .transparent .confluence-external-resource height=”400”}]{.confluence-embedded-file-wrapper .confluence-embedded-manual-size}

[See ]https://docs.google.com/document/d/1c8sCdKEe_kKQMHDMIkAjutLmgxDbqkL0cL3UqvJ-GoQ/edit#heading=h.2u9r9eu7awcy[ for a table of Processing inputs and outputs, and their message types.]

localization/preprocessing/lane_publisher_v1 is our hacky solution to fake lane lines. Essentially, this returns points from a text file (lane lines) and publishes it to the /processing/roadline_post_processing topic

Object Tracking consumes this topic, who then passes it straight to path planning as part of the environment message.

We have keep this so that our object tracking code is backwards compatible with lane_publisher_v1, in case we need to use that again in case the HD Maps do not work.

Planned Architecture

To be able to better handle lane lines, we need to create a new lane_fusion_node:

• hd_map_node: parses OSM, and publishes nearby lane lines in HD Map (without stitching)
• hldf_node: fuses all of perception's different outputs into 1 message (except for lane lines)
• lane_fusion_node: tracks perception lane lines with heuristics, then fuses perception lane lines and hd_map_node's lane lines into 1 set of lane lines, and 'stitches' these lane lines if needed (e.x. intersections)
• tracker_node: tracks objects output by perception, and sends these to Path planning along with lane lines in an Environment.msg

  • output of lane_tracking is not to be tracked by the kalman filter tracker

  • output of HLDF [is] to be tracked by the tracker

Flowchart regarding their connection:

[

Fields Needed by Path Planning

https://docs.google.com/document/d/1_pNYbSeX1zJcYIaId9WFv8xxEPnwmB7nM-dyL7_xc6s/edit

Processing should publish a path_planning/Environment.msg RosMsg to PP
The structure is basically the following nesting structure:

• Environment.msg
  • RoadLinesList.msg
    • LaneLine.msg

Stop lines should be put in the nested RoadLinesList.msg, and ignore the one in Environment.msg

Attachments:

Processing_planned.png (image/png)\

Document generated by Confluence on Dec 10, 2021 04:02

Atlassian