The Hardest Drive System To Program:

[davidthefat]

Just for reference sakes, was 1717's drive system swerve? I first thought it was an omnidrive, but I have also heard that it was a swerve system.

[WizenedEE]

Couldn't swerve get harder to drive because you have to wait for the wheels to get to the right position before it moves?

That is an interesting question though.. how close should the wheels be to the correct angle before you start driving?

For reference, I'm thinking of a three axis joystick where the robot simply moves in the direction the joystick is pointing, and turns with the joystick.

What other control schemes would there be for crab drive?

[Garret]

I am pretty sure 1717uses swerve.
Unless the problem lies in how it would be coded I don't think there would be much of a delay, well at least not anymore than a 6-wheel drive. I may be missing something though.

I think that you would have to really turn them slowly, less than 60 RPM to get a really noticeable delay. because you are only doing a partial rotation it seems like it would reach its position in less than .5 seconds at 60 RPM no matter what?

[davidthefat]

Is the weight of the system any issue? It does not seem to be much heavier than a 6 wheel drive with 4 CIMS.

[WizenedEE]

Originally Posted by Garret

I am pretty sure 1717uses swerve.
Unless the problem lies in how it would be coded I don't think there would be much of a delay, well at least not anymore than a 6-wheel drive. I may be missing something though.

I think that you would have to really turn them slowly, less than 60 RPM to get a really noticeable delay. because you are only doing a partial rotation it seems like it would reach its position in less than .5 seconds at 60 RPM no matter what?

No offense, but if you've ever driven the robot around much, a half second delay really screws with your mind. It's like the hot shower phenomenon, where you turn it up a little bit, nothing happens, so you go a little bit more and more until WHAM, the robot goes flying. However, if you program it right you'd only get a quarter turn at once maximum, so if they turn at any real speed, it'll probably be about .05 second delay, which isn't noticeable. Huh, full circle, I guess you're right

I will add on that if the program lets you start rotating the wheels before they're in position, it will go a little wonky until they get straightened out, which could be weird.

Originally Posted by davidthefat

Is the weight of the system any issue? It does not seem to be much heavier than a 6 wheel drive with 4 CIMS.

4 CIMS and then 1-4 banebots/what have you. And it's not like the metal doesn't weigh anything; for a 6WD, there's basically just two gear boxes, then the six wheels and chain, a swerve drive has four gear boxes (more if there's gearboxes on the wheel rotators), and then supports for each wheel. I'd estimate an extra 10-15 lbs for a swerve drive. Then again, I've never really even seen one

[Siri]

Originally Posted by davidthefat

Now, for the people that said swerve drive is hard to drive with, can you explain why? I see no reason why it would be hard to drive at all. IMHO it would be harder to maneuver a 6 wheel drive than a swerve

It's mostly just how to make it intuitive. There are so many options, and orientating them so they work reliably and understandably for the driver isn't always an easy task, depending on the driver, game/strategy, etc. I know for us, we haven't done much with true 3DOF control (my oversight, Ether), but there are still a lot of variables to play with.

Originally Posted by Josh Fox

That being said, I feel like having a set speed that the robot rotated at might not be the most efficient way of doing things.

I'm not sure though and I could be wrong, I'm not very experienced with the programming/control of swerve drives.

We've used fixed-speed spins on our swerve for 2 years. It's worked quite well for us, but our driver only really uses them in specific cases (aiming in Breakaway and turning the heck around in LogoMotion), with crab and snake covering most of the direction changing. I know a few other swerve teams do it this way, but others may well have variable speeds. Lots of options.

Originally Posted by WizenedEE

4 CIMS and then 1-4 banebots/what have you. And it's not like the metal doesn't weigh anything; for a 6WD, there's basically just two gear boxes, then the six wheels and chain, a swerve drive has four gear boxes (more if there's gearboxes on the wheel rotators), and then supports for each wheel. I'd estimate an extra 10-15 lbs for a swerve drive. Then again, I've never really even seen one

Our modules are 9.1lb each.

[Garret]

9.1 lbs seems heavy, are you including the drive motors, and other hardware, the modules my team made this year (but didn't use do to time constraints) weigh about 4.5 to 5 lbs a piece including mounting, and with the steering motor on each one is about 6 lbs.

[Gdeaver]

9.1 is for the entire unit that bolts on to the frame. Cim, rs540, and 256 banebot included.

[Garret]

That makes sense, it ends up about the same weight as ours if you were to take the CIM and gearbox and add it to ours.

[Jimmy the Kidd]

Last year, the team thought it was a good idea to combine Ackerman and omnidrive. We never got the programming right. Ever. We were supposed to be able to switch back and forth, but the omni drive was too sensitive or sometimes wouldn't even work.

[Ether]

Originally Posted by Jimmy the Kidd

Last year, the team thought it was a good idea to combine Ackerman and omnidrive. We never got the programming right. Ever. We were supposed to be able to switch back and forth, but the omni drive was too sensitive or sometimes wouldn't even work.

Are you referring to an omni drive using omni wheels, or mecanum, or swerve?

[aaronweiss74]

I'm going to have to agree with all those who said that programming the drive system really isn't difficult at all. The most common systems are ready-made and quite frankly, there's absolutely no good reason other than elitist-ness to rewrite them. If you take programming in FIRST as an opportunity to prepare for programming in the real world, you'll have to realize that you get paid to produce new work, not rewrite already working code. As the old saying goes, don't fix what isn't broken. As for an actual answer, it has to be something complex to the point where you require advanced math, many motors, and coordination of such motors. Or something like what's already been mentioned where you switch between some or many drive systems. Walkers, tripods, and things of that sort will always be more difficult than a wheel system though.

[Katie_UPS]

I found that programming penguins to make the robot move was pretty hard. Those buggers are stubborn once you run out of fish!




(couldn't help myself )

[aaronweiss74]

Originally Posted by Katie_UPS

I found that programming penguins to make the robot move was pretty hard. Those buggers are stubborn once you run out of fish!




(couldn't help myself )

I believe 1717 would beg to differ.

[Nikhil Bajaj]

Originally Posted by aaronweiss74

I'm going to have to agree with all those who said that programming the drive system really isn't difficult at all. The most common systems are ready-made and quite frankly, there's absolutely no good reason other than elitist-ness to rewrite them. If you take programming in FIRST as an opportunity to prepare for programming in the real world, you'll have to realize that you get paid to produce new work, not rewrite already working code. As the old saying goes, don't fix what isn't broken. As for an actual answer, it has to be something complex to the point where you require advanced math, many motors, and coordination of such motors. Or something like what's already been mentioned where you switch between some or many drive systems. Walkers, tripods, and things of that sort will always be more difficult than a wheel system though.

The difficulty of programming a drive base is only related to how much work you want to put into it. Getting the bare minimum of functionality with any drive base is pretty easy, I'll agree, but you can always push, and push, and push the boundaries, even with a simple tank drive. Some things I have seen beyond just the basics in FRC:

-Traction Control (really helpful to a lot of teams in Lunacy)
-Automatic, precise turns (really great in Overdrive)
-Automatic straight driving code (also awesome in Overdrive)
-Automatic current-sensing based shifting
-Automatic anti-tipping code (Overdrive)

And those are still relatively simple, as those can all be done with just kinematics or simple PIDs with the right sensors. You could push still farther. If you integrate odometry and/or localization systems, you can start to do path planning and following. You can start integrating knowledge about system dynamics to better the path following. You can move up to state-space and non-linear control, and optimize your robot motion for speed and stability given actuator limitations. You can actually make statements like, "This is the fastest my robot can move across the field and keep the sway of my lift under a certain amount." And you can use that knowledge in an iterative process alongside your mechanical design to make better, faster, more stable, more robust robots.

Now, I'll admit, this isn't really a "programming" problem. The programming for any of those things is usually pretty easy (sometimes tricky), once you know what the algorithms should be. But it really can be pretty hard to figure out the algorithms. That's the challenging part of programming, anyways.

Robot drive control is an active research area for many people doing their Ph.D.'s in Mechanical, Computer, and Electrical Engineering (and Computer Science) and people are still pushing the boundaries further and further. A cursory glance at google scholar yields tons of papers with different control methods for something as simple as skid-steer and systems as complex as mecanum (mecanum is actually really hard to do the dynamics (not kinematics) for, because if you are doing the dynamics you have to model all the wheel slip/skidding).