Localization of A Omni-Directional Robot
 

I have been looking around the web and couldn't find anything. I am trying to do localization, which is finding the location of a robot, on an omni-directional, such as an X-Drive or Mechanum Drive. I have encoders on all four wheels. If anyone can point me towards the formulas or the code that I can use to figure it out.
Thanks for all your help.

Re: Localization of A Omni-Directional Robot
 

Finding the correct speed for each of four mecanum (notice there's no h in mecanum) wheels, given the desired instantaneous vehicle motion (rotatation and XY translation), is called inverse kinematics.

The opposite problem -- finding the vehicle motion given the speeds of each of the four mecanum wheels -- is called forward kinematics. I discuss this briefly starting at the bottom of page7 of this document.

But even if all four mec wheels are always turning at kinematically correct speeds (which is a non-trivial problem), in the real world there will be factors such as roller axis free play, roller friction, carpet compliance, weight distribution, acceleration forces, etc etc which cause the actual vehicle motion to differ (perhaps substantially) from the predicted motion.

Then, on top of that, you would have to integrate the vehicle motion over time to get vehicle location and orientation... and the errors would accumulate.

So the question needs to be asked: how accurate do you need the vehicle location and orientation to be, and what distances and times do you have in mind? Depending on the answers to those questions, there may be a better solution than what you currently have in mind.

Re: Localization of A Omni-Directional Robot
 

Thanks A Lot,
I am trying to find a reasonably accurate position (+/- 6-12 Inches) on a 12x12 Foot Vex Field. I have a gyro that I can use for the heading and the match is 2 minutes long.
Thanks
vrcprogrammer

Re: Localization of A Omni-Directional Robot
 

Correct me if I'm wrong, but since mecanum wheel rollers, when moving forwards or backwards, may not spin predictably due to friction in the rollers, you may not be able to get any good precision out of them.

With something like killough, kiwi, or X-drive the rollers will be forced to spin since the wheels are actually angled, providing more deterministic roller movement.

Also, 2 minutes? I doubt you would get that kind of precision over that time period. Any errors in angle measurements have a huge effect on positional measurement.

If your gyro drifts even 2 degrees, your positional error over 5 feet would be that's sin(2 degrees)*5 ft. Which is just over 2 inches already. I imagine you plan to drive your robot a lot more than that.

If you really need this over a 2 minute time period you may want to think about having the robot drive itself into a wall or corner to re-zero its measurements at some point.

Re: Localization of A Omni-Directional Robot
 

Thanks, Do you have any ideas? One idea that I had was to have 2/4 wheels to keep track of X-Y position. Any ideas/formulas that could help me impliment this.
Thanks.
vrcprogrammer

Re: Localization of A Omni-Directional Robot
 

LIDAR from a Neato vacuum cleaner is another option if you are open to other ideas. If you Google or eBay or Amazon the terms "neato lidar" you will see what I am thinking of. Here is a link to some on eBay. Some vendors even offer code and instructions on how to talk to these devices.

http://www.ebay.com/sch/i.html?_from...dar&_sac at=0

-Hugh

Re: Localization of A Omni-Directional Robot
 

Thanks, but I will have variable objects blocking my robot, so only sensors that are focused on the robot would work.
If anyone has any ideas, that would be great.
vrcprogrammer

Re: Localization of A Omni-Directional Robot
 

Do you want the sensors to be mounted on the robot (and thus sensing the environment - floors, arena boundaries, etc.), or fixtured to the environment (and thus sensing the presence and/or location of the robot)?

Re: Localization of A Omni-Directional Robot
 

I would need to have the sensors mounted on the robot.
Thanks

Re: Localization of A Omni-Directional Robot
 

I dont know what the capabilities of your controller is (roborio or other controller?) But if you have usb ports you might be able to use this.

Re: Localization of A Omni-Directional Robot
 

I really like this idea, is there any way to use this with wheels/encoders. Thanks.

Re: Localization of A Omni-Directional Robot
 

I am trying to design/think of the program for a set of wheels, for X-Y positioning, and I am stuck on getting the formulas. Can anyone help me, or is a 4 wheel design better.

Re: Localization of A Omni-Directional Robot
 

You'll spend the same amount of money on the vacuum as you will on one of these

Except the RPLidar is built for hobby robotics, already functional, and already has solid ROS support. You wouldn't get anything done in VEX since it has it's own motor and isn't a VEX part, but it's a good option for a personal robot or for the Roborio, and again, same const as the neato, but you don't need to take a vacuum apart and risk breaking things.

Re: Localization of A Omni-Directional Robot
 

This all sounds great, but I need this to be on a vex robot, so does anyone have a way to do this with vex edr (vex robotics competition) parts.
Thanks
Vrcprogrammer

Re: Localization of A Omni-Directional Robot
 

What about 2 omni wheels placed perpendicular to each other that drag along the floor. As the one in the y axis moves, it gives you your position in the y axis and the same as with the x. Although I do not know how the code might work, to make this more reliable you could add a gyro to correct for any kind of rotation.

As for the mouse idea, I don't have any info on it other than what's in the post. It's on my to do list but that's a mile long not to mention school work.

Re: Localization of A Omni-Directional Robot
 

That's true only if there is no vehicle rotation. If there is going to be vehicle rotation, you need either a) a gyro, or b) a third follower wheel... and you'll need to integrate (vector sum) the vehicle movements.

You might find this post of interest (and also the rest of the post in that thread).

Re: Localization of A Omni-Directional Robot
 

I corrected my post to include the gyro. I was thinking of it in my head but forgot to add it in. The third follower wheel for rotation is a good idea as well.

Re: Localization of A Omni-Directional Robot
 

This all looks great, how would you recommend using a gyro with the three follower wheels.
Thanks

Re: Localization of A Omni-Directional Robot
 

Well first of all, what is your issue with simply putting encoders on all four of your wheels? If you are going for the X/killough/omni/whateveryouwishtocalllit drive you already have TWO sets of "mouse wheels". Theyre your drive wheels! Even without the gyro you can get rotational odometry. (I have tried this when we were prototyping swerve code on a vex base and it wasn't all too terrible. A gyro is still better, but odometry can determine your angle)

Ether's papers on controlling an omnidirectional drive apply in the reverse direction in order to find your movement based on encoders.

Re: Localization of A Omni-Directional Robot
 

The biggest issue with this method is wheel slippage. Say I accelerate to quickly, or I get into a pushing match and my wheels start to spin because they lost traction. All of a sudden my robot thinks it's 5 feet further forward than it actually is. By getting feedback from unpowered wheels or a laser, you know that whatever movement you detect should in theory be the exact actual movement of your robot.

Re: Localization of A Omni-Directional Robot
 

This is the exact reason I am trying to use the follower wheels, but I would like a way to use the gyro/ultrasonics, to check the data, is this needed, or are the followers accurate enough?

Re: Localization of A Omni-Directional Robot
 

If you have only two followers, you will need a way (such as a gyro) to get rotation.

If you have three followers in the correct configuation, you can get rotation from the follower encoders. If you want, you can compare that to a gyro reading to see how well they agree.

My guess is that a properly installed, calibrated, and initialized gyro will give better accuracy in most cases.

Re: Localization of A Omni-Directional Robot
 

As far as an accurate gyro, the navX MXP plugs into the RoboRIO MXP port, features automatic gyro/accelerometer calibration and sensor fusion, and has a yaw drift of about 1 degree per minute when moving (.2 degrees/minute when still) - which exceeds the quality typically achievable w/the gyro in the Kit of Parts. The navX MXP is being used by many teams for accurate field oriented drive and many are able to get it working in a few hours including installation. The navX MXP interfaces to the RoboRio via several protocols including SPI, and has RoboRio libraries in C++, Java and LabView, as well as sample program code, a 3d-printable enclosure and it's open source hardware/software. Please feel free to send me a private message if you have any questions about that.

I think it'd be helpful and educational for many FIRST teams if there were to be a documented project (w/hardware diagram, sample code and statistical results) which details accuracy findings w/the localization approach using encoders and follower wheel you're looking into. If you're interested in taking on that scope of a project, I'd be happy to give you a navX MXP board for free that you can use for this work.

I realize this may not work because you're asking about VEX, but if it sounds interesting to you let me know, and I can try to help w/some advice on getting it to work on a Vex robot.

P.S. I was speaking this year with a mentor on the "Thunder Down Under" (team 3132 from Australia, they made it to Einstein this year), and they were using a similar approach (encoders for X/Y displacement, navX MXP for rotation); I don't have any statistics on how well that worked, but I know it's been attempted and believe it appears promising. Of course, it all comes down to your accuracy requirements, as Ether said earlier....

Re: Localization of A Omni-Directional Robot
 

mount an accelerometer and take the second anti-derivative of the data and that will give you the position in the x and y axis off of origin.

Re: Localization of A Omni-Directional Robot
 

You need to be careful with posts like that.

Someone might take it seriously.

Re: Localization of A Omni-Directional Robot
 

https://www.khanacademy.org/math/int...e-acceleration

thats how gyro's calculate the the position from rate, although that might get a bit tricky(er) taking the second riemann sum , would have to come up with way to find the constant definitively.

Re: Localization of A Omni-Directional Robot
 

While the theory is sound, this is impractical with an accelerometer. Even the integration of gyroscope signals accumulates error over time due to the limitations of the noisy signal and the discrete Riemann sum. Accelerometers are even noisier, from any vibrations, and also easily saturated. You also have to deal with errors in orientation, so computing just velocity, let alone position, from an accelerometer signal is not that easy.

Re: Localization of A Omni-Directional Robot
 

dang thats a shame, I was hoping we could use that for autonomous ::ouch::

Re: Localization of A Omni-Directional Robot
 

For 15 seconds, you can possibly get away with it, depending on how precisely you need to hit your mark (1/4" or 6") to succeed. It would probably be better than "50% power for 3 seconds" but nowhere near as good as encoders on the wheels.

Re: Localization of A Omni-Directional Robot
 

Here's a really great youtube video that provides some good insights into the issues that occur when attempting to derive displacement (position change) from acceleration (this discussion is at 22:32 into the video). It's telling to note that at one point in the video (at 26:30) when discussing double integration, the speaker says "... double integrate and pray".

[As an aside, I think this video is really instructive in general about MEMS inertial sensors/magnetometers and sensor fusion like that used in navX MXP. If you're interested in this kind of thing, I think it's worth watching the entire video.]

As discussed in the video, the errors are not only due to accelerometer noise, but also because gravity must be removed from the acceleration data, and there can be errors in this process too.

This still leaves this question: how accurate is it?

The latest firmware of the navX MXP implements the algorithms described in this paper: "Implementing Positioning Algorithms Using Accelerometers", and was used to run some tests. Note that this paper also discusses that this approach is not expected to be high accuracy.

We're still reviewing all the data, but with the navX MXP we see times when the displacement calculated is accurate to a centimeter, but at other moments in time the displacement calculation is not at all accurate (in fact in certain cases instead of indicating forward motion, the displacement is in the opposite direction, this is seen even in the integrated velocity data). So this is not promising for use in Autonomous.

However, there are a few things to keep in mind as we move ahead. First, at some point in time accelerometer technology will likely be sufficient/affordable to make this viable. We're definitely not there yet, though.

Second, since the first derivative of acceleration is velocity, and there will be less error in velocity estimates since integration only occurs once, the velocity estimation data may be useful for certain things. For instance, velocity estimation could be used to detect wheel slip, in case one wasn't able to measure the motor current to do that. Velocity estimation could also be used to attempt to maintain a consistent velocity even when wheel slippage is occurring. There are surely many applications for velocity estimation beyond that.

Third, given that sometimes the accelerometer displacement data is valid, this indicates potential for additional sensor fusion. Given that the encoders are widely believed to be more accurate at displacement estimation than accelerometer-derived displacement - but encoders are unreliable during cases of wheel slip - a reasonable approach (I saw this suggested awhile ago on ChiefDelphi) may be to detect wheel slip, then verify the current inertial velocity estimates are realistic and if they are fall back to the accelerometer-based displacement data during this time. In cases where both are deemed unreliable, a best guess based upon interpolation from last valid estimates of velocity would be required. Sounds kinda complicated, but sounds plausible enough that it's worthy of some research.

If there's more interest in this area of research, please feel free to private message me.

Re: Localization of A Omni-Directional Robot
 

I hate to plant this seed in someone's brain, but it MIGHT be possible to have a robot go from (x1, y1) to (x2, y2) using just an accelerometer. It is something I am investigating in my lab at college. Basically you construct the problem in terms of acceleration and the robot learns how to make the accelerometer read that acceleration. The idea is that if the robot gets so good at going x ft/sec^2 for any possibly x and can adjust from it's current acceleration a - > x in a reasonable time, then it is possible. However, as others have pointed out in this thread, error accumulates extremely quickly. This program will have to be flawless in its transitions.

It is a deeper investigation in my original project with a robot teaching itself how to follow a path given velocities. I am without a robot until I go back to college in August, however.

This project should be finished by next fall....with a paper submitted for publication sometime late next year.

Re: Localization of A Omni-Directional Robot
 

How are you dealing with noisy/unreliable signals? This has always been a problem in my experience.

Re: Localization of A Omni-Directional Robot
 

That's where it gets iffy. It relies entirely on 100% accurate sensor data as well as getting data as fast as possible. I was thinking about having *3 accelerometers and averaging them. I expect it get somewhat close to the target spot, but I wouldn't put money on it in a precision contest.

*I would like to have about 20 just to really solidify the data, but that is unreasonable. If I would do that, however, I would use a RANSAC algorithm to find the "mean" of the signals. Also, it'd look pretty silly having a tower of accerlometers on a robot that is 6 inches tall.

Re: Localization of A Omni-Directional Robot
 

I'd wager for typical FRC level precision you'd always be happier with encoders (possibly on non-driven idler wheels) and gyro.

Re: Localization of A Omni-Directional Robot
 

Or a vision program that solves for the pose of a static object in the field, which gives you your position on the field.

But yes, encoders and gyro would be the easiest, and probably the most accurate, approach by far.

Re: Localization of A Omni-Directional Robot
 

lol put a spinning radar satellite on your robot... :D

Re: Localization of A Omni-Directional Robot
 

There are sub-$100 LIDAR units like the LIDARLite which if put on a servo can scan the field at every 2 degree increment in about 2-3 seconds. Advantage is they are very fast, and can range up to 40 meters w/an accuracy of +/1 one inch. Unfortunately, the side panels of the FRC field are polycarbonate and most of the IR passes through, so getting a return on significant portions of the field is problematic. If the side-walls of a FRC field were IR opaque, this could potentially yield enough data to triangulate with, assuming the software were to know the field dimensions.