Navigator

This is where you talk about the EV3 software itself, installation issues, and programming talk.

Moderators: roger, gloomyandy, skoehler

Re: Navigator

Postby gloomyandy » Sun Mar 02, 2014 6:38 pm

Hi Lawrie,
I will check in the change to the motor port code later tonight. My understanding is that it fixes the synchronization issue.

The problem of the move listener being called multiple times I am not sure about. It looks to me as if it may be a long standing issue, but I don't think we have ruled out that the motor changes may be responsible.

Do you want me to create the new forum as a top level one or a sub forum of the EV3 section?

All the best

Andy
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4083
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Navigator

Postby epascual » Sun Mar 02, 2014 6:49 pm

Hi again,

I've maybe found the problem of the misbehaviour with arc moves.

It happens when an arc move is interrupted by calling Navigator.clearPath(). The problems lies in the fact that when Nav.run() loops to execute fragments of an arc move, it does not test if _keepGoing has been cleared during the just terminated one, and thus keeps on starting subsequent fragments although the rest of the process in other threads has been canceled.

This can bee seen on the trace hereafter, moveStopped and moveStarted debugs being printed in listeners:
Code: Select all
[DEBUG ] ask navigator to abort current path
[DEBUG ] moveStopped event=ARC  of -3684.3726 for -2.3466682 degrees at 100.0 provider=lejos.robotics.navigation.DifferentialPilot@baf589 thread=1
[DEBUG ] moveStarted event=ARC  of Infinity for -0.14639282 degrees at 100.0 provider=lejos.robotics.navigation.DifferentialPilot@baf589 thread=13
[DEBUG ] pathInterrupted wp=Point2D.Float[0.0, 300.0] pose=X:-0.27059302 Y:-0.12822199 H:90.14665 seq=0 thread=1
[DEBUG ] path cleared

One can notice that moveStarted listener is called after the path is aborted, and btw no corresponding stop is triggered afterwards. The fancy values for arc moves are due because these are small adjustments caused by the position drift. Maybe automatic classification done in Move.calcMoveType should introduce some tolerance rather than comparing floats with 0. I'll test if this makes things better.

Modifying it by adding the line tagged by EP makes to problem disappear.
Code: Select all
// 2. Drive the path
for (int i = 0; i < moves.length; i++) {
    ((ArcMoveController) _pilot).travelArc(moves[i].getArcRadius(), moves[i].getDistanceTraveled());
    if (!_keepGoing) break;    // EP: added (to honor a move interruption)
}

I've kept the beast running for a moment and the bot moves where it is supposed too (apart the fact that the precision of arc moves is not terrific, so the position drifts quite quickly, but this is another story).
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby lawrie » Sun Mar 02, 2014 7:21 pm

Hi Eric, I have applied your fix to the latest version. Lawrie
lawrie
leJOS Team Member
 
Posts: 922
Joined: Mon Feb 05, 2007 1:27 pm

Re: Navigator

Postby lawrie » Sun Mar 02, 2014 7:28 pm

Hi Andy,

I have applied the change to remove synchronized from getTachoCount to EV3MotorPort, but I have not tested the navigation stuff yet.

I think a sub-forum under EV3, called either EV3 Design, or EV3 Development would be best.

Lawrie
lawrie
leJOS Team Member
 
Posts: 922
Joined: Mon Feb 05, 2007 1:27 pm

Re: Navigator

Postby lawrie » Sun Mar 02, 2014 7:32 pm

Hi Andy, Our changes overlapped, so I think the change to getTachoCount got applied twice. Lawrie
lawrie
leJOS Team Member
 
Posts: 922
Joined: Mon Feb 05, 2007 1:27 pm

Re: Navigator

Postby gloomyandy » Sun Mar 02, 2014 7:39 pm

Ah that would explain the error I got. I must admit I'm still not totally sure what is going on when doing merges etc. with git! Looks like no harm done though!
User avatar
gloomyandy
leJOS Team Member
 
Posts: 4083
Joined: Fri Sep 28, 2007 2:06 pm
Location: UK

Re: Navigator

Postby epascual » Sun Mar 02, 2014 10:18 pm

lawrie wrote:Hi Eric, I have applied your fix to the latest version. Lawrie
Thanks ;)

While we are at exploring navigation and pilot, I've noticed something strange in the values of the distance of arc moves reported by the listeners. The distance of the move passed to moveStopped is half the one of moveStarted. They should be the same (more or less the real move error).

Trying to understand why, I found this statement in DifferentialPilot.steer() :
Code: Select all
_distance = 2 * Math.toRadians(angle) * radius(turnRate);

Why is there this factor 2 ? It's maybe related to the way radius() method and turn rates work, but I confess not having understood the logic behind.

For curiosity's sake, I've removed the 2 *. I know this is not very scientific as a method, but it was just to see which kind of influence this could have. Result : no change. The robot moves the same way as before, but now values reported in listeners are coherent. Strange, isn't it ?

Eric
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby bbagnall » Tue Mar 11, 2014 8:13 pm

epascual wrote:If I globally agree with a "delegation" chain such as app -> Navigator -> Pilot -> Motors (which is more or less the current situation), it can happen that the app needs to request a "direct" move. In the test program I'm working on, the robot navigates between a given set of waypoints, to deposit collected objects to the right place. So I use Navigator.goTo() by passing it the appropriate waypoints. But when depositing an object, the robot needs to realize a specific motion, consisting in : open the gripper and go backwards 10cm to be far enough from the object and not hit it afterwards. This escape move cannot be ordered using waypoints, since the resulting rotation when starting the move would hit the object. The only option is thus to call the Pilot and request it this backward escape, before asking the Navigator to go to the next waypoint.

How would you see such a scenario if the app was allowed to talk only to the Navigator ? The only solution I can imagine is that the Navigator "surfaces" direct motions from the Pilot. This could be the right option, because it would still be informed of what the robot is doing, without letting something jitter in the middle of the chain.

You can use the Navigator.getMoveController() to perform fine control over the movements when you don't want to do just coordinate navigation. As in:
navigator.getMoveController.travel(-100);

It will keep track of location even though you are making moves straight to the pilot object.

The problem with adding these methods to Navigator directly is that there are so many other methods one might want to use, such as arcs. It ends up duplicating a lot of code/methods where we don't need that much duplication.
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm

Re: Navigator

Postby epascual » Tue Mar 11, 2014 9:47 pm

Hi Brian,

navigator.getMoveController.travel(-100);
I didn't notice this method, but I did the same by invoking the method on the pilot which was passed to the navigator at creation time, and cached in a member of the robot's class. OK, I was doing the same job as Navigator already does but was not aware of this at that time ;)

I agree however that working with the navigator only is cleaner, although it generates one more level of indirection.

The problem with adding these methods to Navigator directly is that there are so many other methods one might want to use, such as arcs. It ends up duplicating a lot of code/methods where we don't need that much duplication.
I agree with this point. You're right.
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby bbagnall » Wed Mar 12, 2014 3:07 pm

Yes, it's not very obvious to find that in the Navigator class. We interchangeably use the term pilot and the API uses MoveController to talk about the Pilots. This might become more obvious if we changed the method name to getPilot() instead of getMoveController().

Some other problems with the navigator architecture that stick out:
- It is hard to code a pilot because there are a lot of methods to code. Many of the methods simply call other methods with a different parameter filled in. We could cut down on the work to be done by using an abstract class that includes those methods already coded.
- Coding the blocking/non-blocking variants can be especially difficult
User avatar
bbagnall
Site Admin
 
Posts: 392
Joined: Fri Aug 04, 2006 4:03 pm

Re: Navigator

Postby epascual » Wed Mar 12, 2014 3:24 pm

This might become more obvious if we changed the method name to getPilot() instead of getMoveController().
Yes indeed
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby roger » Fri Apr 11, 2014 7:19 pm

Sorry to be late in picking up on Brian's comments about coding Pilot. I agree that we have more methods than we really need. The blocking/non blocking variants are confusing We should just eliminate the variant methods the do not have the "immediate return" boolean. We could also delete some little used methods as arcForward, arcBackward, rotateLeft and rotateRight.
Roger
roger
Moderator
 
Posts: 363
Joined: Fri Jun 01, 2007 4:31 am
Location: Berkeley, CA

Re: Navigator

Postby epascual » Sat Jul 05, 2014 4:18 pm

Hi everybody,

It seems that the Navigator is broken again in 0.8.1-beta. The path followed by the robot is not the expected one when several moves are executed (same problem as before).

I could notice that the patches I have proposed some time ago, and which have been applied by Lawrie at this time (see above in this thread), are no more in the source code. Is there a special reason for which the code has been reversed to the old (and not working) state ?

Eric
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby epascual » Sun Jul 06, 2014 2:26 pm

After some more investigation, it seems that the problem is not the Navigator but the arc rotate path computation. The excess event firings I have noticed with previous versions seem no more occurring now. BTW, the erroneous behaviors observed with the previous version occurred randomly, even for the same orders and because of the excess events not occurring always with the same sequence, whereas now the wrong behavior occurs systematically.

For instance, here are two traces from an execution using arc rotate path :

[DEBUG ] going to waypoint [X:200.0 Y:0.0 H:0.0]...
[FSM ] switching to TRAVELING state
[DEBUG ] atWaypoint wp=Point2D.Float[200.0, 0.0] pose=X:-9.352541 Y:278.73373 H:115.079994 seq=1 thread=16
[DEBUG ] pathComplete wp=Point2D.Float[200.0, 0.0] pose=X:-9.352541 Y:278.73373 H:115.079994 seq=1 thread=16
[DEBUG ] release_and_go_home()
[GRIPPR] opening (target pos=-676)
[DEBUG ] take off from object
[DEBUG ] going to waypoint [X:0.0 Y:0.0 H:90.0]...
[FSM ] switching to TRAVELING state
[DEBUG ] atWaypoint wp=Point2D.Float[0.0, 0.0] pose=X:121.22841 Y:130.46667 H:178.58667 seq=1 thread=16
[DEBUG ] pathComplete wp=Point2D.Float[0.0, 0.0] pose=X:121.22841 Y:130.46667 H:178.58667 seq=1 thread=16

Traces are emitted in events listeners. I've highlighted in red what seems to be an anomaly : when a way point is considered reached, the pose and the way point coordinates should be more or less equals. You can see this is not the case. Since I suspect this pose being used to compute the next path, this one is completely wrong (which can be observed).

On the opposite, if using turn-and-go moves, the behavior is correct :

[DEBUG ] going to waypoint [X:-200.0 Y:0.0 H:180.0]...
[FSM ] switching to TRAVELING state
[DEBUG ] atWaypoint wp=Point2D.Float[-200.0, 0.0] pose=X:-198.91522 Y:-1.0585327 H:-179.96002 seq=1 thread=15
[DEBUG ] pathComplete wp=Point2D.Float[-200.0, 0.0] pose=X:-198.91522 Y:-1.0585327 H:-179.96002 seq=1 thread=15
[DEBUG ] release_and_go_home()
[GRIPPR] opening (target pos=-670)
[DEBUG ] take off from object
[DEBUG ] going to waypoint [X:0.0 Y:0.0 H:90.0]...
[FSM ] switching to TRAVELING state
[DEBUG ] atWaypoint wp=Point2D.Float[0.0, 0.0] pose=X:0.16777039 Y:0.16178828 H:90.27998 seq=1 thread=15
[DEBUG ] pathComplete wp=Point2D.Float[0.0, 0.0] pose=X:0.16777039 Y:0.16178828 H:90.27998 seq=1 thread=15

The only remaining defect (not visible on the traces) is that rotations are not optimized to be kept between 0 and 180, changing the direction accordingly. The robot seems to turn always in the same direction, leading to an almost full turn during one of the moves. I'll try to retrieve the Git version and see if I can fix this.

Eric
Eric PASCUAL - POBOT association VP & co-founder - http://www.pobot.org
epascual
Active User
 
Posts: 123
Joined: Sun Jan 17, 2010 12:15 am
Location: Sophia-Antipolis (France)

Re: Navigator

Postby roger » Mon Jul 07, 2014 7:38 pm

Hi Andy and Eric,
I have corrected some bugs in differential pilot to eliminate the duplicate calls of MovementStart and MovementStop.
Unfortunately, I have not been able to get it pushed to the git repository using Eclipse. team->pushUpstream
gives master[rejected - non-fast-forward].
Git is quite mysterious to me. Ideas?

Roger
roger
Moderator
 
Posts: 363
Joined: Fri Jun 01, 2007 4:31 am
Location: Berkeley, CA

PreviousNext

Return to EV3 Software

Who is online

Users browsing this forum: No registered users and 3 guests

more stuff