Programming swerve drive in Labview?

In the off season, our team is working on developing a swerve drive.

I have heard arguments (each way) concerning the fitness of Labview as a programming language for our robots (and don’t want to spark a heated debate here).

Has anyone programmed a fully functional (i.e. simultaneous translate and rotate) swerve drive using Labview? If so, given the option, would you do so again?


I think the tacit premise of the question is misguided.

The difficulty1 of developing software for swerve is an algorithmic issue, not a coding issue.

LabVIEW, C++, Java, Python - they’re all more than powerful and concise enough to express the necessary algorithms efficiently, once you’ve figured out the algorithms.

1the inverse kinematics is not the difficult part.

Thanks for the reply.

Unfortunately I don’t have any first hand experience with LabVIEW, so I’m stuck with what I can distill from others at this time (my plan for the off season is to correct this). I am an old school programmer, so I tend to be skeptical of the graphical nature of LabVIEW. Some other mentors I have talked to didn’t like LabVIEW (for whatever reason. I know it’s a philosophical question much like Windows vs. Linux, editor wars, even religion).

I just wanted to get opinions of whether attempting to use LabVIEW (which our team uses) to develop a swerve drive system would be a reasonable endeavor. Which you answered for me.


Team 1640, Sab-bot-age, Pivot drive is programmed in Labview. The programming mentor JCBC, is on CD, send her a note she can give your some pointers.

You would be wise to let go of your prejudice. :wink:

LabVIEW’s graphical nature does not detract from its utility as a full-powered programming language. It actually makes it easier to avoid simple typing mistakes – any problems with the program are typically due to errors in design, rather than silly things like misplaced semicolons. :stuck_out_tongue: The real distinction is that LabVIEW is a dataflow language, and that trips up a lot of people who think they know what programming is. It turns out that much of what typical structured programming practice is based on relies on the accident of procedural programming having become prominent first. Back up a bit from the textual view of a program, focus on the inputs and outputs of a function instead of the step by step directions for doing everything in order, and it all becomes a lot more clear.

To do continuous rotation, 4 wheel independent steering as 1640 has done for 3 years in Labview, one must embrace and understand the data flow mentality of Labview. If you bring your procedural habits to labview, swerve will present a problem. Happened in year 1 effort.

I am hoping to have 1640’s 2011 and 2012 swerve (“pivot”) drive LabVIEW code published shortly. The code from 2011 was almost ready to go before the 2012 season started, but then I got lost in the build season and didn’t follow through.


I have to ask then, what is the difficult part?


1 Like

I programmed a swerve drive with 1756 for Logomotion using LabVIEW. LabVIEW makes programming swerve fairly straightforward. I found basic implementation to be simple, but tuning the PID controls and finding miscellaneous bugs required significantly more time and effort. One word of advice: PID control loops in LabVIEW run differently when you are in the debugging mode. I noticed that the same values could result in unstable oscillations when in debug mode, but would provide good results in full deployments.
Good luck with your project. Swerve drive is a fun drive train to implement and play around with.

1 Like

In 2010 Team Titanium programed a swerve drive from scratch, and managed it out well. If you plan you can do it. Back then there where no examples present for labview, now you should be good pm for any help

In your original post, you stated that you wanted to program a swerve drive that is “fully functional (i.e. simultaneous translate and rotate)”. How to compute the necessary speed and steering angle of each of the four wheels at each moment in time for any desired vehicle motion (inverse kinematics) is straightforward and has been explained here on CD in papers and posts. The difficult part is what you then do with those computed values to get a vehicle that drives smoothly, safely, responsively, and predictably.

Read the last 2 paragraphs on Page2 of the paper
2011-03-28 Calculate Swerve Wheel Speeds and Steering angles.pdf
located here.

Ether has done the modeling. The problem with true “fully functional (i.e. simultaneous translate and rotate)” As far as we have found is that it would require an algorithm that keeps a short history of previous wheel position and a calculated future set of wheel positions. Not an easy programming task in any language. We have not done this yet. Our 2012 bot drives quite well with out going down this path. For a first year swerve effort, you may want to leave this off the plate.

I have posted Team 1640’s 2011 “Pivot Drive” (swerve) code here:

Thanks to the team’s 2011 head programmer, Ben Rajcan, it is nicely packaged as a LabVIEW library. I hope that it will be useful to teams who want to try out programming a swerve drive.