spencer-project / spencer_people_tracking

Multi-modal ROS-based people detection and tracking framework for mobile robots developed within the context of the EU FP7 project SPENCER.
http://www.spencer.eu/
668 stars 327 forks source link

Aggregate Error #78

Open Alex-Beh opened 4 years ago

Alex-Beh commented 4 years ago

I try to roslaunch spencer_people_tracking_launch tracking_on_bagfile.launch and there is no tracking result.

<!-- Aggregate front and rear lasers -->
        <node name="aggregate_lasers" pkg="nodelet" type="nodelet" args="load spencer_detected_person_association/AggregateDetectionsNodelet detected_person_association_nodelet_manager" output="screen" launch-prefix="">
            <rosparam param="input_topics">
                - composite/laser_front
            </rosparam>
            <remap from="output" to="composite/lasers_aggregated"/>
        </node>

There is no message output from the composite/lasers_aggregated. And the reason because in line, the subscriber.getSubscriber().getNumPublishers() is equal to zero which cause the msg didn't publish to the output topic. Anyone know how to solve this issue?

Thanks in advance.

Alex-Beh commented 4 years ago

Fixed by changing subscriber.getSubscriber().getNumPublishers() to subscriber.getSubscriber().

And no empty messages in input_topics that been subscribe by the aggregate nodelet.

For example, I am not using any rear sensor. So I need to comment out the composite/rgbd_ground_hog_rear in the input_topics.

<!-- Aggregate groundHOG in RGB-D -->
        <node name="aggregate_rgbd_ground_hog" pkg="nodelet" type="nodelet" args="load spencer_detected_person_association/AggregateDetectionsNodelet detected_person_association_nodelet_manager" output="screen">
            <rosparam param="input_topics">
                - composite/rgbd_ground_hog_front
                <!-- - composite/rgbd_ground_hog_rear -->
            </rosparam>
            <remap from="output" to="composite/rgbd_ground_hog_aggregated"/>
        </node>

I am not sure whether this is a proper solution or not. Anyone know or encounter the same issue please comment.

tlind commented 4 years ago

What you describe in your first comment is by design (if there is no detector publishing any messages, the aggregator nodelets should also not publish anything). However, you have to make sure that you are not running any detector (advertising such detection topics) for sensors which don't exist. Therefore, the tracking_on_bagfile.launch exposes all these arguments such as rear_laser etc. which you need to set to false.

I don't fully understand what this change implies

Fixed by changing subscriber.getSubscriber().getNumPublishers() to subscriber.getSubscriber().

and what you mean by

And no empty messages in input_topics that been subscribe by the aggregate nodelet.

I agree though that the current detection-fusion pipeline with all these converter nodelets is a bit intransparent and difficult to debug. Theoretically, it might be easier to fuse all detections from different sensors right inside the tracker without any nodelets in between.

tlind commented 4 years ago

I investigated the issue a bit further and it seems that the laser detector crashes under certain ROS / Ubuntu versions upon receipt of the first laser scan due to changes in Eigen and OpenCV. Normally, if the laser detector is not running, the convert_to_composite nodelet would not advertise any output topic (and thus not block the aggregator nodelet). However, in this case, the crash leads to the ROS master being unaware of the detector node being shutdown. I'm working on a fix.

Alex-Beh commented 4 years ago

Thanks for that. I didn't notice the clash issue, so I bypass the checking statement which is not a proper solution.

Fixed by changing subscriber.getSubscriber().getNumPublishers() to subscriber.getSubscriber().

I am currently trying this package successfully on Melodic rosdistro and going to migrate to Noetic. May I know are you going to release the Noetic version? Do you have any estimated timeline in mind?

tlind commented 4 years ago

I've got a working version for Melodic ready and it seems there are not so many changes required for Noetic, so I'd say rather sooner than later. Couple of days maybe.

tlind commented 4 years ago

I implemented a fix for this issue as part of commit 1176546 in convert_to_composite_detections.cpp. By monitoring if any message are actually received on detections topic before advertising a publisher, the aggregator nodelets should now no longer stall when a detector is "dead".

There are now also separate branches for ROS Melodic and Noetic, feel free to give them a try (known open issues for Noetic are listed in #80).

Alex-Beh commented 3 years ago

@tlind Thanks. The latest branch solved the previous issue. However, I realized the track id with missing detection at certain frame will converge towards its nearest neighbour (which is a laser data from static obstacle and it caused high number of ID switches.) I try tune the max_gating_distance in nnt.launch , it do help but the issue still remains. Which parameters should I do the tuning?

tlind commented 3 years ago

There are several parameters (including the motion model, process noise etc.) which have an impact on data association. The most important one is the measurement noise, which in the standard configuration is read from the covariance matrix in the DetectedPersons message. Only the first 2 rows and columns (x and y position over the ground plane) are relevant for tracking. You could e.g. set the first two diagonal elements to a lower value, in order to express a higher certainty and thus be more strict in data association.

An alternative, simpler way is to completely overwrite the measurement noise after measurements have arrived inside the tracker. See the following two parameters: https://github.com/spencer-project/spencer_people_tracking/blob/09b256ba4bc22c5cae8a5ae88960de1a387cfd7f/tracking/people/srl_nearest_neighbor_tracker/launch/nnt.launch#L68-L69

However, if you set the noise level too low, data association might always fail, resulting in a very high number of ID switches. The trade-off can be difficult to get right for all kinds of scenarios.

Alex-Beh commented 3 years ago

@tlind Then what is the trade-off if set the measurement noise level too high? Will include more uncertainty into the tracking process?

The motion model and process noise that you mentioned are those in the imm parameter files? I saw there are few imm parameter file with different combinations of motion models inside the tracking folder. May I know how to choose the motion models, markov transition probabilites and the cosvxx/cosvyy for each models?