[ROS2 Porting] Meeting 2020-10-12

[mitsudome-r]

1. Go over actions items from previous meeting
   • [ROS2 Porting] Meeting 2020-10-08 #68
   • pcl_ros is not ready yet. We might have to modify our codes so that we use pcl stand-alone library instead of pcl_ros
2. Updates from each engineers:
   • Nikolai:
     • ROS Timer. Trying out multiple solutions.
       • https://github.com/tier4/Pilot.Auto/pull/3#issuecomment-706732396
       • @nnmm update porting guideline document about timer
     • working on pose_initializer.
   • Frederik:
     • osqp_interface porting depends on external library.
     • fails to find the include file from mpc_follower.
     • still needs code porting in mpc_follower
     • shift_decider also uses timer so waiting for the solution
     • add documentation about use cases and best practices for using osqp_interface
   • Yunus: starting from next week.
   • Simon:
     • pointcloud_preprocessor
       • @mitsudome-r check if there are any nodelets that are not used
       • nodelets -> convert to components
       • dynamic_reconfigure -> parameter service client (@TakaHoribe also trying to port dynamic_reconfigure)
   • Takamasa:
     • porting as package
       • blocked by timer issue
     • porting ansible script from 18.04 for ROS2
       • still have issues with CUDA
     • working on dynamic_reconfigure
       • recap from dejan: [ROS2 Porting] Meeting 2020-10-08 #68 (comment)
     • create PR to AutowareArchitectureProposal to add guidelines for porting dynamic_reconfigure
   • Jilada:
     • geo_pos_conv package merged
     • created PR for gnss_poser
       • depends on ublox package. It's under review
     • started working on multi_object_tracker
       • depends on uuid_msgs
   • Esteve
     • ported lat_lon_muxer is under reviewer
     • updating ade. Doing more investigation on correlation with github
     • started working on ekf_localizer
   • Nithilan
     • finished porting pose2twist
     • @mitsudome-r do offline support to create PR
   • Mitsudome
     • try adding lint from Autoware.Auto to keep clean codes
3. Issues concerns:
   • Use of global parameters. For now port with the same as local parameter
     • @dejanpan will look for best practice for handling global paramters
4. Distortion correction for velodyne drivers (left over from previous contract)
   • work on this after all the porting is done.
5. Project management

• @mitsudome-r update the spreadsheet about status of each package
• @mitsudome-r tryout Github project feature.
• @mitsudome-r close old meeting minutes

[dejanpan]

@mitsudome-r I am adding these items to the agenda as well:

1. Bringing in external dependencies https://github.com/tier4/Pilot.Auto/pull/14#issuecomment-706725792
2. Dependency resolution in ros packages
   Just shortly how dependency resolution in ros packages works:
   1. you specify the ros dependency in the package.xml, e.g. https://github.com/tier4/Pilot.Auto/blob/9a6ac8109edeeb063d150b0183a02b40589dc50b/localization/util/pose_initializer/package.xml#L18
      rosdep command than looks up what is the real name of that dependency for a given OS (e.g. Ubuntu, Mac, ...) via this file https://github.com/ros/rosdistro/blob/master/rosdep/base.yaml#L3408
      See http://wiki.ros.org/ROS/Tutorials/rosdep (it works the same in ROS 1 & ROS 2)
3. Implement distortion correction for the LiDAR stack => this was a left over item from the 2018 contract.
   1. If we can have a driver that works in ROS2 with the feature, it's fine.
      It's either we add the feature to existing driver in Autoware.Auto or port the ones we have in our repo.
4. Questions 2 & 3 from here: [ROS2 Porting] Meeting 2020-10-08 #68 (comment)
5. Lets have 3 columns here: in-progress (with the link to the PR), in-review, done
   1. Also move the node dependency picture somewhere else
6. Communication:
   1. We need to make sure that we do not miss pings
   2. Please use @mentions
   3. To read the @mentions use:
      1. https://github.com/notifications?query=reason%3Amention or
      2. create the filter in gmail https://gist.github.com/ldez/bd6e6401ad0855e6c0de6da19a8c50b5#mentions
   4. For Apex.AI folks: create 1 gitlab issue for every internal 2 weeks sprint in ProjectCustomers and ping the folks internally in gitlab.apex.ai to get the info that you need ASAP.
7. Timer resolution:
   1. https://github.com/tier4/Pilot.Auto/pull/3#issuecomment-706732396
8. Close old meeting issues

[dejanpan]

@mitsudome-r this is how you re-construct the global parameter use case from ROS 1: https://index.ros.org/doc/ros2/Tutorials/Node-arguments/#setting-parameters-from-yaml-files.

So you use a stand-alone node like this one here: https://github.com/ros2/demos/blob/master/demo_nodes_cpp/src/parameters/parameter_blackboard.cpp. This allows you to introspect and also set the parameters via ROS 2 services.

This approach or approach of having the global parameter server also comes with the caveat which Tully sums very well here: https://discourse.ros.org/t/ros2-global-parameter-server-status/10114/10.