Sensors for mecanum wheels?

[bs7280]

We recently just got a prototype mecanum wheel platform working with a three axis joystick, and everything is working perfectly as far as being able to strafe, move forward backward, and rotate at the same time or independently or what have you.

The next step would be to get the robot working with the appropriate sensors so that "forward" is always the same direction relative to the driver, as right now forward is always the same direction relative to the robot.

So my question is, what sensors (Accelerometer? Gyro? Both?) would we need to be able to control the robot so that forwards is always relative to the driver?

[BBray_T1296]

You would likely need both. Our team tried it 2 years ago (field-relative controls), but we were never getting readings accurate enough to work super well, but that is probably our own fault, not the sensors'.

I had an idea to use a compass sensor to detect rotation, and as soon as the robot was enabled in a match, it set the "zero" for the controls, but a magnetic sensor like that would need to be far from magnets (like motors).

[ekapalka]

Believe it or not, there is actually a "typical" way to do this. It's called field-centric control, and is in fact so popular that it is included in the with the developing software (C++, Java and LabView, I think...) as an alternative to the more common robot-centric control. The only sensor needed is a gyro. Magnetometers haven't proven particularly successful for teams to use in competitions due to their high sensitivity (high enough to detect the earth's magnetic field -> high enough to detect the electronics on other teams robots). I'm not entirely certain how you would incorporate the accelerometer if you were going to use one... What language are you using?

[BBray_T1296]

Originally Posted by ekapalka

high enough to detect the earth's magnetic field -> high enough to detect the electronics on other teams robots

What if your driver-station console also included a stack of like 5 huge neodymium magnets to override everything else in the room?

Originally Posted by huge neodymium magnet warning:

***WARNING*** This is an EXTREMELY Powerful and VERY DANGEROUS Magnet!
The end user MUST USE SAFETY PRECAUTIONS when unpacking and using this magnet. Remove all metal objects within a 5 foot radius before unpacking. Magnets of this size and strength can pull metal objects to them when brought too close. Two magnets of this size can fly together with great force and can break bones.
Wear safety glasses.
Use heavy gloves.
*** DO NOT ALLOW CHILDREN TO PLAY WITH THIS MAGNET***.

[FrankJ]

I guess you wouldn't be using a hard drive in your DS?

[BBray_T1296]

Originally Posted by FrankJ

I guess you wouldn't be using a hard drive in your DS?

Nah, SSD.

Though I think if you have to evacuate all metal in a 5' radius, no electronics are safe...

[bs7280]

We are using Java on our robot. I ended up not using a generic method/class used for mecanum drive but instead made a class from scratch, which ended up working. And thank you to who said "Fieldcentric control" that was what I was thinking of! What gyro sensor should we buy to use with our robot?

[KrazyCarl92]

Originally Posted by ekapalka

Believe it or not, there is actually a "typical" way to do this. It's called field-centric control, and is in fact so popular that it is included in the with the developing software (C++, Java and LabView, I think...) as an alternative to the more common robot-centric control. The only sensor needed is a gyro. Magnetometers haven't proven particularly successful for teams to use in competitions due to their high sensitivity (high enough to detect the earth's magnetic field -> high enough to detect the electronics on other teams robots). I'm not entirely certain how you would incorporate the accelerometer if you were going to use one... What language are you using?

ekapalka is correct on which sensor is most commonly used successfully for field-centric control.

Most gryos actually sense for angular velocity while we are interested in the value for angular position. The code that retrieves the value for us performs the integration that turns the angular velocity reading into the position that we are concerned about. This matters because it is a source of drift in the gyro's angular position reading. It is important to reset the gyro's position value to 0 at the start of autonomous so that any drift that occurs while the robot is sitting on the field or between sitting on the cart and in its starting position on the field can be cancelled out. When we used field centric control in 2010, we also had a button for resetting the gyro in teleop so that we could zero the angular position reading if too much drift occurred throughout a match. Taking advantage of this anytime the robot was facing the proper direction in relation to the driver station helped keep the drift to a minimum and the driving experience as intuitive as possible.

[Caleb Sykes]

Originally Posted by bs7280

What gyro sensor should we buy to use with our robot?

I coded a field-centric mecanum drive last year, and the kit gyro seemed to work fine. After ~10 minutes of driving there was no noticeable drift. I suppose that you could always purchase a higher-precision gyro, but my opinion is that this is unnecessary.

We did not incorporate the accelerometer, and the code still functioned well. So I would say to not worry about that. As stated above, make sure to zero the gyro as soon as the robot enables.

[Brandon Zalinsky]

Gyro only. We started using field oriented drive back in 2010, here's a video of it in action. I would also encourage an encoder on each wheel if you haven't already done so, so you can stop as much drift as possible.

[bs7280]

What sensors and encoders did you use specifically?