loading
 
GPS_Reader module needs more variables
John Davis  [71 posts]
4 years
Trip routing is an important robotic and simulation task.  It goes down a list of places to go and what to do at each place.  RoboMagellan is one example that typically uses both GPS and vision.  Urban Challenge, DARPA or mini, is another.
I have been trying to use the GPS_Reader module within RR to do basic RoboMagellan: visit a list of lat-lon coordinates and, at each point on the list, find and drive up to an red traffic cone.  GPS_Reader doesn't seem to have enough visible variables to do this easily.  
It knows when a waypoint is reached (it turns green), but no variable changes to signal that.  GPS_WAYPOINT_DISTANCE can be tracked to do that (at least before the waypoint is reached), but the bookkeeping is already being done internally; why not share that information?
GPS_WAYPOINT_COMPLETE starts up with value 1, changes to 0 when the first waypoint is reached, then changes back to 1 at the last waypoint.  I can set it to 0 at startup, but I shouldn't have to put in that little bit of clutter.
In any case, the documentation for GPS_Reader is out-of-date.  It is possible I missed something obvious; I previously completed a C++ RoboMagellan code with OpenCV.  The appeal of RoboRealm is the easy reuse of powerful modules, but I am still learning how to do things the RR way.
Steven Gentner from United States  [1371 posts] 4 years
John,

Thanks for the feedback. Based on what you are saying would some/all/any of the following variable be what you are looking for? (We can add them quite quickly as you note they are already being calculated).

GPS_WAYPOINT_CURRENT - the waypoint number currently being targeted (will switch to the next point as soon as it is reached)
GPS_WAYPOINT_LAST - the last waypoint number that was visited

And we will fix the GPS_WAYPOINT_COMPLETE variable.

If you have any others that are needed, let us know!

Thanks,
STeven.
John Davis  [71 posts] 4 years

1. GPS_WAYPOINT_CURRENT and GPS_WAYPOINT_LAST as described would be very helpful.
Unaugmented GPS may be in error as much as +/-30 feet (+/-10 meters).  So, on a complex urban competition course your robot might 'reach' waypoints out of sequence.  For example, it is approaching WP 1 and suddenly GPS_WAYPOINT_DISTANCE changes to less than the specified removal distance; does that mean that it found WP 1 and is now showing the distance to WP 2?  Or does it mean that the reported GPS position has jumped?  These two variables will remove any ambiguity.

2. Waypoint (line) numbers should be displayed in the GUI "Waypoints" field and in the pop-up editor.
This would be very helpful when the list has more than 10 points.

3. Default "Waypoint Removal Distance" should be more realistic, say 10 ft.
I suspect the current 0.0005 default is left over from when this field meant kilometers.

4. Documentation should describe how Reset, Auto Reset, and Reset Trigger interact.

5. A "Run Once" check box would be nice for simulation runs.
You can achieve this with programming, but if it is easy to provide...

6. All displayed variables should be testable.
In the Display_Variables module, what does it mean when GPS_WAYPOINT_HEADING and GPS_WAYPOINT_DISTANCE disappear?  I know this is when GPS_WAYPOINT_COMPLETE changes from 0 to 1, but I have to guard any code that was using those variables.  I haven't done exhaustive tests, but I found that testing for null/non-null doesn't work.  Perhaps we could use GPS_WAYPOINT_COMPLETE as a state variable, but that should be specified in the documentation as a contract.  Then GPS_WAYPOINT_COMPLETE would indeed have to be 0 before any waypoints had been reached.
John Davis  [71 posts] 4 years
Just tried latest RR.  Downloaded as 2.50.16, but appeared as .15.  No new GPS variables, so must be a mixup.
Steven Gentner from United States  [1371 posts] 4 years
John,

Its possible the actual code hadn't made it up just yet. Regardless, .17 should be available (just redownloaded it on my machine). To answer your post above:

1. Out of order approaching of waypoints is ok, they will NOT be removed unless the distance is less than the specified amount AND it is the currently targeted waypoint. The assumption is that the waypoints are specified in order of visitation. If they overlapp in space that's ok, they will not be removed unless you are within proximity of the current waypoint. As far as the module is concerned, the only waypoint that exists while in operation is the next waypoint, all others are ignored until their turn comes up.

2. Waypoint numbering has been added and also now shown in the map just above the waypoint circle.

3. Inital default  removal distance has been updated to 10 ft but since you've been using the module before that value is stuck in there until you insert the module from scratch again. If you change yours to 30 and exit/save it should preserve that value.

4. Documentation describing Reset, Auto Reset, and Reset Trigger added.

5. "Run Once" check box - Simulation is now tied to the waypoint reset. If it is reset, the simulation will continue to run, it is isn't the simulation will stop.

6. Displayed variables - The removal of the variables is just another way of saying that their values are currently not valid, the way that RR is written is that even when you grab the value for a non-existant variable you will get a zero or an empty string which would be what we would set the value to anyhow.

Based on your last post, we did change GPS_WAYPOINT_COMPLETE to be 1 when inactive and 0 when waypoint targetting is active. You should be able to use that to turn off your entire pipeline and GPS_WAYPOINT_REACHED for intermediate
waypoint notification. Or should we also change GPS_WAYPOINT_COMPLETE to another value for intermediate waypoints?

John Davis  [71 posts] 4 years
Thanks for providing these new features.  I have just downloaded and made a first test run.  

I just now saved my program and selected it for upload while it is still running because of one peculiar thing:  after pausing by toggling the RR Run button, one of the two waypoints had been reached; after continuing by toggling Run again, the simulation did not change.  (Much later it started running again, while I was composing this paragraph.)

My test simulation is a very simple route that runs east and west.  I selected two points from the file as waypoints 0 and 1 (WP0 and WP1).  When the simulation begins, the three state variables GPS_WAYPOINT_REACHED, GPS_WAYPOINT_CURRENT, and GPS_WAYPOINT_COMPLETE (REA, CUR, and COM) are all "0", as expected.  After WP0 is reached, REA and CUR change to 1, not what I would have expected for REA.  Then after WP1 is reached, COM also changes to 1, as it should.

I think that waypoint numbering should start with "1"; that way, REA="0" can be reserved for the case where no waypoints have been reached.

(Just a minor point: the intent of GPS_WAYPOINT_COMPLETE might be clearer if it was plural, say, _WAYPOINTS_ or _ALL_WAYPOINTS_.)

Now, in response to your numbered paragraphs:

1.  Thanks for the clarification and for the GPS_WAYPOINT_REACHED variable which, when fully implemented, will allow an unambiguous state transition.

2.  As noted above, I suggest starting with 1 instead of 0.  (0 can stand for the implicit start point.)

3.  Thanks, again.

4.  I haven't had a chance to look at the new documentation, but I will.

5.  Very nice.

6.  I think everything you've done will work just fine once the GPS_WAYPOINT_REACHED is fixed as you intended it.

The issue of testing for valid values is a little bit too complex to debate here, but the waypoint indexing illustrates how overriding the function value's meaning can lead to errors.
GoEW.zip
program.robo
John Davis  [71 posts] 4 years
Aha!  I read the updated documentation and I see what you intended (#4) for GPS_WAYPOINT_REACHED.  That works for me.

I still think waypoint numbers should start with 1, not 0.  Does any other user care?
Steven Gentner from United States  [1371 posts] 4 years
John,

That makes sense. We've updated the waypoints to start from 1.

STeven.

This forum thread has been closed due to inactivity (more than 4 months) or number of replies (more than 50 messages). Please start a New Post and enter a new forum thread with the appropriate title.

 New Post   Forum Index