Robot accuracy

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

Moderators: roger, gloomyandy, skoehler

User avatar
Arqetype
New User
Posts: 6
Joined: Wed May 31, 2017 8:06 am
Location: Belgium

Robot accuracy

Postby Arqetype » Fri Aug 04, 2017 8:55 pm

Hi,

Today I created a simple robot, using two motored wheels and a castor wheel. Making the robot describe a square (simply four times going forward for 50 cm and then rotating 90 degrees) it returned back to base give or take a few centimeters. It made me quite happy :D.
Although it seems that it doesn't perform accurately every time...

When I started checking out the arc method for the WheeledChassis, I was not so happy :( . The arcs made by the robot have a wider radius and a smaller angle than expected. The error margin is much bigger than I think is reasonable.
For the arc test I describe a Yin figure (part of the code):

Code: Select all

   double radius = 25;
   car.rotate(-90);
   while(car.isMoving());
   car.arc(radius, 180);
   while(car.isMoving());
   car.arc(-radius, 180);
   while(car.isMoving());
   car.arc(-radius*2, 180);
   while(car.isMoving());
   car.rotate(-90);
   while(car.isMoving());
   LCD.drawString("X: " + car.getPoseProvider().getPose().getX(), 0, 1);
   LCD.drawString("Y: " + car.getPoseProvider().getPose().getY(), 0, 1);
   LCD.drawString("H: " + car.getPoseProvider().getPose().getHeading(), 0, 1);

That should take the robot back to its starting position. But it is off by several centimeters, up to 15 at times!
The pose at the end is also off by a few centimeters: X: -2.19, Y: 1.62, H: 0.16
With the travel and rotate methods, the pose values are far more accurate.

Am I expecting too much of my EV3? Or am I missing something obvious? Has anyone performed such tests? What was the result? What did you do to improve your robot or program?
Any ideas, help or input is much appreciated.

Arq

PS: I did the same tests with a robot with tracks, the results were similar: travel and rotate are pretty accurate, arc is not.
Arqetype, Pixar aficionado

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

Re: Robot accuracy

Postby gloomyandy » Fri Aug 04, 2017 9:49 pm

What sort of surface are you running the robot on? Which wheels are you using (A picture or even better a video of your robot always helps). The type of surface that the robot runs on can make a huge difference to the accuracy of movements, in particular the "nap" of a carpet can have a big impact. It would be good to see a video of your robot in action. You may also want to experiment with different surfaces.

It is very, very hard to get good results for robot positioning using just odometry (which is what you are doing). Basically the further you move the more error you accumulate. In your first test the robot has moved 200cm (four sides of a 50cm square), but in the second test the robot will move 25*pi + 25*pi + 50*pi which is 314cm so you would perhaps expect to see a larger error.

The acceleration and velocity that you are using will also impact how accurately movements are made. High values of either will make it more likely that you will get wheel slip, or simply make requests that the motors are not capable of performing. Similarly very low speeds may require the inner wheel of a robot making an arc (especially ones with a small radius) to move very slowly which may not be possible. So you might want to experiment with setting lower (and higher) values for these.

Oh and it is probably better to use the waitComplete() method to wait for the movement of the robot to finish rather than simply spinning on the return of isMoving(). This will free up more cpu which will probably help a little with accurately tracking the robot position.

As I mentioned above using dead reckoning/odometry will almost always result in the accumulation of errors. Even the construction of your robot may contribute to this, things like how the castor can move and how rigidly the wheels are mounted (so that things like the distance between the wheels can not change while the robot is moving, it is possible for a LEGO wheel to slide along an axle over time). Take a look at the following article which shows how much the tracking of a robot can drift even when using an almost ideal surface:
https://lejosnews.wordpress.com/2016/02 ... ile-robot/

Also take a look at video that is part of this article (near the end) which shows how quickly errors build up when operating on typical floor surfaces within a house:
https://lejosnews.wordpress.com/2017/07/15/slam/

Dealing with these sorts of errors has been one of the core areas of robotics for a long time, there are lots of papers out there. The great thing is that Mindstorms gives you the chance to experiment with them using a LEGO based robot! Be sure to update us on how you get on!
leJOS news https://lejosnews.wordpress.com/

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

Re: Robot accuracy

Postby gloomyandy » Sat Aug 05, 2017 5:22 am

One other thought, the WheeledChassis is pretty new, it may be worth trying the older DiffernetialPilot to see how that compares.
leJOS news https://lejosnews.wordpress.com/

User avatar
Arqetype
New User
Posts: 6
Joined: Wed May 31, 2017 8:06 am
Location: Belgium

Re: Robot accuracy

Postby Arqetype » Sat Aug 05, 2017 7:03 am

Hi Andy,

Thanks for your thoughts and suggestions!

About the surface: I run my tests on the floor, wooden boards with tongue and groove. The joints are minimal. Let's see if I can find something even smoother of that size.

Thanks for the tip to use waitComplete. I will try that for sure.

I had seen the 'slam' video recently (awesome!). It made me accept the build up of errors, which I experienced in the square test. But the results of the Yin test were still disappointing. But as you point out, the robot runs quite a distance. And more importantly the Yin test uses a combination of forward moves and rotations. The square test shows that traveling is always more accurate than rotating. In the Yin test the robot is rotating all the time.
I even suspect that the batterypower is of importance. The funny thing is that it influences rotations more than straight moves. That's why I display my batterypower with all my runs. I probably need to take my testing to the next level, getting some decent logs and a video :)

I will look at the DifferentialPilot as well and compare the results.

I'll be back!
Arqetype, Pixar aficionado

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

Re: Robot accuracy

Postby gloomyandy » Sat Aug 05, 2017 11:51 am

Battery voltage may have an impact but that is much more likely if you are using high speeds or accelerations. In general the motor control code should handle variations in voltage and motor loading. If you are seeing battery voltage having an impact then I would certainly be looking closely at the velocity and acceleration settings. An interesting point with this is that because a rotate on the spot turn drives both motors at the same speed (but in different directions) then problems with not being able to reach the target speed or match the requested acceleration profile will be minimal (because it will probably impact both motors in the same way). However when following a curve this will not be case as one motor will run slowly (and will almost certainly reach the target speed), while the other will be turning faster (and may not reach the target speed).

The other thing about your arc test is that you are making turns in different directions, in the square test you always turn the same way. So if your robot has a built in bias to turn in one direction it may be hidden in the square test. Have you tried running the square test in the other direction? Same with the arc test, try running it the other way around and compare all of the results. If you really want to go to town take a look at this:
http://www-personal.umich.edu/~johannb/ ... mbmark.pdf
leJOS news https://lejosnews.wordpress.com/

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

Re: Robot accuracy

Postby gloomyandy » Sat Aug 05, 2017 12:38 pm

Oh and good luck with the tests. Looking forward to seeing the results. Trying to understand why a robot does what it does is not easy, can be oh so frustrating but can also be rewarding, educational and addictive! Of course once you understand what is happening, you then have the even bigger problem of trying to work out a way to fix it!
leJOS news https://lejosnews.wordpress.com/

Aswin
leJOS Team Member
Posts: 310
Joined: Tue Apr 26, 2011 9:18 pm
Location: Netherlands
Contact:

Re: Robot accuracy

Postby Aswin » Sat Aug 05, 2017 2:34 pm

When making arcs there are centrifugal forces on your robot coming from one side. This can have an effect on your wheels. The outer wheel may compress a bit. Or the point where the wheels touches the ground may shift ( to the outside of the arc). This all can have an effect on the accuracy of the robot. These effects are not there when rotating or traveling.
To make a robot precise you best have a stiff frame, wheels that do not compress easily, a narrow contact area between wheel and ground, no gearing, short axles and a low centre of gravity.
As Andy said you should also carefully choose speed and acceleration.
My NXT blog: http://nxttime.wordpress.com/

User avatar
Arqetype
New User
Posts: 6
Joined: Wed May 31, 2017 8:06 am
Location: Belgium

Re: Robot accuracy

Postby Arqetype » Sun Aug 13, 2017 10:12 pm

Thanks for your valuable input. I even read the paper of the University of Michigan, Andy, which indeed provides a good insight in the perceived errors as well as solutions for them. The most important tip was to perform my tests in two directions: clockwise and counterclockwise.

Learnings
Performing several tests (straight line, turns on the spot, the already mentioned square and yin-yang) I learned a few things:

- travel is pretty reliable
When using the travel-method (moving in a straight line) errors are extremely small, less than 1 mm on a 3000 mm run! Increasing or decreasing the speed has no impact on the accuracy. As long as some acceleration is set. I used 5 as default. Changing the acceleration from 1 up to 10 seems to have no impact on the accuracy either.

- drift
Some robots tend to drift to one side when running a straight line. This can have two causes: a difference in the motors or a difference in the wheels. It can be solved by adding a drift factor which adjusts the wheeldiameters of the robots. It's a small factor like 1.002 or 0.997.

- rotations are not reliable
When using the rotate-method troubles start. In my rotation test the robot turns 180 degrees 10 times. Sometimes it ends up with practically the same heading, but more often it is off by as much as 35 degrees. That boils down to 7 degrees on a 360 turn. That is 2 percent!
Changing any of my parameters (wheelbase, rotation speed, acceleration, drift) doesn't really help so far... I need more time to investigate this further.

- 'move memory'
I did notice this: when performing a straight line after a rotation the robot tends to rotate a little bit further before moving straight ahead. It seems like the wheels 'remember' which way they were moving. In my experience this is the real reason for the inaccuracy in my square runs. But I have no idea how to solve this in the software.
I have a video here https://vimeo.com/229252359

- take arcs lazily
To get arcs working it is important to slow down. Using the angular speed, one just has to realise that 90 degrees of an arc with a radius of 100 cm results in a distance of about 157 cm. So an angular speed of 90 is simply impossible to achieve. In this case I would recommend an angular speed of 6. (recommended linear speed = 10 cm/sec; 157cm / 10 cm/sec = 15.7 sec; 90deg / 15.7sec ~= 6deg/sec)

- angle is the culprit
Using this insight I managed to improve my Yin/Yang figure. The arcs are nearly perfect now. It's only the angle that falls short (5 cm on a radius of 50, also too much for my taste). As this happens in both directions, I'm convinced that it can be improved. I have no idea how to improve it yet...
Arqetype, Pixar aficionado

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

Re: Robot accuracy

Postby gloomyandy » Mon Aug 14, 2017 3:05 am

The rotation memory is almost certainly due to two things...
1. You are using a caster wheel, this will almost certainly be causing problems. If you can try and get hold of the ballbearing caster provided with the LEGO edu kit, this is better but not perfect. You can also use the omniwheels they seem to work well.
2. backlash/slop in the gearing of the LEGO motors. Basically you can turn the motor for several degrees before the wheel will actually move (as the gears mesh then unmesh). After a rotate operation one motor will be set with all of the gears meshed perfectly ready to rotate in the direction of travel, but the other will have them all set for the opposite direction and so when you start both motors turning one wheel will start to rotate straight away, but the other will be delayed by a small amount and as a result the robot will rotate a little before it moves.

A similar thing may be happening with your rotations. When leJOS moves motors it will try very hard to follow your requested acceleration and velocity requests. As a result there is a chance that the wheel will not stop dead but will overshoot, leJOS will then correct this error by rotating the wheel slightly in the other direction. This can result in the above backlash/slop in that if a wheel has overshot and has been reversed the gear train will now be in the "wrong" position for the next move as a result the robot will rotate either too much or too little. Using a slow acceleration can help with this, but do not use too low a target velocity as it is very hard to accurately maintain low speeds. Oh and once again your caster will probably cause problems if you try and rotate first one way then the other. Also using a wider wheelbase will probably help make turns more accurate.

I'm afraid that you are discovering what many, many people have already found out. Using odometry does not give good results! Trust me I've spent a huge amount of time trying to make it better! Others have also spent a long time on this but at the end of the day unless you have a perfect motor, with perfect wheels a perfect caster set up (with just the right weight distribution) and a perfect surface to run on, then you are going to accumulate errors and chances are they will not be predictable.

So what is the solution. Well try and get things to work as well as you can, but then instead of relying on accurate turns use something like a gyro to track the actual turn made (linear movement is usually reasonably good, but a gyro can also help track drift). Don't try and use the gyro to make the turns more accurate. Instead track the robot position/pose and correct the error on the next turn/move. If you can use something like SLAM to use external objects to navigate by.

Take a look at the following, they may help they also track my journey of trying to get good robot motion:
https://www.youtube.com/watch?v=NJ_6Qm_BNFI
https://www.youtube.com/watch?v=IMI63k5W3sU
https://lejosnews.wordpress.com/2014/10 ... ms-part-1/
https://lejosnews.wordpress.com/2014/10 ... ms-part-2/
https://lejosnews.wordpress.com/2016/02 ... ile-robot/
https://lejosnews.wordpress.com/2017/07/15/slam/
leJOS news https://lejosnews.wordpress.com/

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

Re: Robot accuracy

Postby gloomyandy » Mon Aug 14, 2017 7:02 am

Oh and when it comes to make a turn you should also think about the tyres you have chosen to use. The ones in your video have a relatively large contact patch with the floor. This is good for going straight, but think about what will be happening when you ask the robot to turn on the spot and the path you expect the inside edge of the tyre to make v the outside edge. With a narrow wheelbase like the one you have I think you will find that the ideal path of each wheel will have a significantly different velocity for the inside of the tyre to the outside, this is obviously not going to happen so some part of the tyre will in effect be skidding. You will probably find that a tyre with a narrow ridge around the centre will turn better (but it may not hold a straight line to well!). Again a wider wheelbase will help with this.
leJOS news https://lejosnews.wordpress.com/

User avatar
Arqetype
New User
Posts: 6
Joined: Wed May 31, 2017 8:06 am
Location: Belgium

Re: Robot accuracy

Postby Arqetype » Tue Aug 15, 2017 6:58 am

At first I also suspected the caster wheel to be the cause of the extra turns. So I spent some time closely observing the motions. My conclusion is that the effect is minimal. The 'outside' motors really pull the robot a bit further. I don't see this happening when I keep the robot in the air, without any friction on the motors. So what you say about the gears meshing makes sense to me. Any thoughts on how - if at all - this can be fixed, monitored or controled somehow? Like a trick to 'unmesh' the gears?
The ballbearing caster and gyro sensor are on my wishlist :)
Arqetype, Pixar aficionado

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

Re: Robot accuracy

Postby gloomyandy » Tue Aug 15, 2017 8:57 am

It might be possible to "pre-load" the motor position by applying a small motor current (by using setPower) to each motor after a turn. Basically using sufficient power to move the motor and gears but not move the robot. But I'm not sure how well it would work. But you may find you get better results by using different tyres and a wider wheelbase (I would certainly try those first). Alternately don't make on the spot turns always use an arc style turn? I think that is what folks in things like FLL do if they need really accurate turns. I suppose if you know that you will be going to turn abd then move straight you could try making a slightly less than 90 degree turn and then assume that the robot will move the extra small amount when you start the straight move (if you are using a pose to track position you will have to adjust the pose to allow for this).

To test if your caster is causing problem do the following. Move the robot in a straight line for a short distance. Hold it in place and rotate the caster 90 degrees to be in the same position that it is in after a turn. Then move the robot again in a straight line. If the robot turns a little then the caster will be causing it.


But I think you need to step back and ask yourself why do you need such an accurate turn? What is it you are trying to do? If your robot will end up moving on a real world surface like a carpet, or that will probably have small bumps or things like threshold strips then these will have a much bigger impact on moves than the small errors we are talking about here.

If you do get a gyro and are prepared to do a little more work than simply plugging it in, then something like the BNO055 will give much better results than the LEGO one!
leJOS news https://lejosnews.wordpress.com/


Return to “EV3 Software”

Who is online

Users browsing this forum: No registered users and 1 guest