I'd like to know if there is a way to set the initial pose of the robot (ie location and heading), so that is is not supposed to be at the origin and aligned wit the X axis. The idea is to have a reference frame for the terrain defined in the most natural way wrt. terrain characteristic, and have the robot's navigator be initialized with a given pose in this frame.

Thanks in advance for any suggestion... including telling me I have not understood how it is supposed to work

I'm playing with the Navigator (leJOS version 0.6.0) and get erratic results. Sometimes, listeners are not called at the end of moves or waypoints reach. The robots stops at the right position but nothing else happens. Neither listeners are called, and isMoving() keeps on returning true, so my program gets stuck there.

Restarting the exact same program, without any change nor even recompiling it gives different behaviours : sometimes it works as expected, sometimes not.

In addition, I could noticed another misbehaviour : when arrived at wp location, the final rotation direction is not always optimal, leading to rotations greater than 180 degrees.

Which isMoving always returns true? Pilot? Navigator, RegulatedMotor? Please add calls to all of them and let me know what each level returns. Also what listeners are not called, the ones in the Pilot, Navigator etc?

gloomyandy wrote:Which isMoving always returns true? Pilot? Navigator, RegulatedMotor? Please add calls to all of them and let me know what each level returns. Also what listeners are not called, the ones in the Pilot, Navigator etc?

navigator's one only. The others all change to false as expected.

Once again, this does not occur all the times. I could observe it again a couple of minutes ago : the second time I started the program (without changing anything in it), the problem occurred. Previous attempt ran fine.

I could also notice that sometimes Navigator.stop() does not return, being stuck at _pilot.stop() statement, which does not return. I'm suspecting some monitoring variable used in different threads not being declared as volatile. For instance, Navigator._keepGoing is accessed by both Navigator and its inner class Nav and is not tagged as volatile. And I could see other flags used in a similar way without being declared as volatile. I remember lots of problem originated from this kind of situation when programming interrupt handlers on micro-controllers.

What I observe makes me think this could be related, since not occurring all the times and without obvious reason.

Hi,thanks for the feedback. Indeed it does look like there may be some issue with the inter thread communication here. The NXT version of leJOS did not optimize things to the extent that the EV3 is probably doing so it is likely that issues like this will turn up. I'm afraid I don't have the time to look into this at the moment, but perhaps you could dig a little deeper and try and work out what is going on. If all else fails you could try talking to this chap:

This is Porgy, Alan Turing's teddy bear. If any bear can help then this one should be able to!

Hi,What do you mean by "stuck" it is hard to imagine how getTachoCount can stick since it simply returns a value from shared memory, a possibility is that there is some sort of deadlock can you get a stack trace when things stick?

gloomyandy wrote: it is hard to imagine how getTachoCount can stick since it simply returns a value from shared memory,

I confess not beeing a specialist of shared mem et al., so didn't really know which kind of system level mechanism is behind. I was just suspecting that reading from specific hardware addresses could trigger some low level process which could be the deep cause of the trouble. I could see this kind of mechanism when working with micro-controller and electronics based systems. But if you say there is nothing which can lock when reading from this kind of shared mem, I'll go and look elsewhere.

gloomyandy wrote:a possibility is that there is some sort of deadlock can you get a stack trace when things stick?

I've already added traces here and there, but there is still room for more. But as you know, adding traces modifies the execution timeline by adding delays, and thus this is not really neutral when tracking time related problems such as dead locks or concurrency. Hope this will not be one of these situations where the instrumentation "cures" the problem and makes it very difficult to track.

Very interesting, especially if the deadlock detection works as advertised.

A potential problem is to have Ctrl-\ work on French keyboards, since the backslash is accessed in combination with the AltGr meta key :/ Maybe the function can be remapped to an other shortcut. I'll give it a look.