Autoware Architecture WG Meeting (perception/sensing) 2022/05/25

[mitsudome-r]

Participants

Chaired by Ryohsuke

Goal of this WG

• https://docs.google.com/presentation/d/1AhuCcScktgBwJreAjDspyf2OcKTNFbK-fFI1QT9NRLg/edit?usp=sharing
• Wiki: https://github.com/autowarefoundation/autoware-projects/wiki/Autoware-Architecture-Working-Group

Discussion Topics:

Review Prediction Interface Design

Reference:

• bag file to try autoware software-suites #3
• Current output of Prediciton:
  • PredictedObjects
  • Difference from Tracked Object is that it has predicted path in kinematic state

Discussion

• Should we used fixed interval for predicted path or should we have PoseStamped for each point in trajectory?
  • We think fixed interval is enough. It would just make planner node complex if we allow varying time_step in predicted path
• What does the confidence represent? Is it for confidence of trajectory as a whole, or is it for each position in predicted trajectory?
  • It's to represent confidence of the trajectory itself.
  • Reference: Waymo Motion Prediction Challenge data format
  • We should add description to the document/comment as message definition

Review Sensing Interface Design

• Reference:
  • bag file to try autoware software-suites #3
  • Radar: Update AutowareRoute #191
  • Lidar: Modified scan2image & calibration_test for calibration_publisher node #101
  • GNSS: Add sleep command to decrease CPU occupancy #233
  • TIER IV Architecture Proposal
    • GNSS might change
  • ROS2 sensor_msgs
• IMU: sensor_msgs/Imu
• Camera: sensor_msgs/Image + sensor_msgs/CameraInfo
• LiDAR: sensor_msgs/PointCloud2
  • Point Field contains: x, y, z, intensity, laser channel, time_stamp
• GNSS:
  • sensor_msgs/NavSatFix
  • sensor_msgs/Imu (optional)
  • geometry_msgs/Twist (optional)
• Radar:
  • ros-perception/radar_msgs/msg/RadarScan.msg for radar pointcloud
  • ros-perception/radar_msgs/msg/RadarTracks.msg for radar object.

Discussion

• Camera output: There is also CompressedImage or Image?
  • usb_camera outputs both of the message type
  • We have ROS default tool to convert between CompressedImage ↔ Image. If we use compressed image as common interface, we have to do decompression at all modules that use the message.
  • Do we want to consider encoding that is not supported by ROS2 by default?
    • If we want to support such encoding, we should make proposal to ROS2 message repository rather than defining original message in AWF.
    • Common neural network would take image as bgr (or other 8bit representation) so it might make more sense to stick with default encodings
• Do we support wheel encoder as sensor output?
  • Mitsudome: I think we can take it as vehicle velocity value as geometry_msgs/Twist rather than encoder ticks from each wheel.
• Lidar:
  • We still need to agree on pointfield definition
  • PointXYZI+LaserChannel+Time
  • Do we want to remove laser channel after preprocessing is done within sensor module?
    • We can still allow additional fields if required
• GNSS:
  • Fatih: from past experience, we should output position(lat/lon/alt) and orientation value as a single message rather than using a separate message.
  • Some of the messages that Fatih used include:
    • https://github.com/clearpathrobotics/applanix_driver/blob/hydro-devel/applanix_msgs/msg/NavigationSolution.msg
    • https://github.com/clearpathrobotics/applanix_driver/blob/hydro-devel/applanix_msgs/msg/NavigationPerformance.msg
    • https://github.com/SBG-Systems/sbg_ros_driver/blob/master/msg/SbgEkfEuler.msg
  • In TIER IV architecture proposal, we proposed to use geometry_msgs::Pose (and maybe twist as optional output) to encapsulate all the conversion of Lat/Lon + INS to be done within sensor module
  • Fatih will propose a new message for GNSS that includes both position + orientation info with boolean to indicate which values are valid.
• Radar:
  • We can contact SmartMicro and Continental to review the message type proposed in https://github.com/orgs/autowarefoundation/discussions/191
• How about ultra-sonic sensors
  • We can use https://github.com/ros2/common_interfaces/blob/master/sensor_msgs/msg/Range.msg
  • We don't have any module that uses ultrasonic output. We might want to wait until we have better idea about how we want to use it in Perception stack.

Next Week Topic

Planning