Service features

[ferdianjovan]

I added service features for logging UBD vision_people_logging. So instead of running all the time, it will be a service which will be called by other node to trigger storing UBD.

[cdondrup]

Do you need this? Because according to @lucasb-eyer this is not needed for his work any more. If I understood correctly.

[ferdianjovan]

As we will observe a person for a longer period (see https://github.com/strands-project/g4s_deployment/issues/87), we might need to delete some pics of a person stored on the fly. So yes, I need this :)

[hawesie]

@cdondrup do you mean that he doesn't want to results of logging any more, or something else?

[hawesie]

I wonder if a service is the right way to go about this? Maybe an action server that you start to enable logging and cancel to stop logging would be better? It could then publish the captured ids/logs to the feedback topic.

[cdondrup]

Yes, at least we had to stop logging in AAF because it was running with 100% CPU and using a lot of space on the HD. So we asked an he said that it is not important. But since I am not sure that is the case for your scenario as well and if you need these images yourself, I just wanted to note that it might not be necessary to store them in the first place ;) But please make sure that he really doesn't need them any more.

[hawesie]

Ok, thanks!

[ferdianjovan]

Due to the reasons @cdondrup mentioned, I chose a service that captures just one pic (one log) and give the id back in the case it needs to be deleted. I believe we just need one log for each person as the recording will be done by @PDuckworth stuff. For the pose information of that upper body, I can link the returned id to the trajectory msg from human_trajectory package to get the whole movement of the person (not done yet) if you agree @hawesie .

[ferdianjovan]

Otherwise, I can make the action server and test it today.

[hawesie]

Maybe I don't fully understand how this all works together. I'll pop down and find you shortly.

[PDuckworth]

We store rgb images for skeleton detections - and we need to remove any images we don't have consent for so it seems unnecessary to store the UBD images too. (unless i'm missing something).

[PDuckworth]

Also, we only request consent given that we record a certain number of skeleton poses, i.e. it's worth bothering them for the data. So there is no way currently to get consent from UBDs.

[hawesie]

@PDuckworth I think this is separate to your stuff.

[PDuckworth]

I agree, but how else are you going to get consent to store the image?

[hawesie]

Now I understand what this PR is for. The UBD Logging process will no longer store to the db continuously (which generates a large amount of unnecessary data). Instead the new capture service will trigger storage of the next frame(s) of detections. These can then be retrieved from the db by the other service added. The logged data will be used to move person observations into soma.

[hawesie]

This shouldn't be merged yet as @ferdianjovan still has commits to make.

[ferdianjovan]

It can be merged now, please :)

[cdondrup]

I trust you tested this on the robot.

[ferdianjovan]

Surely did, just changed a small code, so easy to test and check. Thanks @cdondrup