ROS Melodic support

[NunoGuedesFollow]

Is there going to be a ROS Melodic support?

[NunoGuedesFollow]

Thanks, I will try it! Best Regards!

…

----- Original Message ----- From: AssassinCrow [mailto:[email protected]] To: [email protected] Cc: [email protected]>, Author Sent: Sun, 05 Apr 2020 06:20:33 -0700 Subject: Re: [spencer-project/spencer_people_tracking] ROS Melodic support (#74) Hello, I'm not the developer but I'm also trying to execute the spencer package in ROS melodic. Maybe you can find your answer in here(it says spencer package also supports ROS melodic.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[tlind]

Hi, adding ROS Melodic support is on our roadmap. I know there are some issues related to C++11 (namespacing issues with boost::shared_ptr and std::shared_ptr, e.g. in the rviz plugins) which currently prevent compilation also on the LCAS build farm for ROS Melodic.

However, I cannot give an ETA right now since I am mostly still using ROS Kinetic and first have to set up a virtual machine for testing. Pull requests are also welcome!

[NunoGuedesFollow]

Hi, Have you had any success by now in this matter? Best Regards, Nuno Guedes

…

----- Original Message ----- From: AssassinCrow [mailto:[email protected]] To: [email protected] Cc: [email protected]>, Author Sent: Sun, 05 Apr 2020 06:20:33 -0700 Subject: Re: [spencer-project/spencer_people_tracking] ROS Melodic support (#74) Hello, I'm not the developer but I'm also trying to execute the spencer package in ROS melodic. Maybe you can find your answer in here(it says spencer package also supports ROS melodic.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.Hi,

[tlind]

No progress on this matter so far from my side due to other duties. It seems we will skip Melodic and directly switch to Noetic / Ubuntu 20.04 which will be the final ROS 1 release.

[Alex-Beh]

@NunoGuedesFollow May I know have you compile the code successfully in Melodic? I am trying to do the migration, currently facing some issue on the opencv3

@tlind I saw your comment in other issue. (link) It seems to be quite difficult to fully change the code from opencv2 to opencv3. Is it possible to run this package in Melodic while using opencv2 as backbone? Assumming that I have resolved all the namespace issue such as adding std namespace to shared_ptr.

[tlind]

I haven't tested it myself yet, but using the method described in the link, it should be possible (assuming OpenCV 2 is still installable under your OS version).

[Alex-Beh]

@tlind Hello, may I know which version you using for the opencv? 2.4.9?

Update:
I solved the issue. My OS is Ubuntu 18.04 with Melodic rosdistro. I am using vision_opencv indigo branch (this is the one using opencv2) and did what you have commented in other issue. I have successfully run the quick start tutorial:
roslaunch spencer_people_tracking_launch tracking_on_bagfile.launch
and the result is pretty cool. Thanks for the great contribution.

Just want to double check with you, few nodelet such as /relay_rgbd_for_visualization/rgbd_rear_bottom_depth_image_raw and /relay_rgbd_for_visualization/rgbd_rear_bottom_rgb_image_raw is fail to be loaded when I roslaunch, is it normal? Any functionality or set up that I miss out?

Update 2:
Solved it by installing the following two dependencies:

sudo apt install ros-melodic-jsk-topic-tools
sudo apt install ros-melodic-jsk-rviz-plugins

Continue the tutorials. Sorry for keep spamming.

[Alex-Beh]

@tlind Sorry for interupt you again. I am still facing some issues.

There is no publisher to topic rgb/image_rect_color , may I know is this normal?

I get the detection result, but there is no tracking functionality. Is this because I am too near to the camera or something is wrong?

[tlind]

The names of the topics can vary a bit depending on which sensor and OpenNi version you use. Maybe there is "rgb/image_color_rect" or "rgb/image_color/raw" which you can use instead?

If you get detection results, but no tracking results, it is most likely due to an issue with the TF "odom" frame, which is required for tracking. Run "rosrun tf view_frames" and check that your sensor frame has a connection to odom frame.

[Alex-Beh]

@tlind I am using the realsense D435 with the realsense-ros driver. I think the detector do not subscribe to the correct image topic. I have both the following topics:

/spencer/sensors/rgbd_front_top/color/image_raw
/spencer/sensors/rgbd_front_top/rgb/image_rect_color

I tried rostopic info /spencer/sensors/rgbd_front_top/rgb/image_rect_color

Type: sensor_msgs/Image

Publishers: 
 * /spencer/sensors/rgbd_front_top/realsense2_camera_manager (http://localhost:41119/)

Subscribers: 
 * /spencer/sensors/rgbd_front_top/realsense2_camera_manager (http://localhost:41119/)
 * /spencer/perception_internal/people_detection/rgbd_front_top/upper_body_detector (http://localhost:40693/)

However, when I rostopic echo /spencer/sensors/rgbd_front_top/rgb/image_rect_color, there is no message from the topic. May I know which topic should be subscriber by the detector?

I tried to trace back the topics and nodes from rosnode info /spencer/perception_internal/people_tracking/srl_nearest_neighbor_tracker
when I rostopic info /spencer/perception/detected_persons_composite and there is no publisher to this topic. Is this correct?

From the tf frame, the rgbd_front_top_link and odom are connected although the depth frame, infra1 & infra2 do not update periodically. (The buffer length is always 0sec and I think that it is normal because they are fixed link relationships)
frames.pdf

[Alex-Beh]

@tlind Sorry for keep asking question. Have been struggled for few weeks.

Do the rosbag file come with tracking functionality? I try the following command:
roslaunch spencer_people_tracking_launch tracking_on_bagfile.launch

and below is the screenshot from rviz. It seems there is no tracking function.

I try ping the /spencer/perception/detected_persons and there is no data come out.

alex-beh@alexbeh-ThinkPad-T490:~$ rostopic hz /spencer/perception/detected_persons
subscribed to [/spencer/perception/detected_persons]
WARNING: may be using simulated time
no new messages
no new messages
no new messages
no new messages
no new messages

I am scared of losing certain functionality after the migration.

Looking forwards to your help. Thanks

[tlind]

I have added a melodic branch which includes all the necessary fixes for ROS Melodic, including migration from OpenCV 2 to OpenCV 3. I have also verified that the tracking_on_bagfile.launch example works correctly (after incorporating those fixes) via the provided Dockerfile. In addition to the screenshot above, tracked persons should be visible.

Update: Binaries for ROS Melodic are now also available from the LCAS buildfarm, as documented in the main README file.

[Alex-Beh]

The above error is about aggregate error and I think you have solved the issue. I try the melodic brnach on my laptop with the tracking_on_bagfile.launch. Although there are tracking persons shown in the rviz, but seem the groundHOG detector is not running.

I try rosnode list |grep groundHog and rostopic list|grep groundHOG but there is no results. May I know the groundHOG detector is running on your system?

[tlind]

Remember you first need to install the CUDA Toolkit (e.g. 10.1) and then manually make and install libcudaHOG (as described in detection/monocular_detectors/3rd_party/README.md), before re-building the rwth_ground_hog catkin package. Without the libcudaHOG compile-time system dependency, the detector will be non-functional and just print a red error message to the console upon startup.

However, indeed some more patching was required to make libcudaHOG compile under Ubuntu 18.04. The commit which I just pushed to the melodic branch (1970b37) provides the necessary fixes. I just tested it in a Docker container with tracking_on_bagfile.launch use_hog_detector:=true. If you switch on the DetectedPersons visualization for HOG, you should see yellow detection boxes. I also verified that the PCL detector (use_pcl_detector:=true) still works.

[tlind]

Here's how it should look like then (note that in this rather confined space, the groundHOG does not output many detections as it is intended for far-range):

[Alex-Beh]

Yes, the issue has been solved by reinstall the groundHOG library. However, the accuracy of the model decreased after the changes.

I saw you have retrained the model for leg detector with laser. May I know how you retrain the config file for the upper_body_detector or only reformat the file?

You can see the results of the previous version in the following link:
https://drive.google.com/file/d/1WpgNIhiJXu_20S_vKd8nJW4A1rYd3cYP/view?usp=sharing

I will do the comparison with the current branch and upload the result tomorrow.

[tlind]

It would be helpful to know if you think the decrease in overall performance to be related to 2D laser, HOG, or RGB-D.

For 2D laser, there have been a number of changes that could have an impact on performance:

1. The original default model was for LMS200, not LMS500. They differ in angular resolution and mounting height. You can try to switch back to a lms200 model (specified via model_prefix). Unfortunately, I do not recall on which dataset the original lms200 detector been trained (Freiburg main station, aspekt, or a combination thereof?).
2. The original model used an Adaboost classifier, now random forest. Several years ago already, we generally saw better results with RF or SVMs on several datasets, that's why I did not retrain Adaboost models for the new ROS distributions.
3. There were some changes to the training code to make sampling of positive/negative/ambiguous samples more deterministic, that gave better results on the DROW dataset.
4. Between Ubuntu 14.04 and 16.04, there had been a change in how the corresponding version of the Eigen library computes SVD decomposition in degenerate cases; this affects one or two laser features, and has a positive performance impact in some scenarios, and negative impact in others.

For the upper-body detector, I believe PR #59 from LCAS/RWTH introduced mostly a change in file format to allow easier use of the ROS parameter server, but I'm not 100% sure. I'll try to convert the template back into the old format that you can visualize nicely e.g. using VSCode (you will recognize the silhouette as "ASCII art").

Best way would be to run a quantitative evaluation on the annotated Toulouse Mo-Cap or Schiphol sequences for all 3 supported ROS versions, but I don't know when I would find time for this. With all these changes in underlying libraries (Eigen, OpenCV2->3 etc.), I would not expect 100% identical performance, but there also should not be like a +/-20% change in results.

[germal]

Hello @tlind , I'm trying to build Spencer on ROS melodic , but catkin throws errors related to Opencv3 compatibility in person_classifier.hpp
also if I changed the namespaces gpu->cuda and HOGdescriptor->HOG , for example

error: ‘getPeopleDetector64x128’ is not a member of ‘cv::cuda::HOG’
setSVM(128, 64, cv::cuda::HOG::getPeopleDetector64x128(), 0.0);

EDIT Ah ok, just found your guidance in the post of Alex !
Thanks a lot,
germal

[germal]

Hello @Alex-Beh !
I have built Spencer on melodic and I'd like to adapt to D435 .Did you managed to make it work with Spencer ? could you advice what to change ?
Thanks a lot !
Regards
germal