pointcloud_preprocessor builds but issues a warning.

--- stderr: pointcloud_preprocessor 
CMake Warning (dev) at CMakeLists.txt:18 (find_package):
  Policy CMP0074 is not set: find_package uses <PackageName>_ROOT variables.
  Run "cmake --help-policy CMP0074" for policy details.  Use the cmake_policy
  command to set the policy and suppress this warning.

  CMake variable PCL_ROOT is set to:

    /usr

  For compatibility, CMake is ignoring the variable.
This warning is for project developers.  Use -Wno-dev to suppress it.

There are other packages that rely on PCL and don't have this warning, so we should be able to get rid of it

In porting sensing_launch in tier4/autoware_launch-old#14, I wrote this snippet of code when porting this section

      <node pkg="ublox_gps" name="ublox" exec="ublox_gps_node" if="$(var launch_driver)">
        <remap from="ublox/fix" to="ublox/nav_sat_fix" />
          <arg var="parameters" value="$(find-pkg-share ublox_gps)/config/c94_f9p_rover"/>
      </node>

There are two problems:

Runtime failure

[ublox_gps_node-1]   what():  U-Blox: Could not open serial port :/dev/ttyACM0 open: No such file or directory
[ERROR] [ublox_gps_node-1]: process has died [pid 31543, exit code -6, cmd '/home/frederik.beaujean/AutowareArchitectureProposal/install/ublox_gps/lib/ublox_gps/ublox_gps_node --ros-args -r __node:=ublox -r ublox/fix:=ublox/nav_sat_fix -r __ns:=/sensing/gnss'].

I suspect that's because I don't actually have the sensor connected to my laptop. Can somebody confirm this?

Missing parameters

There is no config file c94_f9p_rover to be found in our repositories. I only found similarly named files c94_m8*.yaml in https://github.com/tier4/ublox/tree/master/ublox_gps/config and m8u_rover.yaml in the same directory. Does anyone know which file to choose? Or perhaps have a copy of the missing file?

Good day

I have a suspicion that there is an error during initialization of std::normal_distribution<>

The variance value is used (from pose covariance matrix), not the standard deviation, as required by the documentation.
Perhaps it should be done like this:
std::normal_distribution<> x_distribution(0.0, std::pow(base_pose_with_cov.pose.covariance[0], 0.5));

@esteve When consuming the osqp_interface package in the ros2 branch, I noticed something strange

$ colcon build --packages-up-to osqp_interface 
Starting >>> osqp_vendor
Finished <<< osqp_vendor [1.76s]                     
Starting >>> osqp_interface
Finished <<< osqp_interface [1.69s]

But when I look at the build in more detail, there is a warning. To reproduce this,

$ touch src/autoware/pilot.auto/common/math/osqp_interface/CMakeLists.txt
$ VERBOSE=1 make -j1 -C build/osqp_interface/
make: Entering directory '/home/frederik.beaujean/AutowareArchitectureProposal/build/osqp_interface'
/usr/bin/cmake -S/home/frederik.beaujean/AutowareArchitectureProposal/src/autoware/pilot.auto/common/math/osqp_interface -B/home/frederik.beaujean/AutowareArchitectureProposal/build/osqp_interface --check-build-system CMakeFiles/Makefile.cmake 0
Re-run cmake file: Makefile older than: /home/frederik.beaujean/AutowareArchitectureProposal/src/autoware/pilot.auto/common/math/osqp_interface/CMakeLists.txt
-- Found ament_cmake_auto: 0.9.6 (/opt/ros/foxy/share/ament_cmake_auto/cmake)
-- Using PYTHON_EXECUTABLE: /usr/bin/python3
CMake Warning at /home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/share/osqp_vendor/cmake/ament_cmake_export_libraries-extras.cmake:116 (message):
  Package 'osqp_vendor' exports library 'osqp' which couldn't be found
Call Stack (most recent call first):
  /home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/share/osqp_vendor/cmake/osqp_vendorConfig.cmake:41 (include)
  /opt/ros/foxy/share/ament_cmake_auto/cmake/ament_auto_find_build_dependencies.cmake:67 (find_package)
  CMakeLists.txt:13 (ament_auto_find_build_dependencies)

as a consequence,

message("osqp_vendor libraries ${osqp_vendor_LIBRARIES}")

gives empty output and a consumer can get a linker error about missing symbols.

However when I build everything with colcon, I get a different output

colcon build --packages-up-to mpc_follower --cmake-args -DCMAKE_BUILD_TYPE=Debug
Starting >>> autoware_control_msgs
Starting >>> osqp_vendor
Starting >>> autoware_planning_msgs
Finished <<< autoware_control_msgs [0.48s]                                                                                                       
Starting >>> autoware_vehicle_msgs
Finished <<< autoware_planning_msgs [0.58s]                                                                                                     
Finished <<< autoware_vehicle_msgs [0.73s]                                                                
Finished <<< osqp_vendor [1.45s]                    
Starting >>> osqp_interface
--- stderr: osqp_interface                             
osqp_vendor libraries /home/frederik.beaujean/AutowareArchitectureProposal/install/osqp_vendor/lib/libosqp.so
---
Finished <<< osqp_interface [1.86s]

questions

• So why is osqp_vendor_LIBRARIES empty when invoking make directly?
• And why is there only the shared object and not libosqp.a in the other case?

Sumary

The topic tools package is used by a couple of different packages within this repository, specifically ShapeShifter and relay topics. Currently the topic_tools package is not ported. I've been following the (rather) recent discussion on getting topic_tools ported but it seems like something that might not be easily achieved:

• https://discourse.ros.org/t/ros2-anything-equivalent-to-topic-tools-shapeshifter/3393
• ros2/ros2#857

It package topics_tools appears to be used in the following packages (other than autoware_state_monitor) but only as part of the launch file:

1. autoware_state_monitor - ShapeShifter
2. awapi_awiv_adapter - relay nodes
3. scenario_selector - relay nodes
4. simple_planning_simulator - relay nodes

Potential work around so far can be to use GenericSubscription part of ros2bag_transport as an example on how to extend the SubscriptionBase to suit the simplistic needs of generalising the subscription of topics. Though it seems like there may be many dependencies that over-complicates the package.

For the autoware_state_monitor the GenericSubscription is sufficient as all that is necessary is collecting the time in which a topic is published to. The data from that topic is irrelevant. Though the ability to know the topic name is important for logging purposes.

To Do:

• @dejanpan to investigate the state of topic_tools porting.
• @nnmm and @mitsudome-r to add any other investigation they have done on the topic.

I tried many methods on the Internet and failed, thank you very much

see #240

In order to concanate the lidar point cloud datas from the rosbag file I recorded before, I cannot subscribe to the topics in the preprocessing.launch file however I tried to many ways to subscribe. Anyone have an idea?
Here's my launch file and rqt_graph:
Note: I recorded the rosbag with only 2 lidars(you can see as /velodyne_points_01 and /velodyne_points_04) just for now and that's why I deleted if condition part from the launch file for concat filter and try to adapt my situation.

Also when I launch the preprocessing.launch file I got this error:
[ERROR] [1628676610.166239566]: Skipped loading plugin with error: XML Document '/home/nisa/workspace/AutowareArchitectureProposal.iv/install/traffic_light_ssd_fine_detector/share/traffic_light_ssd_fine_detector/traffic_light_ssd_fine_detector.xml' has no Root Element. This likely means the XML is malformed or missing..
[ INFO] [1628677513.596157724]: Initializing nodelet with 16 worker threads.
[ INFO] [1628677513.601915580]: waitForService: Service [/pointcloud_preprocessor/pcl_manager/load_nodelet] is now available.
[ WARN] [1628677518.640897647]: This node/nodelet subscribes topics only when subscribed.
[ WARN] [1628677518.724132091]: This node/nodelet subscribes topics only when subscribed.

<launch>
  <arg name="input_points_raw0" default="/velodyne_points_01"/>
  <arg name="input_points_raw1" default="/velodyne_points_04"/>
  <arg name="input_points_raw2" default=""/>
  <arg name="input_points_raw3" default=""/>
  <arg name="input_points_raw4" default=""/>
  <arg name="input_points_raw5" default=""/>
  <arg name="input_points_raw6" default=""/>
  <arg name="input_points_raw7" default=""/>
  <arg name="input_points_number" default="2"/>
  <arg name="output_points_raw" default="/points_raw/cropbox/filtered"/>
  <arg name="tf_output_frame" default="base_link"/>

  <!-- nodelet manager -->
  <group ns="pointcloud_preprocessor">
    <node pkg="nodelet" type="nodelet" name="pcl_manager" args="manager" output="screen" />

    <!-- concat filter -->
    <group if="$(eval input_points_number!=1)">
      <node pkg="nodelet" type="nodelet" name="concatenate_filter" args="load pcl/PointCloudConcatenateDataSynchronizer pcl_manager" output="screen">
        <rosparam param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1)]</rosparam>         
        <remap from="~output" to="points_raw/concatenated" />
        <param name="output_frame" value="$(arg tf_output_frame)" />
        <param name="approximate_sync" value="true" />
	
<!--        
<rosparam if="$(eval input_points_number==2)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1)]</rosparam>
        <rosparam if="$(eval input_points_number==3)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2)]</rosparam>
        <rosparam if="$(eval input_points_number==4)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2), $(arg input_points_raw3)]</rosparam>
        <rosparam if="$(eval input_points_number==5)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2), $(arg input_points_raw3), $(arg input_points_raw4)]</rosparam>
        <rosparam if="$(eval input_points_number==6)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2), $(arg input_points_raw3), $(arg input_points_raw4), $(arg input_points_raw5)]</rosparam>
        <rosparam if="$(eval input_points_number==7)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2), $(arg input_points_raw3), $(arg input_points_raw4), $(arg input_points_raw5), $(arg input_points_raw6)]</rosparam>
        <rosparam if="$(eval input_points_number==8)" param="input_topics" subst_value="true">[$(arg input_points_raw0), $(arg input_points_raw1), $(arg input_points_raw2), $(arg input_points_raw3), $(arg input_points_raw4), $(arg input_points_raw5), $(arg input_points_raw6), $(arg input_points_raw7)]</rosparam>-->
      </node>
    </group>

    <!-- crop box filter -->
    <node pkg="nodelet" type="nodelet" name="crop_box_filter_mesurement_range" args="load pointcloud_preprocessor/crop_box_filter_nodelet pcl_manager" output="log">
      <remap if="$(eval input_points_number==1)" from="~input" to="$(arg input_points_raw0)" />
      <remap if="$(eval input_points_number!=1)" from="~input" to="points_raw/concatenated" />
      <remap from="~output" to="$(arg output_points_raw)" />
      <rosparam>
        min_x: -200.0
        max_x: 1000.0
        min_y: -50.0
        max_y: 50.0
        min_z: -2.0
        max_z: 3.0
        negative: False
      </rosparam>
      <param name="input_frame" value="$(arg tf_output_frame)" />
      <param name="output_frame" value="$(arg tf_output_frame)" />
    </node>
  </group>
</launch>

I was wondering why did you choose to run centerpoint voxel encoder module on Torch instead of TRT ?

I want to install branch ros2 on ubuntu 20.04 + RTX 3070. I installed repo with colcon build, but when I install pkg: lidar_apollo_instance_segmentation.
I get error:
CUDA_TOOLKIT_ROOT_DIR not found or specified
CUDA NOT FOUND
TensorRT is NOT Available
CUDNN is NOT Available
gdown: command not found. External files could not be downloaded.

Does everyone know which version of CUDA for ubuntu 20.04 and RTX 3070?

What should be the new method of looking up transform with a given timeout. With the current implementation of BufferCore, this cannot be achieved (see the doxygen for information). However the implementation provided by tf2::BufferClient allows for a timeout duration to be specified (see the doxygen for information).

It would be ok, to ignore the timeout duration in transform lookups using the current time, however some methods use the message time stamp which might result in errors due to latency.

In the implementation of the concatenate filter in ros1, if the input topic is not ready when the timer callback is called, the timer rate temporarily speeds up (10 Hz -> 100 Hz) not to wait 0.1 sec until the next timer callback is called.

Since the ROS2 generic timer doesn't' have the API to change the timer rate in runtime, the above function is dropped for the ROS2 porting.

This problem should be dealt with in some way, port the API of the setTimerRate() in ROS2, or redesign the concatnate_filter. The latter is better, I think.

Follow guidelines of https://github.com/ros2/eigen3_cmake_module#edit-your-cmakeliststxt to avoid subtle errors in include problems for consumers

Assign to @fred-apex-ai

Summary

This issue is to keep track of clean up requests which will be done post-porting. These tasks are tangential to the porting effort but important refactoring/style changes which should be addressed after the porting effort.

To Do

• multi_object_tracker - convert iterator based for loops to range-based for loops

The ReadME of the lidar_centerpoint module reads that you're training the model using mmdetection3d. How did you export it to ONNX then? And which configuration of the CenterPoint in mmdetection3d is used?

Hello,

Like I asked already on header, I don't think we need to calculate centroid in 3D (and loop through all the points), because cv::minEnclosingCircle will give the centroid in 2D already and we can calculate the centroid in 3D by:

// calc min and max z for cylinder length
  double min_z = 0;
  double max_z = 0;
  for (size_t i = 0; i < cluster.size(); ++i) {
    if (cluster.at(i).z < min_z || i == 0) min_z = cluster.at(i).z;
    if (max_z < cluster.at(i).z || i == 0) max_z = cluster.at(i).z;
  }
// calc circumscribed circle on x-y plane
  cv::Mat_<float> cv_points((int)cluster.size(), 2);
  for (size_t i = 0; i < cluster.size(); ++i) {
    cv_points(i, 0) = cluster.at(i).x;  // x
    cv_points(i, 1) = cluster.at(i).y;  // y
  }
  cv::Point2f center;
  float radius;
  cv::minEnclosingCircle(cv::Mat(cv_points).reshape(2), center, radius);
  centroid.x = center.x;
  centroid.y = center.y;
  centroid.z = std::max((max_z - min_z), ep)/2;

https://github.com/tier4/Pilot.Auto/blob/0f3dee10dd4c22fddbee44662bd520e5a6d87ef7/perception/object_recognition/detection/shape_estimation/src/model/normal/cylinder.cpp#L39-L46

https://github.com/tier4/Pilot.Auto/blob/0f3dee10dd4c22fddbee44662bd520e5a6d87ef7/perception/object_recognition/detection/shape_estimation/src/model/normal/cylinder.cpp#L64

Some packages fail to build on arm64 due to compilation options tied to x86. For example in the ndt_omp
I'll open a PR soon addressing these

Motivation

Even after porting to ros2, the word nodelet survived in file names; e.g. there is passthrough_filter_nodelet.cpp but the node is registered as PassThroughFilterComponent. This is confusing.

acceptance criterion

• names are consistent
• no more reference to nodelets, they don't exist in ros2

@TakaHoribe @rej55 cc @yukkysaito @kenji-miyake

一旦ビルドを通すためにcapcity=100で進めて最後に調整する

capacity=100で問題ありそうなパッケージ

• obstacle avoidance planner

Hi

I am trying to figure out how to add a camera for traffic light recognition in pilot.auto 0.5.1.
I can't manage to generate ROIs for the traffic light because I don't have the camera<->map transform for my camera images.

The file here:
https://github.com/tier4/autoware_launcher.iv.universe/blob/master/sensing_launch/data/traffic_light_camera.yaml

looks like a calibration for the camera. It looks similar to the calibration file in autoware.ai, except there is a 3x4 'projection_matrix' which does not exist in .ai calibration files. What does this matrix correspond to?

Is there any tool to generate this calibration file? or is it possible to convert calibration from .ai to pilot.auto?

Thanks

The url for autoware_web_controller is obsolete.
Use web_controller instead.

To find errors in package.xml early, it is useful to run the linters to check a package.xml. @nnmm and @fred-apex-ai found a little issue in #88 (review) this way. Linters should be enabled and it is encouraged that while porting, one runs at least

colcon test --packages-select foo

before considering a PR ready for merge.

Action items

• Update existing ports
• update porting doc guidelines
• discuss in standup to check for this in reviews

Hi,

I have found out that the HSV based traffic light classifier assume the image encoding is BGR:

While the image is actually in RGB:

As the result it leads to the classifier mistaking red light for green light.
The CNN based classifier does not have this issue.

The issue is present both in master and ros2 branch.

Could you please provide a docker file to try these packages or specify the environment details?

How to construct map to do localization and traffic light detection? Kindly help

Hi,

I am playing with autoware.iv and trying out the new features.
Is lane change supported in this version? If yes, where is it implemented?

Thanks

vehicle_info_util.cpp: In instantiation of ‘T {anonymous}::getParameter(rclcpp::Node&, const string&) [with T = double; std::string = std::__cxx11::basic_string]’:
vehicle_info_util.cpp:44:75: required from here
vehicle_info_util.cpp:29:44: error: no matching function for call to ‘rclcpp::Node::declare_parameter(const string&)’
29 | return node.declare_parameter(name);
| ^
In file included from /opt/ros/foxy/include/rclcpp/node.hpp:1224,
from /opt/ros/foxy/include/rclcpp/executors/single_threaded_executor.hpp:28,
from /opt/ros/foxy/include/rclcpp/executors.hpp:22,
from /opt/ros/foxy/include/rclcpp/rclcpp.hpp:146,
from /home/autoware/src/autoware/AutowareArchitectureProposal.iv-main/vehicle/util/vehicle_info_util/include/vehicle_info_util/vehicle_info_util.hpp:20,
from /home/autoware/src/autoware/AutowareArchitectureProposal.iv-main/vehicle/util/vehicle_info_util/src/vehicle_info_util.cpp:15:
/opt/ros/foxy/include/rclcpp/node_impl.hpp:157:1: note: candidate: ‘auto rclcpp::Node::declare_parameter(const string&, const ParameterT&, const ParameterDescriptor&, bool) [with ParameterT = double; std::string = std::_cxx11::basic_string; rcl_interfaces::msg::ParameterDescriptor = rcl_interfaces::msg::ParameterDescriptor<std::allocator >]’
157 | Node::declare_parameter(
| ^~~~
/opt/ros/foxy/include/rclcpp/node_impl.hpp:157:1: note: candidate expects 4 arguments, 1 provided
make[2]: *** [CMakeFiles/vehicle_info_util.dir/build.make:63: CMakeFiles/vehicle_info_util.dir/src/vehicle_info_util.cpp.o] Error 1`

Hey guys
In mpc.cpp file does anyone know how to derivate these two functions 'addSteerWeightR' and 'addSteerWeightF'? I can not understand these two functions.

Looking forward to receiving help!

overview

@0x126 @miursh @aohsato @yukkysaito @YamatoAndo
I think that the existing concat filter is comlicated to implement and is prone to unexpected bugs. So I came up with a simpler implementation. Please comment for this issue!

difference

• Existing logic
  • Basically wait until all topics are available except in some cases. If the same topic is subscribed multiple times before all the topics are available, the timer will start from there, and if the topics are not available by the timeout, the remaining topics will be combined and published at that time.
• New logic
  • The topics subscribed within the timeout are combined and published at that time. If all topics are not available at time limit, the remaining topics will be combined and published at that time. (please refer to below image.)

Limitation

The current implementation does something like case1. For example, data for annotation should be conbined in consideration of shutter timing. To do this, for example, searching close time stamp topics from topic queue is one of the idea. However, the interval between topics is actually short, so I think that linear interpolation is sufficient even in case2.

Relationship between shutter timing and concatenation logic

case1

Since the conventional logic does not consider the shutter timing, it will combine topics with different shutter timings as shown in the figure below.

case2

Ideally, it is better to combine topics with the same shutter timing like this.