The Hardest Drive System To Program:

[Ether]

Originally Posted by Siri

I'd say Unicorn drive is up there. There's so many modes available: tank (uncommon if snake works), full crab (all wheels pointed same direction), snake (front & back point opposite directions), center spin, arbitrary center spin, each potentially with x and y-orientation.

You left out the most interesting one: full 3-degree-of-freedom control, like a mecanum or omni.

Originally Posted by rahilm

There are other types of swerves, including ones where each wheel is rotated independently (allows greater maneuverability and less skidding and much more complicated programming)

A swerve with four-wheel independent steering and wheel speed control allows the vehicle to be programmed to behave much like a mecanum, but without the traction limitations.

The procedure for calculating the wheel speed and steering angle for each of the 4 wheels is presented here.

For those who like to have a deeper understanding, the derivation of those equations is given here.

[davidthefat]

I just realized why more teams don't do swerve: it is hard to do the actually mechanical fabrication than it is to code it. I am not sure if my team is capable of producing such a drive system. Most of the mechanical guys are seniors and are graduating. My mentor will not let me learn any mechanical skills because he deems me as a too valuable of a programmer to be welding and stuff.

The most "advanced" drive we can fabricate will probably be a mecanum drive, possibly an omni drive.

But, if there are any teams that are willing to invite me to help program something more advanced, I will be glad to do it. I really have our doubts for next year. Chances are, we will go with our 6 wheel again (which I loath)

[PAR_WIG1350]

Originally Posted by Siri

I'd say Unicorn drive is up there. There's so many modes available: tank (uncommon if snake works), full crab (all wheels pointed same direction), snake (front & back point opposite directions), center spin, arbitrary center spin, each potentially with x and y-orientation.

Originally Posted by Ether

You left out the most interesting one: full 3-degree-of-freedom control, like a mecanum or omni.

The full 3 degree of freedom mode makes all other modes, except for tank which is inferior anyways and should be left out, redundant. That is not to say that redundancy is bad, Being able to lock into a single mode can compensate for oversensitive controls.

[David Doerr]

Ackermann steering was the hardest steering I've programmed, but also the most fun. If you're not familiar with it check it here: http://en.wikipedia.org/wiki/Ackermann_steering

The wheel steering angles aren't equal when turning because the wheel axles both have to point at the turning center point. With a hardware linkage, you're limited as to where your turning center can be located, but with a software "linkage" you can place the turning center wherever you like.

The HOT team used this in 2008 when I was a member of that team - a fitting drive and steering system for that year's theme. A separate control loop was used for each steerable wheel.

[Siri]

I'd say Unicorn drive is up there. There's so many modes available: tank (uncommon if snake works), full crab (all wheels pointed same direction), snake (front & back point opposite directions), center spin, arbitrary center spin, each potentially with x and y-orientation. The real trick is switching "modes" on the fly. Some have 2 speeds, either mechanical or software-based (less optimal but alright for some games/strategies).

We've been iterating 4-wheel swerve for 2 years (without tank mode). Heck of a ride. Go programmers!

The other possibility that comes to mind is Nonadrive. It's incredible, but I have no idea how complicated the programming is. (148, are you here?) Of course, there's always auto-balancing trackballs. Or triple-jointed six legged bots.

[davidthefat]

Originally Posted by Siri

there's always auto-balancing trackballs. Or triple-jointed six legged bots.

How legal would those be?


edit: I don't think the unicorn drive is hard per se, but it would be a pain to make it user friendly

[Robby Unruh]

To me, drive programming isn't hard, it's just really time consuming. Having to write all those limits to make sure you don't go over 1.0 or under -1.0, yelling at your electrical team to hurry up and give you the jaguar channels because you forgot to write them down (I never did ), then having to write all the functions like goLeft, goRight, goForward, etc. All just a total brainhurt, and at the end of the day you probably will have carpal tunnel. Man, those were the days.

[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.

[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).

[Ether]

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...

Welcome to CD. Your enthusiasm and self-confidence are admirable, but as you get older and gain experience you will find that those absolute statements have many shades of gray.

A software problem need not involve advanced math to be complex. It may involve just algebra, geometry, and trig... but require considerable skill and experience to set the problem up properly.

In the real world, many software people get paid to rewrite already working code, be it to make it more efficient, make it more maintainable, make it more re-usable, make it conform to a new customer-required (or company-required) coding standard or language, take advantage of the unique characteristics of a new processor, avoid royalties, or migrate away from a legacy language.

Rewriting library code just to be "elitist" is immature and counterproductive. But assuming that learning is the motivation, at least one good reason to re-write library code is to learn. Some people learn best by doing. Understanding and analyzing an already-solved problem and designing and coding a working solution is one way to do this. Comparing your solution to someone else's can be rewarding and provide deeper insight. It goes without saying that this learning process should not be allowed to jeopardize the project.

[Jimmy the Kidd]

Originally Posted by Ether

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

Omni wheels.

[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.

Originally Posted by Ether

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

Originally Posted by Jimmy the Kidd

Omni wheels.

I'm trying to understand what you mean by "Ackerman" in the context of an omniwheel vehicle.

Ackermann is a very specific type of front-wheel steering, used by automobiles, in which the vehicle turns around a point lying on the line which is colinear with the axles of the rear wheels.

Since an omni-wheel vehicle is holonomic, you certainly could mimic this behavior, but why would you want to? An omni-wheel vehicle can be given a "car-like" driver interface simple by disabling the strafe command - and using only rotate and fwd/rev commands.

[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 )