Andymark Swerve Drive Labview Programming Help

We have purchased 4 andymark swerve drive modules with absolute encoders on each, but are struggling with the programming. Is there any chance anyone could send some current gen (2017 or 18) labview programming examples?

We played with it in the FALL. I wrote a version and my head programmer wrote a version. I don’t have his version uploaded.

We did not use swerve on the robot this season, however you are welcome to look at the code. Me and head programmer learned from what Apple Pi had done. (Thanks Apple Pi, our 4-H team twins!)

We are using the AndyMark swerve modules with the analog sensors for steering. This code is NOT FINAL, it works except we haven’t figure how not to get the pods to rotate all the way around the long way. All of our code, electrical prints are archived on frcsoft. This was made in 2017 Labview, so you have to port it over to 2018 for sure, because the libraries are drastically different this year.

We learned alot from Ether’s Swerve_Steer_8 spreadsheet, I think you can download that from CD Media. If you can not find it, let me know. (Thank you Ether)

I now imagine an alot with swerve wheels…

Also - we used to do LabVIEW Swerve so check out our old Github repos from 2015 and 2017.

Make fun of me all you want, I don’t care. I am here to inspire and help the students when I can with what I know. I got a D- in English in college. I am not here to teach English lessons. Sorry I offended you.


I’m not offended but obviously you are. My post was not meant to offend as I find it humorous - thus the amusing and cute picture of the “alot”.

You should try not to use engineering as a cover for poor English. It leads me to having to tell people I can’t hire them because they can’t communicate. A large portion of engineering is communication. Spelling and grammar are part of that.

Here are a couple of videos of that setup, if that helps you. I looked at what was posted, and in that version of code, the pods rotate the “long” way just so you know. But a good start to help you, I hope. Good luck this season.

Thank you. This is wildly helpful. We actually had used Spark Motor controllers, instead of Talon SRXs. I have ordered some to put on the robot at the competition, but in the meantime, is there any way to do this with sparks instead of talons?

You should be able to process your encoder data on the RIO and use the sparks similarly to how you would use the Talons. The closed loop will have to happen on the RIO instead of on a Talon SRX though.

The nice thing about Talon SRX controllers, is that they have built-in motor control or closed loop features that make it easier to program. If you bought Talons, you could get away with having just 4 Talons, one for each steering pod. This is where the closed loop control is needed the most.

The drive motors could remain Spark controllers to help reduce cost or budget in the robot.

If you must use Spark controllers for the steering pods, then you will need to create or use the internal PID function in labview. The code provided by Apple Pi calculates the angle where the wheels need to turn in the screen shot provided below. Where it sets the Motor Output would need to be replaced with PID block(s) that is always checking some scaled value of your angle turn as well from your analog sensors.

There would not be much code changes if Talons SRX could be used for the steering pods. But you still do need to replace and update to the new CTRE libraries, as you can see the sample is broken because it was create in last years labview if you opened in this years labview version, where as the libraries are now considered 3rd party.

So many of the icons and language have changed from 2017-2018… For instance, the SETREFERENCE in begin no longer exists as it was in the 2017 version. I have tried to come up with something similar but it doesnt seem to mesh.

It is also making several dependency errors in the example you sent.

Yes…this is a PAIN…for labview, I would not recommend opening up the old sample Labview (2016) and trying to make it work in this years Labview (2017). There are things we don’t know behind the scenes that have changed. For example a big change is the CTRE libraries are moved out, and that’s why the 2016 project is all broken.

The way I would recommend to keep you out of trouble would be to start a new robot project in this years Labview (2017) version, and re-create the logic you see in the a new robot template. This way all the new dependencies will have the latest update. It will be a pain to re-create all of that but it will work correctly in the end. I am sure there are “porting” guides to walk you through it or someone on here might be able to give you advice how to port a Labview 2016 to Labview 2017 project, but by the time you fight with all that, you could have just redone the whole thing in Labview 2017. Plus by actually wiring and programming it, you learn every part of the code, which helps understand it better I think, atleast for me.

Just make sure you install the latest Labview Update and the latest CTRE library before you begin. Then create a new labview robot template and go from there. When it comes time to deploy on the RIO, don’t forgot to format the RIO and do the Lifeboat update from CTRE.

For the analog encoders, did you run them directly to the Talon SRX or did you run them to the analog port on the rio? We are using these, and attaching them to the analog ports on the rio. Thanks!

If you are going to use the Talons SRX for position control of your steering pods, then the analog sensors need to be connected directly to the Talons.

You will need this board, to solder the analog sensor too, then connect it directly to the talon. I dunno if you can see that in the video I posted earlier, but the big gear is connected to the analog sensor and that is wired to a local talon for that pod.

Chris we (Apple Pi) always love to hear that teams find usefulness from our code - particularly a team like yours we admire so much (ever since you came to CT in 2010 with your tiny triangle robot).

The latest variant of code we have posted is identified here:

But as mentioned requires some updating due to CTRE changes. If you go to our 2015 code it does not use Talon SRX libraries - all on RoboRio and is an alternative approach, though we do like the pigeon imu.

This year during build season we have substantially overhauled this and are including Motion Magic for the steering control. It is not yet ready for posting and likely will continue to evolve over the season, but is showing some promise.

We have found that the CTRE stuff is fantastic - but like a lot of powerful tools can have some unintended consequences, our programmers are all students, occasionally misguided by a retired Mech E mentor.

I have no problem with your englesh, and we also love being a 4H team!

“we haven’t figure how not to get the pods to rotate all the way around the long way.”

We only turn the wheels a maximum of 90 degrees, if the need is for more than 90 degrees, we reverse the direction of the drive wheels and rotate desired angle minus 180 degrees.

I did find that CTRE made a migration guide. I dunno if this helps:

Oh wow, you still remember that huh? That was such a FUN TRIP! I have great memories of that trip to CT. Everything from the time it took to get there, to the science center, to a really neat Greek restaurant, to getting pushed into the goal that year. That’s when we met Dana and Rosie too. ha ha ha. I remember talking to many of your team mates that year about 4-H. We met all the other UTC teams while we was there. It was a great time! Thanks for a trip down memory lane.

Thank you very much for this, we will check this out in the summer again. I am trying to learn it in the offseason so I can start teaching it to some of the students. I got a pretty good handle on the math in my head now. We are really partial to the KISS method and pretty fond of TANK drives so I dunno if we will ever be a SWERVE team or not. The code provided was pretty easy to follow and understand. When I see the swerve work in action, there are so many working parts, I worry about mechanical failures the most. You can only write so much code to fix a set screw that fell out in the middle of the match….

You’re welcome.

Here’s the spreadsheet download link for anyone who’s interested:

You enter the fwd, strafe, and rotate commands, and it displays a simple graphic showing the wheel speed and steering angle for each of the four wheels. Useful for checking out your own swerve code inverse kinematic calculations.

Also, if you haven’t coded swerve yet, here’s a document that explains the swerve inverse kinematic equations step-by-step:

There are a few icons I can’t seem to find in the libraries, GetDoubleGyro seems to be one of them. Is this custom code or can this be found?

Attached is our attempt at recreating your code, it still has a few broken VIs, can you let us know if we are close?