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]

Originally Posted by 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.

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]

Originally Posted by davidthefat

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

To be fair, your original post was only

Originally Posted by davidthefat

What is the hardest drive system to program?

--

Originally Posted by davidthefat

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/s...irectional.pdf

[mobilegamer999]

Originally Posted by davidthefat

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]

Originally Posted by 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.

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]

Originally Posted by davidthefat

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]

Originally Posted by 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.

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

[basicxman]

Originally Posted by bladetech932

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]

Originally Posted by basicxman

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

Originally Posted by 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.

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.