The Hardest Drive System To Program:

[davidthefat]

What is the hardest drive system to program?

[basicxman]

Any base drive system is not incredibly difficult to program. Programming an effective control system for a drive system is hard.

see:

Failure checking (state machine, redundancies)
Human error correction
Mechanical error correction


I really don't know what to answer your question with, everytime I think of a drive system I think of all the ways I could improve it with pieces of code - would be very difficult to pick a single one, and would require more context.

[mobilegamer999]

My opinion would be swerve drive.
Theres pre-made code in WPILIB already for Tank, Arcade, Mechanum and one other I believe. But swerve is the only one out there that requires pretty much completely custom code to get working.

[davidthefat]

My opinion would be swerve drive.
Theres pre-made code in WPILIB already for Tank, Arcade, Mechanum and one other I believe. But swerve is the only one out there that requires pretty much completely custom code to get working.

Can you explain swerve drive? Apparently, my understanding of the said swerve drive is actually "crab drive". Tell me WHAT it is, not how or anything like that.

[basicxman]

Tell me WHAT it is, not how or anything like that.

To be fair, your original post was only


What is the hardest drive system to program?


--


my understanding of the said swerve drive is actually "crab drive"


Crab drive is a specific type of swerve drive, where there are four rotating modules.

[basicxman]

I would recommend reading this excellent white paper by Ian Mackenzie

http://www.firstroboticscanada.org/site/files/workshops/omnidirectional.pdf

[mobilegamer999]

Can you explain swerve drive? Apparently, my understanding of the said swerve drive is actually "crab drive". Tell me WHAT it is, not how or anything like that.

Each wheel module rotates along its vertical axis as well as rotating along the wheels axle (for movement which is usually helpful), so to go at a 45 degree angle, you rotate all wheels to 45 deg and then just drive all wheels straight.

[davidthefat]

Any base drive system is not incredibly difficult to program. Programming an effective control system for a drive system is hard.

see:

Failure checking (state machine, redundancies)
Human error correction
Mechanical error correction


I really don't know what to answer your question with, everytime I think of a drive system I think of all the ways I could improve it with pieces of code - would be very difficult to pick a single one, and would require more context.

Can you elaborate on your 3 points a bit more please?

[bladetech932]

In my opinion how you want to implement the drive will make the programming difficult. For example a competent programmer can program a swerve that can move the wheels forward and rotate them directly with a joystick but making a program that takes into account the position of the wheels relative to the closest direction to rotate and stops the wheels from moving till they reach the correct angle while taking into account the angle of the robot and the desired direction will make the programming more difficult. i have found the most fun is had trying to make an extremely complex drive train simple to use! Now with just the simple setup (aka. nothing unique) i would agree it would be the swerve because of the availability of prewritten code and for the difficulty in making the drive simple to use.

~Jon

[basicxman]

Can you elaborate on your 3 points a bit more please?

> Failure checking (state machine, redundancies)
If a sensor relating to your drive system fails, what is going to happen to your robot? A lot of teams run a separate task on the cRio that monitors for failures and then triggers a state change when a failure occurs. For instance let's say a gyro stops reading values, rather than making the robot spin in circles, the drive system would ignore gyro values.

Redundancies being increased reliability of a drive system, http://en.wikipedia.org/wiki/Redundancy_(engineering)

> Human error correction
How much money would you put on the fact that your driver can hold two joysticks at 50% throttle precisely? Probably not a lot.

> Mechanical error correction
Motors aren't made equal. Two motors of the same model will rarely go at the same speed. Using encoders and other techniques to correct this.

[davidthefat]

My opinion would be swerve drive.
Theres pre-made code in WPILIB already for Tank, Arcade, Mechanum and one other I believe. But swerve is the only one out there that requires pretty much completely custom code to get working.

Now, keep in mind, I have not used any prewritten code except for theses classes: PWM and Joystick.

[basicxman]

i have found the most fun is had trying to make an extremely complex drive train simple to use!

Precisely.

[connor.worley]

They're all fairly simple until you get to a full swerve drive. But even then it's just some control loops and a bit of trigonometry.

[davidthefat]

> Failure checking (state machine, redundancies)
If a sensor relating to your drive system fails, what is going to happen to your robot? A lot of teams run a separate task on the cRio that monitors for failures and then triggers a state change when a failure occurs. For instance let's say a gyro stops reading values, rather than making the robot spin in circles, the drive system would ignore gyro values.

Redundancies being increased reliability of a drive system, http://en.wikipedia.org/wiki/Redundancy_(engineering)


> Human error correction
How much money would you put on the fact that your driver can hold two joysticks at 50% throttle precisely? Probably not a lot.

> Mechanical error correction
Motors aren't made equal. Two motors of the same model will rarely go at the same speed. Using encoders and other techniques to correct this.


"Safe Mode": If triggers, switches to bare bone drive code.
Multiple sensors to "check" each other

We just used dead zones for the human error part

We didn't use the encoders because there was too much noise that I did not trust them enough to use it.

[davidthefat]

They're all fairly simple until you get to a full swerve drive. But even then it's just some control loops and a bit of trigonometry.

Joystick has a X and a Y axis; get the inverse tangent of the Y/X. You have your angle (of course, there is something to check if the x and y are both negatives and or on the axis it self. That is easy) Rotate the wheels to that angle (Closed Loop System) Then the magnitude (Pythagorean theorem) is the speed to the motors.

How ever, I heard that it is the crab drive.

[mobilegamer999]

swerve drive == crab drive

and yes, putting all that stuff in (in summary) sounds simple, but seems complicated in comparison to say tank drive which is read left joystick set left wheels, read right joystick set right wheels

[davidthefat]

swerve drive == crab drive

and yes, putting all that stuff in (in summary) sounds simple, but seems complicated in comparison to say tank drive which is read left joystick set left wheels, read right joystick set right wheels

So you are saying that the "hardest" drive system is not even that hard. (I am more than capable of programming that) Now I guess I will look into to legged locomotion instead of wheels...

Actually, I think a 2 wheel system would be fairly hard.

[rahilm]

swerve drive == crab drive

and yes, putting all that stuff in (in summary) sounds simple, but seems complicated in comparison to say tank drive which is read left joystick set left wheels, read right joystick set right wheels

Crab is simply a TYPE of swerve drive, but they are not the same. Swerve is just the ability to have sets of wheels that can rotate. Crab drive is a type of swerve drive where all the wheels are linked (mechanically usually), so they are always at the same angle. 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), and Winnovation's 6-wheel swerve.

[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 (http://www.chiefdelphi.com/forums/showthread.php?p=992406#post992406) 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]

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

How legal would those be? :p


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

[mobilegamer999]

I have helped many teams with base drive code and have encountered quite a few different drive types. The swerve drive that I worked with was 4 swerves, each with independent control, and I would say it was one of the more difficult ones to get working, fully functions, and non-wire-twisting.

Now, the code i have doesnt use PID loops, but rather 'manual' monitoring and speed adjustment of swerve modules based on current and target angles. That being said, had it not been in the heat of competition with the limited time for programming and annoyance of "its just code, whats so hard about it" (as im sure all programmers are used to), I would have taken the time to properly implement PID loops, correct stops, and more features. But what made it difficult and would make it similarly difficult in any build season is the tendency to get 'base functionality' working then add 'slightly more' over and over so you can get more testing done and get it more and more functional but have ugly and hard to manage code, instead of taking the time to properly write it with closed control loops after base functionality was working. The biggest issue was the time limitation we had on programming and had we had more time, maybe it might have been easier to work with.

[Ether]

I'd say Unicorn drive (http://www.chiefdelphi.com/forums/showthread.php?p=992406#post992406) 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.


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 (http://www.chiefdelphi.com/media/papers/download/3006).

For those who like to have a deeper understanding, the derivation of those equations is given here (http://www.chiefdelphi.com/media/papers/download/3008).

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

[bladetech932]

Dont worry david i'm in the same boat as you. Our team doesn't have the manufacturing capabilities to do a swerve drive even though i could easily program it and make it easy to use. and I HATE THE 4-6 WHEEL TANK DRIVE

[NickE]

What is the hardest drive system to program?http://www.youtube.com/watch?v=vwFrCpYavt4

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

[WarpSpeed10]

I think this drive base would be the hardest to program. Just watch it as they kick it. It's beautiful. :')

http://www.youtube.com/watch?v=W1czBcnX1Ww

[davidthefat]

http://www.youtube.com/watch?v=vwFrCpYavt4

I would totally be down to do that. *cough*JPL, accept my internship request*cough* :yikes:

[Chris is me]

Programming a drive so that you CAN control all of its functions is easy.

Programming a swerve drive so that it's intuitive and easy to control those functions is not.

[davidthefat]

Programming a drive so that you CAN control all of its functions is easy.

Programming a swerve drive so that it's intuitive and easy to control those functions is not.

From your experience, how long does it take for the swerving wheels to actually orient itself to the right angle? What kind of motors are required to be able to rotate the wheels and not stress out the motors?

[buildmaster5000]

From your experience, how long does it take for the swerving wheels to actually orient itself to the right angle? What kind of motors are required to be able to rotate the wheels and not stress out the motors?

Depending on the gear ratio and the distance required, about .5 second is a reasonable estimate. We used swerve and didnt use PID loops without a visible performance loss. Using window motors and the wildswerve pods, we probably averaged .25 seconds between posisitons using window motors. We also limited the wheel to only have a 180 degree range of rotation.

[Chris is me]

From your experience, how long does it take for the swerving wheels to actually orient itself to the right angle? What kind of motors are required to be able to rotate the wheels and not stress out the motors?

I haven't built a swerve out of "FRC parts", but this depends on your coefficient of friction and number of wheels. What motors and gearing you can use depends on how fast you want the pivots to be able to rotate and what tread material you use.

That said, with proper gearing I've heard of teams using anything from Window motors to the FP.

[Duncan Macdonald]

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)
you could fund raise really hard and help your mechanical team out if you really want to build one.http://www.team221.com/order.php?cat=3

I wouldn't recommend doing something solely because it is hard. Most teams do a cost/time vs return analysis and decide that focusing on an effective manipulator and simple drive will result in a better final product. We did this and decided that in this game* a mecanum has some advantages when hanging tubes and we wanted to add it to our bag of tricks.

*Chose not to in '07 because we anticipated heavy defense

[PAR_WIG1350]

I'd say Unicorn drive (http://www.chiefdelphi.com/forums/showthread.php?p=992406#post992406) 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.

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.

[Ether]

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.

Interestingly, all the other modes are subsets of the 3-degree-of-freedom mode. So once you have the 3-degree-off-freedom programmed, you can get the other modes just* by converting the driver interface commands to the equivalent 3 degree commands. For example, the conversion for Ackermann steering is shown here (http://www.chiefdelphi.com/media/papers/2426).



* "just" software. I hate that phrase. Don't you?

[Tom Line]

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.

Tank drive is inferior? That's a pretty interesting statement to make considering the number of Einstein teams who have run tank vs. any other system.

On what do you base tank's perceived inferiority?

[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

[The Lucas]

Probably this one (http://www.chiefdelphi.com/forums/showthread.php?t=89768):D
I can't figure out which combination of outputs make it move, let alone reach its top speed of 154 fps or Warp 9 (I am not really sure).

Seriously, I think a Field-Centric 3 degrees of freedom drive is the toughest I've seen in FIRST.

[Chris is me]

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

All I can say is build one and try it.

I agreed - until I picked up the Revolution demobot at IRI and tried to make it drive around without ramming into anyone. Wow it is hard.

[Josh Fox]

I think that all depends on how you program it and how much practice a driver has.

After 4 years of driving Team RUSH's robots, I'd like to consider myself to be a fairly competent chassis driver. That being said, I only had experience practicing and operating with 6wd. I only had one real chance to drive a swerve-based chassis. It was programmed with one stick controlling rotation and the other translation, and it was a completely different beast than standard 6wd. That being said, with more practice it's possible I would've been able to do just as much with swerve as a 6wd robot, but I wasn't since I hadn't practiced with it.

[davidthefat]

How I interpreted the controls was that the joystick was to move around the field and the shoulder buttons were for zero point turning. The gyros (double redundancy) would orient it self relative to the driver, so when ever the driver presses down, it will come toward the driver.

That sounds a lot easier than how you described it.

[Josh Fox]

That definitely sounds like an interesting control method, and I've never heard it done that way.

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.

[Garret]

Is swerve supposed to be more difficult than Mecanum to drive?

I don't see how it could be that difficult from the drivers perspective. We have a mecanum robot, and our driver did fine even though he had to deal with reversed controls for our first matches and was controlling all the robots functions. After that was fixed we didn't have any difficulty driving. I am trying to figure out what you mean by difficult. is there something that swerve has that makes it more difficult than mecanum.

Also our driver had no real prior practice with mecanum.

[Alan Anderson]

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

I don't know how 148 actually did it, but the way I'd program it is almost ridiculously simple. For all practical purposes, the joystick axes drive motors directly, with a single pushbutton controlling a drop wheel.

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

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 :P

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.

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 :o

[Siri]

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

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.

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 :oOur modules (http://wiki.team1640.com/index.php?title=DEWBOT_VII_Drive_Train#Mass) 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]

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]

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]

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]

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.

[ttldomination]

Reading through this thread, I do have a question.

Assuming a robot has a crab drive, how would turning of the actually base fair? I would think that since turning would pretty much be comparable to a 4WD, it wouldn't so hot, but my knowledge of swerve/crab isn't whole.

Can anyone confirm this?

[Garret]

The way our swerve drive turns would be to turn the wheels in so that it actually doesn't skid. I know 1717 does this and it is very effective as far as I can tell.
If they didn't turn inward it would be rather difficult to turn I think.

[Ether]

The way our swerve drive turns would be to turn the wheels in so that it actually doesn't skid.

I think he was asking specifically about crab (http://wiki.team1640.com/images/6/60/Programming_a_Pivot_Drive_Robot.pdf) drive (which is a subset of swerve), where all four wheels are driven and steered in the same direction.

If they didn't turn inward it would be rather difficult to turn I think.

With high-traction wheels and a long wheelbase, yes.

[davidthefat]

Now, this might sound ridiculous, but has anyone thought of putting a "turret". So the Drive train would be a separate system than the turret like a tank.

[Ether]

Now, this might sound ridiculous, but has anyone thought of putting a "turret". So the Drive train would be a separate system than the turret like a tank.

I believe this has been done.

[apalrd]

Now, this might sound ridiculous, but has anyone thought of putting a "turret". So the Drive train would be a separate system than the turret like a tank.

This Robot (http://www.chiefdelphi.com/media/photos/27228) comes to mind. So do a few others by team 118.

[Joe Ross]

Now, this might sound ridiculous, but has anyone thought of putting a "turret". So the Drive train would be a separate system than the turret like a tank.

http://www.youtube.com/watch?v=CAJBC-DDL9w

[davidthefat]

This Robot (http://www.chiefdelphi.com/media/photos/27228) comes to mind. So do a few others by team 118.

http://www.youtube.com/watch?v=CAJBC-DDL9w

I believe this has been done.




:eek: How stable was it? Are you aware if it broke down often or at all?

[Alan Anderson]

If they didn't turn inward it would be rather difficult to turn I think.

With high-traction wheels and a long wheelbase, yes.

If you crab a long/narrow wheelbase sideways, it becomes a short/wide wheelbase.

[Ether]

If you crab a long/narrow wheelbase sideways, it becomes a short/wide wheelbase.

Of course.

If the vehicle is mechanically limited to crab operation that may be your only option.

If not, it could be argued that it would be easier overall to replace crab software with something more flexible.

[buildmaster5000]

Short answer: Swerve drive with 4 independently controlled wheels.

Long answer: Swerve drive with 4 independently controlled wheels that have a limited range of motion. This forces the programmer to limit how the wheels will be pointed as to not tear out the wires leading to the motor powering the wheel (CIM motor in most cases.) It also requires the wheels taking a specific path in order to do this. This path is not necessarily the shortest and most direct, but it should be no more than 180 degrees of travel. An example of this is the attached picture, a portion of team 2421's creation this year. If someone wants to see the code for it, it is available here (http://code.google.com/p/rtr2421code/source/browse/JanTest/src/org/rtr2421/robotics/JanTest.java). Feel free to PM me with any questions you may have

[davidthefat]

From what I can see, you only need 90 degrees of rotation. Personally, from the context of this competition, having 4 independently rotated wheels are too much weight. The swerve system it self is quite heavy, adding unnecessary weight should be avoided. I really see no advantage with 4 independent wheels compared to the "crab" drive. At least the negatives far outweigh the positives.

[bladetech932]

I agree with david on this one. While i do see the merit in four independently controlled swerve modules, i think the weight and the limited motors outweigh the benefits of the control. For the case of FRC i think that the crab is more than sufficient.

[AdamHeard]

From what I can see, you only need 90 degrees of rotation. Personally, from the context of this competition, having 4 independently rotated wheels are too much weight. The swerve system it self is quite heavy, adding unnecessary weight should be avoided. I really see no advantage with 4 independent wheels compared to the "crab" drive. At least the negatives far outweigh the positives.

I disagree.

Many teams are capable of making such a drive lighter than most teams invest in traditional drivetrains. They then achieve full omnidirectional motion without the drawbacks of a robot sitting on rollers.

[Robby Unruh]

Can someone give me some examples of how swerve drive is controlled via joysticks? :confused:

[bladetech932]

There are many ways but two common ways among teams who do it for the first time are
-one joystick with the y axis being speed of the wheels the buttons being rotation of the whole robot and the x being the rotation of the wheels(the easiest)
-one joystick with the rotation based on where the stick is on the joystick and speed is the R vector of the x and y axis and rotation on buttons
but really there are A LOT of ways to control a swerve.

[Captaindan]

hardest robot to program as far as drive goes is definitely an omni drive robot that can switch to akermon.... which is similar to a monster truck drive train where the front and back wheels turn all with encoders to exact positions we called it the crazy bot because the watchdogs would go crazy and the r0bot would go plum crazy and head for the nearest programmer for some reason

[davidthefat]

hardest robot to program as far as drive goes is definitely an omni drive robot that can switch to akermon.... which is similar to a monster truck drive train where the front and back wheels turn all with encoders to exact positions we called it the crazy bot because the watchdogs would go crazy and the r0bot would go plum crazy and head for the nearest programmer for some reason

I never understood the watchdog, does it starve when a set of instructions took too long? I never had to explicitly feed it. Most of them usually were simple programming errors similar to index out of bounds or segment fragmentation.

[Greg McKaskle]

The watchdog monitors one thing and controls another.

In the case of the system watchdog, it monitors incoming control packets and controls the outputs of the robot. The deadline is 100ms, and this means that if the incoming packets take longer than 100ms to arrive, the watchdog shuts down the outputs. As an example, lets say that the driver sets the tethered robot to driving forward, and then the clumsy mentor steps on the enet cable, yanking out out of the laptop. Since this breaks comms, the watchdog notices and will shutdown the outputs. Same situation if your laptop runs out of power, you shut down the radio, you yank the enet from the dlink, you lose power to the dlink, etc. If the cRIO doesn't get incoming packets, you don't want the robot to keep driving, and the system watchdog does that.

For the User watchdog, it observes your code's ability to call the feed function. If your code doesn't call feed, it shuts down the outputs. As an example, lets say that the robot is driving forward, and the forgetful mentor sets a breakpoint in your teleop function. Without the watchdog, the robot will maintain its current course. With the watchdog, it will halt the motors.

The Safety Timers are similar to this, but are I/O specific. They observe the updates to a given output and will shutdown that output if the deadline is missed. Again, this could be due to a breakpoint, delay, infinite loop, dead thread, bad logic, etc.

Does that help?
Greg McKaskle

[Ether]

hardest robot to program as far as drive goes is definitely an omni drive robot that can switch to akermon

Once you've got omni programmed, adding Ackermann (http://www.chiefdelphi.com/media/papers/download/3030) is very simple.

[davidthefat]

The watchdog monitors one thing and controls another.

In the case of the system watchdog, it monitors incoming control packets and controls the outputs of the robot. The deadline is 100ms, and this means that if the incoming packets take longer than 100ms to arrive, the watchdog shuts down the outputs. As an example, lets say that the driver sets the tethered robot to driving forward, and then the clumsy mentor steps on the enet cable, yanking out out of the laptop. Since this breaks comms, the watchdog notices and will shutdown the outputs. Same situation if your laptop runs out of power, you shut down the radio, you yank the enet from the dlink, you lose power to the dlink, etc. If the cRIO doesn't get incoming packets, you don't want the robot to keep driving, and the system watchdog does that.

For the User watchdog, it observes your code's ability to call the feed function. If your code doesn't call feed, it shuts down the outputs. As an example, lets say that the robot is driving forward, and the forgetful mentor sets a breakpoint in your teleop function. Without the watchdog, the robot will maintain its current course. With the watchdog, it will halt the motors.

The Safety Timers are similar to this, but are I/O specific. They observe the updates to a given output and will shutdown that output if the deadline is missed. Again, this could be due to a breakpoint, delay, infinite loop, dead thread, bad logic, etc.

Does that help?
Greg McKaskle

Yes, that helps and explains it.

[Jimmy the Kidd]

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


Omni wheels.

[Ether]

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?

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 (http://en.wikipedia.org/wiki/Ackermann_steering_geometry), 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.

[Jimmy the Kidd]

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 (http://en.wikipedia.org/wiki/Ackermann_steering_geometry), 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.




What we ended up trying to accomplish was a, I guess you'd say, mirrored Ackermann. AKA, the front wheels would turn 45 degrees to the left, and the back wheels would turn 45 degrees to the right. Then, when triggered, the drive sticks would toggle over to omnidrive, with each wheel receiving the same value from the joystick.

[Ether]

What we ended up trying to accomplish was a, I guess you'd say, mirrored Ackermann. AKA, the front wheels would turn 45 degrees to the left, and the back wheels would turn 45 degrees to the right. Then, when triggered, the drive sticks would toggle over to omnidrive, with each wheel receiving the same value from the joystick.

Several comments:

1) I thought you just said (http://www.chiefdelphi.com/forums/showpost.php?p=1052287&postcount=83) you were using omni wheels. Omni wheels aren't usually steered. Can you post a picture of your drivetrain?

2) I wouldn't suggest using the word "Ackermann" to describe what you stated. The whole idea of Ackermann is that the wheels are steered to different angles, not the same angle. The point of this is so that each wheel's axis will point to the center of rotation of the vehicle so that the wheels do not scrub.

3) Not sure I understand what you mean by "omnidrive, with each wheel receiving the same value from the joystick". Each wheel of an omnidirectional vehicle typically receives different commands, not the same commands.

[Jimmy the Kidd]

Several comments:

1) I thought you just said (http://www.chiefdelphi.com/forums/showpost.php?p=1052287&postcount=83) you were using omni wheels. Omni wheels aren't usually steered. Can you post a picture of your drivetrain?

2) I wouldn't suggest using the word "Ackermann" to describe what you stated. The whole idea of Ackermann is that the wheels are steered to different angles, not the same angle. The point of this is so that each wheel's axis will point to the center of rotation of the vehicle so that the wheels do not scrub.

3) Not sure I understand what you mean by "omnidrive, with each wheel receiving the same value from the joystick". Each wheel of an omnidirectional vehicle typically receives different commands, not the same commands.




I apologize. I was confused myself when I was talking. We had standard wheels. In "Ackermann" the wheels turned opposite of each other to make tighter turns. In "Omni", say you pushed the joystick to the left. Each of the four wheels would go left. Up-left, each would go up-left.

[Ether]

In "Ackermann" the wheels turned opposite of each other to make tighter turns. In "Omni", say you pushed the joystick to the left. Each of the four wheels would go left. Up-left, each would go up-left.

You mentioned in your earlier post that your team encountered a great deal of trouble trying to get this programmed properly.

Have you given up, or is your team going to try to tackle this as an off-season learning project?

[Jimmy the Kidd]

You mentioned in your earlier post that your team encountered a great deal of trouble trying to get this programmed properly.

Have you given up, or is your team going to try to tackle this as an off-season learning project?




We do still have the original drive train, and we've cycled programmers since then. That sounds like a good summer project, actually.

[Ether]

We do still have the original drive train, and we've cycled programmers since then. That sounds like a good summer project, actually.

Here's (http://www.chiefdelphi.com/media/papers/2426) a resource that your new programmers might find useful. It discusses swerve and Ackermann programming.

[WizenedEE]

Is there a paper on all the different types of drive systems? Even just a list of their names and a brief description would be helpful for some sort of regularity/standard for names.

[Jimmy the Kidd]

Here's (http://www.chiefdelphi.com/media/papers/2426) a resource that your new programmers might find useful. It discusses swerve and Ackermann programming.




Thanks man. I'll be sure to let you know about our progress. We're also planning on putting LabView code onto a VEX PIC controller. Maybe use that to control 2010's drive train.