Running RRT without the GUI

[steenax86]

Hey guys,

Would you have quick recommendations to tweak RRTWidget.cpp and main.cpp such that RRT does not use a GUI for the obstacle setup? My use case is: being able to run RRT experiments (after recompiling the code several times) on complicated obstacle paths. Could we store complicated obstacle setups to a file and read it in for subsequent executions? I am open to using a quick hack, and would prefer not relying on the GUI to drive the algorithm.

Thanks in advance,
Steena

[jgkamat]

Hi @steenax86!

This rrt is primarily developed for RoboJackets/robocup-software, which ineracts with the rrt entirely as a library (without using the rrt-viewer). This project is split into two parts, the rrt-viewer (which is what you're referring to), and the rrt itself. The rrt-viewer uses the rrt library to add it's obstacles and run the rrt from them, the viewer just happens to drive these interactions through a GUI. For your use case, I suspect you would want your interactions to be driven through your own program (which need not have a GUI).

I'm not too familiar with the RRT library actually, so maybe @joshhting has some comments on best approaches to tackling this.

At a first glance, what you want to do is create a stateSpace object to represent your objects, which you can generate programatically however you wish. You can then pass that stateSpace object to the RRT library when creating it, and you should be good to go. This is the section where we update the obstacle grid, again, while this is driven by a GUI in this case, it definetly does not need to be.

One more thing to note, I don't think that the obstacle object (stateSpace) needs to be a grid, I think you can define your own stateSpaces which aren't grids.

Please let me know if you have any questions, or if that didn't make any sense! :)

[steenax86]

Hi @jgkamat !

Thank you very much for all the pointers!! II am actually in the process of writing my own stateSpace and modifying the RRTWidget.cpp and the main.cpp.

If I am generating the state space programmatically, would I need to worry about updating the obstacle grid during the execution? For a new obstacle setup, I could re-create my obstacle course, recompile, and run. Does this sound right?

Thanks again!

[jgkamat]

@joshhting do you know if the RRT copies the state space at the start of the iteration?

I would guess that you do need to, but the call to RRT probably would block to prevent doing that (and to return the path with the least hassle) so unless you're doing multithreaded programming I think you should be fine.

For a new obstacle setup, I could re-create my obstacle course, recompile, and run. Does this sound right?

Yup! You could also have your program do it for you, so you only need to write one program which runs the RRT repeatedly (and so you don't need to keep recompiling for every test).

[joshhting]

The RRT uses a single statespace if that's what you're asking. Creating your obstacle course before passing it into the RRT is certainly valid, but If you're just changing the configuration of obstacles during execution time, you are also free to update your obstacle configuration live, like we do with our ObstacleGrid::obstacleAt().

[steenax86]

Thanks guys for all the pointers. Just got back to the project and have managed to eliminate the GUI for now and get the code to compile and run. However, I don't quite understand how to distribute obstacles around state space.

RRTWidget.cpp has several obstacle checks like so, (_stateSpace->obstacleGrid().obstacleAt(x, y)). Is there a way I could just pass a series of coordinate pairs (x,y) to the obstacleGrid() to set up a custom obstacle course? I am a little unclear on the 2dplanning method I ought to be using to do this.

Secondly, would this vector contain the final path after BiRRT computation:
std::vector<Eigen::Vector2d> path = _biRRT->getPath();

Thanks in advance!

[joshhting]

If you wish to use our obstacle grid, we represent our search space as a 2d grid of boolean values indicating whether there is an obstacle at that grid cell. ObstacleGrid::obstacleAt(x,y) is the only method it currently has for setting up obstacles. It sets the obstacle state (either true or false) for the grid location at (x,y), so you'll have to call that function for every cell that comprises your obstacle walls.

std::vector<Eigen::Vector2d> path = _biRRT->getPath(); does return the final path. Specifically it returns the list of nodes in the RRT that comprise the solution path.