Take a step back. Do the following....1. Get a smooth large piece of card, tape out a square on it. Make this square as large as you can as it is easier to see errors that way.2. Create a program that instructs the robot to follow that square path. Make it stop at each turn by calling wait for stop. Use only the two parameter version of the move commands to minimise what happens at a turn. The program should do nothing else, no sensor reading, no logging nothing else at all. 3. Place the robot on the track and observe how it follows the course.

If you see errors try lowering the speed of your robot and the acceleration. Doing this will reduce the chances of wheel slip and other issues. The speeds you are using are actually pretty high. You should use a low enough acceleration such that you can actually see the robot accelerate. Use low values to begin with, you can make an accurate robot faster.

Test your robot and film it. If you are still getting very different results on the first run to what happens on the second run etc. then there may be a problem with the leJOS classes. At the moment it is impossible to say what may be happening. Make sure that you start each run with the robot in exactly the same place (Make a mark or use extra tape to allow you to be sure). If you are getting different results, post your video and your test program code.

If the robot makes the same moves on multiple runs, but it does not follow the course very well, you can probably tune things a little by adjusting the wheel diameter (to adjust the distance moved) and the offset of the wheels (to adjust how much the robot turns). As Aswin has said a tracked robot is very tricky to get to work well, this is especially true on a surface like carpet which will present different amounts of friction as the robot moves around on it.

Take a look at this...https://lejosnews.wordpress.com/2016/02 ... ile-robot/Notice that I use a board that has a very good surface to it, that I do not use tracks, that the robot moves relatively slowly and that you can see the robot accelerate when it starts. I needed all of this to make the odometry as good as I could get it to be, but even then you still get errors accumulating!

Yep, I agree with you, that's why I wanted to check if my programs are correct using poseprovider, even there are some errors due to sufrace etc. But in this case, when code was executed as it was designed, robot moved really well with only minor errors, so from my point of view, the reason of not working was related to the code itself. Do you agree with me?Anyway, I really would like to construct the robot which executes the code I described in previous posts, so I'll try to calculate robot's positions from chassis or pilot movements. Your comments and suggestions are really welcome

Sorry I don't agree with you at this stage. So far I've not seen anything that is conclusive. It would be very unusual to have a robot that works well on the first run but not on others (even if there is a problem with the code). So I think you need to have a more consistent test (like the one I outlined above). One that we can see the results of easily and if there is a problem reproduce. I know it is frustrating not having this stuff just work, but if we do not understand what is happening we can't really help, we need your help if we are going to be able to help you.

No problem, I'll do the tests with squared-shape travel and will share a video. Still, as my purpose is to learn programing java and lejos, I am more oriented to the process, not just to get the final result - a robot that moves precisely - so it would be even better for me to do more coding.

Again, the brick was restarted before test. All runs were made from the brick, except one (after the longer pause in the video). You can notice that robot makes incorrect moves in various positions. Two successful runs were at the beginning, and one in the middle. Strange, isn't it?

Hi Aswin,looking at the MovePilot code it seems to me that it is possible for isMoving to return false before the notification to any move listener has been called. This could potentially result in the next turn being started before the pose provider has updated the current pose. Not sure if this is what is going on but it could be. Can you see any problem with changing code in the MovePilot isMoving method to simply return the current value of _moveActive?

You might be right that isMoving can cause problems, especially when the motors have to deal with high friction and low speeds and are prone to a stall. I think technically there is no problem to change the internals of the isMoving method. It does however change the meaning of isMoving. I could also add another method, something like hasActiveMove to keep the definition of isMoving the same for motors, chassis and pilots. What do you prefer?

BTW, the DifferentialPilot and the OmniPilot have the same kind of implementation of isMoving as the MovePilot so they should be updated as well.

Hi Aswin,I think the main problem is (as usual) one of threading. The problem is that the thread that will update the pose information (by calling movement stopped etc.) may not wake up and notice that the move is complete until after isMoving has been able to return false. This means that any program that is waiting for a move to stop (like the navigator) can end up getting a pose that has not been updated to the new position. So it seems to me that one way to fix this is to ensure that isMoving will not return false until the end of the move has been noted by the monitor thread, hence using the value of _moveActive. In theory all we are doing is delaying the return slightly. Do you see a problem with this? I don't see any real problem as there will always be a slight delay here anyway (even when using the return from the motors) as at the lowest level the state of the motors is only monitored every few milliseconds. I agree that if we do change this we will need to modify the other pilots as well.

An alternative would be to modify isMoving to make a call to movementStopped if it detects that the motors have stopped. However you would need to take great care with synchronization to ensure that we avoid lockups and double notifications.

I suspect that this bug may have been introduced some time ago when we switched from using a pure motor listener mechanism (which had all sorts of problems with double notifications and other threading issues), to one that uses a monitor thread. Basically this is yet another example of why the listener model although on the face of it simple and elegant is in practice complex and extremely error prone!

coming back to the discussion about problems related to navigation and pose provider few months ago, I tried to develop my own navigator and robot tracker and would like to share how it works. All calculations are done in PC, and a robot is provided with two inputs: turning angle and travel distance. Communication are established in both ways, the robot accepts commands and sends replies to server. That was a nice practice for me. You can find a video here:

As for beginner, everything was more or less challenging: to establish server and client connection to communicate both ways, use g graphics, redirect system out to jpanel and, of course, to remember trigonometry school course . I am trying to learn Java by myself, so every new thing takes time to figure out how it works, and it takes many trials and errors.