strands-project / strands_perception_people

long-term detection, tracking and recognition of people
96 stars 70 forks source link

[bayes_people_tracker_logging] revamp #141

Closed cdondrup closed 9 years ago

cdondrup commented 9 years ago

Currently the logger has a message that does not correspond to what it does. It has been a general logger for the whole output of the ppl perception pipeline including the upper body detector and the mdl people tracker. Due to a stupid mistake on my side, this prevented it from logging anything if not all of these topics where published. As kind of a hotfix during the marathon, I just removed everything but the logging of the bayes_people_tracker. Long story short, I would like to re-write this component before the deployment and wante to collect some opinions. Does anyone need:

If not, I will remove those and just use the bayes_people_tracker message instead of a custom one. The current message will remain to be able to retrieve data from the datacentre that has been recorded using the logger. This rewrite will also include #138 but I guess I will use a std_srvs/Empty to toggle it instead of a dyn param.

lucasb-eyer commented 9 years ago

What kind of upper_body_detector outputs are we talking about?

I'd be interested if it does somehow include images, so I could get rid of strands_head_orientation/src/store_detections.cpp. If it's too much trouble/too off-topic for a "bayes people tracker logger," I can rewrite a dedicated logger if I can find the time to.

cdondrup commented 9 years ago

It wasn't logging images, no. It really depends on what we want to log, when, and how. I need the trajectories so logging for me means just looking at them. I included the ubd detections and the mdl tracks just in case someone needs them but I only need the bayes tracker output. If we say that, whenever we see a human we also want to log images than it could be in there as well. But then the name of the package is a bit misleading. Maybe a dedicated logger for this wouldn't hurt.

lucasb-eyer commented 9 years ago

I guess the question is what we'll want to do with the output. I think if we want to use it for evaluation purposes (ie. our paper or reports) we really need the corresponding (full) video to each track, so that we have a way to annotate ground-truth. Whether it best fits in this node or a separate one, you know better than me.

If it's for something else then I agree with the separate logger for images/video anyways.

cdondrup commented 9 years ago

I think it would be good to have the option of logging one or the other or both together. If you are only interested in logging trajectories, e.g. afaik me, @ferdianjovan, and Leeds, then always logging the images as well just floods your datacentre with unnecessary information. I agree that for ground truth we need the videos and also laser data in addition to the trajectories.

I'll create a separate node that logs all the raw data. I only have to find a way to nicely associate the tracks with it.

lucasb-eyer commented 9 years ago

sounds good to me, and I'll monitor that to see if/when I can help.

ferdianjovan commented 9 years ago

I might need images and videos later, so having the separate logger for those is really good. I will see what I can do to help that as well.

cdondrup commented 9 years ago

Thank you guys, I might take you up on that offer. There won't be much happening before the 15/3 so stay tuned.