1058's Field Oriented Drive

[AmoryG]

Originally Posted by CraigHickman

Wow. Your team should be incredibly proud, as that is one of the smartest drive systems I have seen in FIRST. Seriously good work.

Out of curiosity, what sensors did you throw on there? I'm guessing gyro and compass, possibly accelerometer, but I'd be curious to see how they interact, and what controls what.

The amazing thing is you really only need a gyro to do something like (beats me how you program an omni wheel drive using this implementation, never have done it or thought about).

If you know what angle you have to be (gyro angle) and the angle you want to be (controller) then you know your angle error. Your robot's turning speed should be based on that error.

But obviously it takes a lot of fine tuning to get something like what PVCMike's team has done work well. It may look pretty in the video, but our team did something similar in last years competition. The wheels of our crab drive would face the direction we pointed our joystick, and another joystick would control the direction our robot was facing. Unfortunately, it was a bit sloppy and the trailer made driving the thing horrific.

[jspatz1]

We have accomplished this same field oriented steering with our swerve drive this year, and it does indeed provide some advantage with this game. Drivers tend to do well the first time they touch the stick. Its so easy even a mentor can drive it! Nice to see someone else has done it too. Great minds think alike!

[JVN]

Very, VERY cool. In order to make a holonomic drive useful, you need to make sure the driver can utilize it. This usually means it needs to be intuitive for the driver to use. Your implementation is absolutely fantastic.

Our team opted to make the system mechanically intuitive, whereas you solved it with some GREAT software (this is where my coworkers would mock me for always opting for mechanical complexity instead of a "line of code").

Are you using a gyro for orientation? Does it still function after going over the bump? What are you bolting on top?

-John

[ICntIHaveRbtics]

Hey I just found this thread too! Thanks Mike!

Just putting it out there, as Brendan (BEEKMAN) said, they spent hours of time both at team meetings at at home working on this. Hours. They may have actually surpassed my amount of "FIRST dedicated time" (people who know me know that's like 75% of the hours I'm awake daily) to do this. So I just wanted to put a little more emphasis on that crazy dedication they had.

&& the frame that it's on right now isn't the frame we used. We transferred the electronics over to a new basic KOP frame and (of course) we have some PVC on top to keep balls from getting stuck on top.

Can't wait for GSR!

[Dale]

One of the biggest problems to overcome with this kind of system is gyro drift. The more turns and bumps a robot encounters the more the gyro and the code tends to drift in its understanding of where "North" (not magnetic north, just a consistent orientation) is. Noise on the analog line will also add to this...there's always noise.

When we tried doing this a few years back, with the old IFI system, we could only get good results for the first 20 seconds or so before the errors accumulated so badly as to cause the system to need recalibration. Have you noticed that to be a problem with the cRIO and it's better A/Ds? Is there a way for the driver to reset the definition of "North" if the gyros loose their way?

[PVCMike]

Originally Posted by Dale

One of the biggest problems to overcome with this kind of system is gyro drift. The more turns and bumps a robot encounters the more the gyro and the code tends to drift in its understanding of where "North" (not magnetic north, just a consistent orientation) is. Noise on the analog line will also add to this...there's always noise.

When we tried doing this a few years back, with the old IFI system, we could only get good results for the first 20 seconds or so before the errors accumulated so badly as to cause the system to need recalibration. Have you noticed that to be a problem with the cRIO and it's better A/Ds? Is there a way for the driver to reset the definition of "North" if the gyros loose their way?

From what I understand through testing Brendan and Brian also discovered that through out the 2 minutes and especially going over the bump the robot would lose its calibration. To solve this they have used some additional sensors (other than the gyro) to automatically re-calibrate the gyro every so often on its own. They have also programmed in a button on the joystick so you can position the robot and click the button to recalibrate which seems to work well too. Feel free to come by our pit at GSR (Team 1058 the PVC Pirates) and ask for Brian or Brendan and they'll be able to tell you all about it!

[artdutra04]

Originally Posted by Dale

One of the biggest problems to overcome with this kind of system is gyro drift. The more turns and bumps a robot encounters the more the gyro and the code tends to drift in its understanding of where "North" (not magnetic north, just a consistent orientation) is. Noise on the analog line will also add to this...there's always noise.

When we tried doing this a few years back, with the old IFI system, we could only get good results for the first 20 seconds or so before the errors accumulated so badly as to cause the system to need recalibration. Have you noticed that to be a problem with the cRIO and it's better A/Ds? Is there a way for the driver to reset the definition of "North" if the gyros loose their way?

The combination of the 12-bit ADC on the cRIO (versus 10-bit on the older IFI system) and the faster polling rate make gyros much less susceptible to noise.

Originally Posted by PVCMike

From what I understand through testing Brendan and Brian also discovered that through out the 2 minutes and especially going over the bump the robot would lose its calibration. To solve this they have used some additional sensors (other than the gyro) to automatically re-calibrate the gyro every so often on its own. They have also programmed in a button on the joystick so you can position the robot and click the button to recalibrate which seems to work well too. Feel free to come by our pit at GSR (Team 1058 the PVC Pirates) and ask for Brian or Brendan and they'll be able to tell you all about it!

What the degree/second rating of your gyro chip? If it's already a 300 deg/sec, you could measure the drift over time. Sometimes the noise is biased in one direction, and you can offset this just by adding/subtracting a coefficient at your software at regular intervals.

[Nadav Zingerman]

Isn't this just the functionality provided by the "Meccanum - Cartesian" block in WPILib (in LabVIEW) with a PID controlling the rotation input?

[Vikesrock]

Originally Posted by Nadav Zingerman

Isn't this just the functionality provided by the "Meccanum - Cartesian" block in WPILib (in LabVIEW) with a PID controlling the rotation input?

No, the system in the video implements field oriented control. This means that when the driver pushes the joystick straight away from them, the robot moves away from the driver, regardless of it's current orientation.

The WPILib Mecanum functions are robot-centric. Pushing away from the driver on the joystick will drive the robot "forward" which may be towards the driver, away from the driver, left-to-right, right-to-left or any direction in between.

EDIT: As we're not using holonomic drive this year, I only took a brief look at the new Mecanum Cartesian VI. Looks like I missed the Gyro Angle input terminal up on top. The system discussed in this thread appears to be a more robust implementation of the same concept.

[indubitably]

Originally Posted by Nadav Zingerman

Isn't this just the functionality provided by the "Meccanum - Cartesian" block in WPILib (in LabVIEW) with a PID controlling the rotation input?

Yes actually it is the same.
Our team did driver centric/field oriented drive code also. we had it done very early and I was surprised when i updated week five and saw the code just laying there.

Oh well it was a great learning experience and allows us to fine tune it much easier.

I thought everyone that did mecanum would have used that but judging by the posts on this thread i guess not.

[EgROS]

Wow! That is really impressive!!!!

My team is doing a field centric controll scheme but it is nothing like this. This is really amazing!

[BEEKMAN]

Originally Posted by Nadav Zingerman

Isn't this just the functionality provided by the "Meccanum - Cartesian" block in WPILib (in LabVIEW) with a PID controlling the rotation input?

Not really, for one, the WPICode (if you actually read their code, is labled as "experimental" and for programmers like us, we found the bugs quite easily).....so our system is 100% fool proof, will work every time, all the time. The gyro will never walk, making it a seamless system...and a lot of fun

[Cyberphil]

that is SICK!!!!!!!!!! Awesome Programming!!! Amazing job guys!

[Tom Bottiglieri]

Very cool. I was able to drive 190's 2005 robot, which implemented the same type of control scheme. I found it was extremely easy to just pick it up and start doing some really complex maneuvers within about 15 seconds of driving it. If yours is anything like theirs, you will be driving circles around all the other bots at GSR.

To echo some of the previous questions... what type of additional sensors did you use to re-zero the gyro? I can imagine some range finders picking up the wall, but that's noisy at best. It just seems like a chore to have the driver re-zero the drive base a few times per match.

Originally Posted by BEEKMAN

Not really, for one, the WPICode (if you actually read their code, is labled as "experimental" and for programmers like us, we found the bugs quite easily).....so our system is 100% fool proof, will work every time, all the time. The gyro will never walk, making it a seamless system...and a lot of fun

Now you've really spiked my interest! Do you mind sharing your method for keeping the gyro from walking? Are you re-zeroing with some kind of sensor off of the arena wall, or do you have a compass as well to aid the gyro in keeping a clean reading?