potential future white paper: swerve drive implementation

[PAR_WIG1350]

I was thinking of posting, at some point in the future (not necessarily before kickoff or even the end of build season, it depends on a number of factors), a white paper on swerve drive implementation and formula generation technique for any given drive base. basically, a guide to creating mathematical formulas to control a swerve drive base regardless of size, shape, or number of modules. It will also briefly talk about driver controls and sensors.

I just wanted to tell you about this and was wondering if there were any suggestion or comments you would like to share or questions you would like answered.

Any feedback will be appreciated.

[apalrd]

Would you be talking about the math behind the steering only, or the implementation in software as well? Both would be useful to many.

[PAR_WIG1350]

Mainly the math, but It will probably also include some information on programing as well. It really all depends on if my algorithms work the way I think they will. Testing that is the main reason for holding out on posting the actual paper for such a long period of time.

[Gdeaver]

Team 1640 did swerve for the first time this year. As part of our off season design project several papers were developed. Mostly the math. You may want to look at them.
This is the first paper after the summer work.
http://wiki.team1640.com/images/8/85...heel_Drive.pdf
This is a paper commenting on the summer project.
http://wiki.team1640.com/images/6/60...rive_Robot.pdf
This is the final paper commenting on crab with orientation control. Mode1 in the paper was implemented on the 2010 robot. Mode 2 is tough because it requires tracking states and would require some feed forward algorithms.
http://wiki.team1640.com/images/3/3a...Twist_edit.pdf
Browse our website for the mechanical implementation.
Comments and comparisons to your work are welcome.

[davidthefat]

Isnt it just simple as getting the angle of the joystick relative to the center of the joypad., which is using tangents. Then get the distance of the joypad from the center, which would be the speed.... Doesnt sound all that complicated as people make it out to be...

[PAR_WIG1350]

Originally Posted by Gdeaver

Team 1640 did swerve for the first time this year. As part of our off season design project several papers were developed. Mostly the math. You may want to look at them.
This is the first paper after the summer work.
http://wiki.team1640.com/images/8/85...heel_Drive.pdf
This is a paper commenting on the summer project.
http://wiki.team1640.com/images/6/60...rive_Robot.pdf
This is the final paper commenting on crab with orientation control. Mode1 in the paper was implemented on the 2010 robot. Mode 2 is tough because it requires tracking states and would require some feed forward algorithms.
http://wiki.team1640.com/images/3/3a...Twist_edit.pdf
Browse our website for the mechanical implementation.
Comments and comparisons to your work are welcome.

The graphs in the second paper resemble graphs generated with by algorithms, which is comforting, but they are not the same algorithm. The technique you use focuses on achieving goals that with my technique are simply after thoughts that a good driver could still probably approximately mimic. My algorithms focus more on a maneuver that is not present in your calculations, but you do include a replacement for this maneuver.

I also was considering some form of drifting 'snake' maneuver, similar to our '09 bot, but I decided Against it for the experiment I'm running <although the Algorithm that the paper will describe can be used to figure out how to do this, and the calculations have been run, I just don't think that I will use them.>

One advantage I see with your algorithm is simpler math, that is, not necessarily lower level, just less of it.

[PAR_WIG1350]

Originally Posted by davidthefat

Isnt it just simple as getting the angle of the joystick relative to the center of the joypad., which is using tangents. Then get the distance of the joypad from the center, which would be the speed.... Doesnt sound all that complicated as people make it out to be...

That would be CRAB drive, the simpler, less maneuverable cousin of swerve drive.

[JamesBrown]

Originally Posted by davidthefat

Isnt it just simple as getting the angle of the joystick relative to the center of the joypad., which is using tangents. Then get the distance of the joypad from the center, which would be the speed.... Doesnt sound all that complicated as people make it out to be...

http://www.firstwiki.net/index.php/D...n#Swerve_Drive

Briefly explains that Crab drive is a type of swerve drive where all wheels are turned to the same angle (either through hardware connections, or due to a simplified algorithm like the one you describe).

[PAR_WIG1350]

What math level should I write for? I was thinking Algebra II but I also thought it would be beneficial to open up access to teams without that level of experience. How much in depth should I go? Should I walk through the derivation of the method step by step, or should I just present the general formulas and algorithms and point out the various constants and variables and what they are in real life (as opposed to on paper or in code)?

-Alan

[JamesBrown]

I think that an Algebra 2 level should be fine (assuming you actually meant Algebra 2) I would imagine that all teams would have members who have taken math up to Algebra 2, all mentors should also have this level of understanding.

I personally thing that the Derivations would be useful as a learning tool for students, that being said I would not include any derivations that a HS student with knowledge of Algebra 2 and Geometry couldn't do (i.e. no Calc, and nothing other than sin/cos/tan as far as Trig)

[PAR_WIG1350]

Originally Posted by JamesBrown

I think that an Algebra 2 level should be fine (assuming you actually meant Algebra 2) I would imagine that all teams would have members who have taken math up to Algebra 2, all mentors should also have this level of understanding.

I personally thing that the Derivations would be useful as a learning tool for students, that being said I would not include any derivations that a HS student with knowledge of Algebra 2 and Geometry couldn't do (i.e. no Calc, and nothing other than sin/cos/tan as far as Trig)

OK, thanks for the feedback, sounds good to me.

[virtuald]

Swerve Drive is really easy to implement if you ignore the actual control of the motors and just look at it abstractly (ie.. point motor to angle and run it at some speed). Of course, there are some optimizations you can do to ensure smoother operation past just the pure mathematical analysis.

I created a spreadsheet to simulate a swerve drive and its calculations (by using a graph to model the direction/speed of the wheels): http://www.virtualroadside.com/blog/...l-spreadsheet/

We also released the source code for our robot that year (which includes its swerve drive code), which can also be found elsewhere on my website.

[PAR_WIG1350]

Originally Posted by virtuald

Swerve Drive is really easy to implement if you ignore the actual control of the motors and just look at it abstractly (ie.. point motor to angle and run it at some speed). Of course, there are some optimizations you can do to ensure smoother operation past just the pure mathematical analysis.

I created a spreadsheet to simulate a swerve drive and its calculations (by using a graph to model the direction/speed of the wheels): http://www.virtualroadside.com/blog/...l-spreadsheet/

We also released the source code for our robot that year (which includes its swerve drive code), which can also be found elsewhere on my website.

Yes, but not really, for people who breeze through vector calculus like it was nothing, swerve drive is nothing (and this is swerve drive, not crab which is really easy to program), but some teams don't have any team members with higher level math skills. The idea of this paper is to provide an out of the box formula for any swerve drive base regardless of size, shape, or number of wheels. Also, it doesn't involve any calculus at all. in addition, mechanical and electrical implementation of swerve will also be discussed. Currently the paper is not very much more than a plan, but the idea of using tables and arrays for swerve drive is one of the planned topics of discussion, although how to do it is not.

[Nadav Zingerman]

Originally Posted by PAR_WIG1350

Yes, but not really, for people who breeze through vector calculus like it was nothing, swerve drive is nothing (and this is swerve drive, not crab which is really easy to program), but some teams don't have any team members with higher level math skills. The idea of this paper is to provide an out of the box formula for any swerve drive base regardless of size, shape, or number of wheels. Also, it doesn't involve any calculus at all. in addition, mechanical and electrical implementation of swerve will also be discussed. Currently the paper is not very much more than a plan, but the idea of using tables and arrays for swerve drive is one of the planned topics of discussion, although how to do it is not.

There is no calculus involved in that spreadsheet. If anyone really want to use an "out of the box" formula without really understanding it, all they have to do is translate the Excel formulas into code.

[brianc217]

My team tried to do a crab drive system this year but we found that the chassis would not maintain its orientation as we had assumed.
Does anyone know why this might have happened?

I tried implementing some correction code that would look at the gyro and compensate by speeding up one side or slowing down the other with some success but it wasn't perfect.

I also tried making sure all the wheels were going the same speed using rotation sensors and PID but could never get it to work. There was too much lag. Has anyone got this to work with this or a different method?

Thanks. I would appreciate any feedback. It would let me sleep easier at night!