Fixes planning performance #147
Conversation
| while (ros::Time::now() - start_time < ros::Duration(3.0)) | ||
| loop_rate.sleep(); | ||
|
|
||
| ros::Duration(3.0).sleep(); |
There was a problem hiding this comment.
It seems worthwhile to log a message saying that it is sleeping (and why).
I'm assuming this is somehow related to ensuring the goal is delivered to the remote robot through the generic bridge? If so, it's not clear to me why it would help. I thought that the bridge didn't start establishing connections for a new message topic/type until the first message was received, so a delay in between creating the publisher and publishing the first message wouldn't help.
There was a problem hiding this comment.
I'll add a comment on this. When you declare a publisher you have to sleep a bit before publishing a message. This is not an issue when there is a connected_callback involved, but since we're doing remote commanding and waving that requirement, without this, the goal is not published. I can also lower the time involved, in retrospect 3s is too much..
astrobee/survey_manager/survey_planner/data/jem_survey_static.yaml
Outdated
Show resolved
Hide resolved
|
Closes #142 |
|
Signed-off-by: Marina Moreira <[email protected]>
I applied your patch and will rebase your PR if needed to merge asap |
As we discussed earlier, I liked your suggestion of merging my PR into this one. Just will save some hassle with rebasing my PR if your PR goes in with squash-and-merge. |
fixing inspection tool reading input and exiting
better performance in simulation
cleaning output
adding localization attitudes to jem static