Publish trajectory novelty scores

[PDuckworth]

@hawesie Where do you want the novelty scores published from? The ROS Service, or the client node which calls the service? Isn't the client node kind of redundant if I return the service msg, then publish this msg?

Would it not be better to return the service msg to the client, then run some logic (in the client node) and then publish the significant novelty scores??

[hawesie]

If we're only every going to use the significant scores in the other nodes, then the latter is fine.

[PDuckworth]

I think so. Most of the novelty scores returned will be un-interesting.

Did you want them publishing so we can log them? Is it possible to log the service msgs returned?

[hawesie]

Yes, logging was one reason publish them. Without publishing you can just use the mongodb_store message store interface to save the results of the service call.

[PDuckworth]

@jayyoung I currently publish a UUID on "/trajectory_behaviours/novel_trajectory".

Hope that's OK?

[jayyoung]

Cool thanks! That's the UUID you get from bayes_people_tracker, right? So I should be able to just look in there to get the current pose for a particular UUID

[jayyoung]

Also @PDuckworth do you have a service where I can request the novelty score for a given UUID?

[hawesie]

I think the idea is that you don't need that service because @PDuckworth is already doing that and making the decision.

[jayyoung]

Right, yes, I thought /trajectory_behaviours/novel_trajectory might publish multiple UUIDs, and I'd need to pick between them, but that's not the case yet.

[PDuckworth]

@jayyoung Sorry, I missed these comments. Yes, I only publish the UUID you need to drive up to.

Although, I have nothing in place to stop two trajectories (temporally very close) both being novel, and hence publishing both (one after another). Maybe you want to add a delay on the messages you can subscribe to so you have time to actually drive up to the UUID's pose?

[jayyoung]

I didn't know about that, I'll work something out. Thanks for letting me know. I think just having my behaviour block once an interesting UUID has been picked up is probably the best thing to do for now.

[PDuckworth]

Agreed. You probably would want a feature like this anyway (regardless of my publishing), to stop you trying to drive up to someone before someone else has had time to swipe their card.

[jayyoung]

Actually this is a non-issue, since the system won't trigger a new check if a check has been performed in the previous N minutes (starting from when the task was triggered), so it can't interrupt itself so long as the task time is shorter than the cooldown, and the task times out after a few minutes anyway, and that's the worst case scenario time-wise.