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.

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

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

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

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]

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

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.

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