Start ROSCore for launch debugging, if not running (ROS1) #429
Conversation
|
|
|
Thank you! |
|
@RyanDraves I'd love to chat with you about your contributions. If you are interested, could you connect with me on linked in? https://www.linkedin.com/in/louamadio/ |
|
|
||
| // Wait for the core to start | ||
| while (!(await rosApi.getCoreStatus()).valueOf()) { |
There was a problem hiding this comment.
It would be great to add a maximum timeout - Wouldn't want to cause issues with vscode if roscore fails for some other reason.
There was a problem hiding this comment.
Good catch. I wasn't sure on the exact timeout to set, so I settled for 3 seconds. From my local testing, roscore seems to activate at about the 700 ms mark, but I figured it could be slower if you were running this on a Raspberry Pi or something. The error message should help users if a super slow machine can't start roscore in 3 seconds.
| break; | ||
| } | ||
| case "2": { | ||
| // TODO, support starting the ROS2 daemon automatically |
There was a problem hiding this comment.
With a Todo comment, could you link it to a github issue so we don't forget to add this?
There was a problem hiding this comment.
I created #431 for the issue. I wasn't sure on the exact format you wanted to link it, so I went with // TODO(#431) on both relevant comments if that's alright.
Resolving #282 for ROS1, I chose option 2 for what was discussed with how to implement this feature. Since launch debugging needs to set rosparams, I found it more suitable to active the core at the beginning then monitor for it to become active. The core that is started will close when the VSCode Window is closed, same as having run the
ROS: Start Corecommand manually. As I'm not familiar with ROS2, I set this feature to only work for ROS1.Using the method I described in #330, I tested this implementation by using launch debugging on some rostests. Test cases includ asserting the values of rosparams, so I can verify that they are properly set.