Skip to content
This repository was archived by the owner on Mar 16, 2024. It is now read-only.

RRT time and distance #89

Open
Manick9 opened this issue Mar 17, 2018 · 9 comments
Open

RRT time and distance #89

Manick9 opened this issue Mar 17, 2018 · 9 comments

Comments

@Manick9
Copy link

Manick9 commented Mar 17, 2018

Hi,

Is it possible to get the time taken or the distance of the solution?

Thank you!

@Manick9
Copy link
Author

Manick9 commented Mar 21, 2018

How do you make use of the QTimer or QElapsedTimer to find out the total time taken?
Do you use it under under RRTWidget::run ?

@JNeiger
Copy link

JNeiger commented Mar 21, 2018

It looks like the QTimer in RRTWidget::run just calls the run_step() function as fast as possible while still allowing time for the CPU to process GUI events.

I don't believe we have a setup right now to say how long it has been in seconds, but we do have an iteration counter that kinda works.

To get the time taken, I would personally just add a class variable in the RRTWidget that is going to be the sum of the time taken in run_step(). Within the run_step() function, use a QElapsedTimer to get the time taken for that iteration and just add it to the sum. That should get you a fairly reasonable elapsed time for the entire solution

There is a way to get the distance, but it is not built in right now. Once the BiRRT is done, you should be able to call getPath() to get a vector of points. Once you do that, just iterate through that list adding the distances between points. We should already have a function to get the distance between two points called distance(from, to). It is in the PlaneStateSpace class, but it should be accessible in GridStateSpace due to the inheritance.

@Manick9
Copy link
Author

Manick9 commented Mar 23, 2018

Thanks a lot! I have 1 quick qn where do you change the start and goal coordinates in the program?

@JNeiger
Copy link

JNeiger commented Mar 23, 2018

No worries! In the GUI you should be able to drag the red and green things around. To do it programmatically, you can just call the setStartState and setGoalState on the BiRRT object in the RRTWidget::run function or something. I would do it there since that's the last place we touch before we actually start running the RRT. That BiRRT should be a Vector2d so it should be pretty easy to create the right arguments needed for the setters.

@Manick9
Copy link
Author

Manick9 commented Mar 23, 2018

I found the default values are being set here. Is there any easier to define the co-ordinates?

_biRRT->setStartState(size / 10);
_biRRT->setGoalState(size / 2);

@JNeiger
Copy link

JNeiger commented Mar 23, 2018

Yep! So we use Eigen/Dense for a bunch of stuff. You should be able to just initialize it like Vector2d(x, y). If you are feeling fancy you can also do...

Vector2d s;
s << x << y;

Here's a good reference page

@Manick9
Copy link
Author

Manick9 commented Mar 28, 2018

Thanks! Just a quick qn.

What does the red path represent ? Is it the previous solution?
Yellow path is the optimal path and the thick dark blue is the final smoothed path, right?

@JNeiger
Copy link

JNeiger commented Mar 28, 2018

The red path is the actual RRT solution through all the nodes.

The yellow path minimizes the number of waypoints that you need to completely describe the path.

The blue path is the smoothed one. I want to say that we use a cubic beziar curve with the waypoints in the yellow path as the anchors. This helps with motion control and stuff since sharp corners are really difficult to deal with.

@Manick9
Copy link
Author

Manick9 commented Mar 28, 2018

Appreciate your fast response.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants