Are there any good resources for swerve drive code in Labview? I know there is alot for Java, but I was struggling to find any Labview resources.
1640 and 1540 have both published their swerve Labview code on Github
I want to say 2067 is also a Labview swerve team. At the least, there’s code on their website.
This one is older but you can perhaps check the algorithms used: Team 2468 Orion Code
We (33) programmed a swerve in labview. Pm or post here if you have specific questions!
Team 1023 also programmed a swerve in LabVIEW, specifically the Swerve Drive Specialties Mk. 1 Module, feel free to ask any specific questions, at some point the code should be released, however, it still has quite a bit of cleanup to be done.
Unsure if you mistyped but we have never used LabVIEW, and certainly not for any swerve drive code. We have some Java swerve code on our GitHub tucked away from a largely unsuccessful offseason project but there are much better references elsewhere.
Wierd, when you search for “Labview swerve github” your team number comes up and the text says it’s your swerve code. But when you click into the link your repo says nothing about labview. Just some Google weirdness.
I know this isn’t what you are looking for, but I think it should be addressed. While I have not personally done any work with LabVIEW, my team used it for years and I have experience with other graphical robot programming languages. I have the opinion that anything sophisticated should not be done graphically. My friend’s team recently switched from LV to Java and are super happy with the switch. I also mentored a VRC team that was using a graphical language called “EasyC” which was c-like but graphical. Part of what I helped them do was move to a typing-version of C (RobotC) and it was one of the best decisions that the team made. We saw unreal improvements in efficiency and level of sophistication.
I have seen at countless competitions teams looking for help with LabVIEW. Unfortunately, most of the people there use Java (which as of last year accounted for approximately half of all FRC robots). They could not get the help they needed because LabVIEW simply isn’t as widely used. It is not as widely used as (from what I heard) it gets in the way.
If I were in your position, I would spend the summer learning Java programming, rather than going to a swerve drive project. I personally got from EasyC to writing Java programs in the first three days of Build Season (the VRC change was happening at the same time). My VRC team was in the same position that you were in. We wanted to more sophisticated stuff like PID and an on-robot UI, and EasyC started getting in the way. It admittedly seemed daunting at first, but we were at the same level as before in a matter of hours. If you want any help, feel free to send me a message on CD. I am more than happy to help out in any way I can.
We were actually a java team before last competition season. However, our mentors decided that we should make the switch due to one of our mentors, who works professionally with labview (but his labview is strikingly different from FRC labview), having the capability to provide help.
Ah, I figured it out. Back in 2015, we created a Github repo with a list of all the code releases we could find, including team 900’s LabVIEW swerve code. Said repo is sitting in the unmaintained depths of our organization as its maintainer is long since graduated, although I suppose the link to the aforementioned swerve code may be helpful.
I wish that I could offer advice on that situation, but I can’t really. I think it says a lot about LabVIEW in FRC that you are having a hard time finding example code, but it is up to your team to prioritize what is important for your team. I have found at least on my team that the mentors may not always make the best decisions. I am fortunate in that my team has a very aggressive “Student Run, Student Built” culture with all of the pros and cons that it brings, which creates an easier entry to encourage the mentors to adapt to what is best for the team. If you feel that LabVIEW is the right option for your team then you have every right to do it. If it were my team, I would respectfully suggest that LabVIEW is not the right path since it has major issues and I am of the belief that our decisions should be made independently of our current mentor set (since we have had lots of people come and go in our 25 years).
Back in 2011 I wrote Swerve Drive code in LabVIEW. The sensor and motor WPI Lib calls and the PIDs need to be added but the tricky math that takes 3 joystick axes and wheel directions as the inputs and outputs the direction and speed for each wheel is there. It can handle any number of wheels, each with any XY position relative to the desired center of turn. It can limit how many times a wheel rotates incase you have wires that would get disconnected. Feel free to ask me questions on the linked thread! I have yet to have a robot to test this code on so I would be excited to know that it works (or not).
Welcome to LabVIEW @Phil_McJoe. (also @abeaver) I must admit I am biased because LV is my first programming language and is still the one I know best. But for me at least dataflow in LV is very sensible compared to text based languages. It allows you to very easily parallelize your code. The way math operations work in LV makes reading order of operations in math natural. However, if you think better about math in text based there is a structure for that in LV.
The reason my team used LabVIEW when I was a student was not because any mentor knew it (he was actually a Java programmer). It was because LV costs so much for most people ($5,000 for the professional version) but it is free for use in FRC robots and with it being used a lot in industry where FRC students may want to apply for jobs in the future (SpaceX, NASA, Boeing, etc.). If anyone wants to learn C++ or Java there are plenty of places for that in schools and a FRC scouting program. This led me to learn LabVIEW and resulted in my getting an intership working on mass spectrometers while I was about half way through high school. That intership has since turned into a job for me. By the way I am looking for another intern if you are in St. Louis.
I wanted to share my implementation of crab drive on our 2019 robot. Not because it is well-written (it isn’t), but just sharing you may find some pieces or ideas to use.
The implementation had two steering motors. All the PID code was left out, and is pretty standard. Read an encoder and feed some PD (no I) to control the steering motor, using a global variable for azimuth angle (theta) that was from the joystick mapping. Also, the drive subVI was left out. I really just took the mecanum holonomic drive vi and repurposed it, with a new joystick mapping.
What I’ll post is the joystick mapping. It took x and y axis from the first joystick and converted these cartesian x,y values to polar coordinates, magnitude and direction (theta).
A second joystick axis (xspin) used a lookup table to adjust the 4 drive motors based on the direction. This spin component was added to the first magnitude. (so could be above 1, and so was normalized using the pre-written normalization in the mecanum code). Also, I added scaling (so I could reduce drive motor power for all). I also an option for individual gains – but never used it. I also added a deadband for the joystick around the center.
The most central part of mapping from x,y to polar, was the Inverse Tangent (2 inputs) atanh(x,y) function. It resulted in radians, but there is a second function that was useful both to change back to degrees and also let you rotate the input angle. I used that because we only we weren’t fully rotating our crab modules (only from -90 to +90 – with 0 degrees being the default forward). I had a boolean that maps it back out to 360.
Now there are code changes I would make. I probably could clean it up with formula nodes for the magnitude part (which if I forgot to mention is just Pathagorean). This also doesn’t have code to move to the closest angle. Really a lot could be improved. But you have some of the very basic ideas.
These are the times where I miss the dead horse emoji from old CD.
The language debate is an long-time CD favorite; you know it’s truly summer CD when it gets brought up. Everyone has their favorite language and would like to convince everyone else to use it, like some missionary trying to save the souls of the non-believers. But the bottom line is, all languages can do just about everything 99% of FRC teams will ever need. Each language is better at some things and worse at others. The best language for each team is different because different teams have different priorities and resources.
If the OP’s team has mentors who are experienced with LabVIEW (even if it’s a slightly different use case than FRC programming), it’s probably best for them to stick with it. Despite your unfounded claim that “anything sophisticated should not be done graphically,” there’s no reason you can’t program a swerve drive in LabVIEW.
Thank you for clarifying. I am trying to make an effort to learn the basics of labview this summer since it is so different from what I am used to and my region has a lot more software people than mech eng. people. The decision is completely up to OP. I apologize if I came across as too harsh to anyone. I personally had a bad experience in VRC with a graphical language, but I think that my approach to the world from a couple of years of OOP languages. I also am sorry if I took the thread off in the wrong direction. Getting back on track, I looked through some of my VRC code and remembered how much of it was code for the more popular Vex teams, just adopted for our language. I think that OP could have success trying to replicate some Java/C++ code in LV, especially since their team used Java before. I tried to find more LV Swerve and couldn’t find a lot of examples. Once again I am sorry for getting stuff off track. Good luck OP
You can do a search on CD and find different iterations of our Labview swerve code. The more recent ones use the CTRE encoders and talonSRX features including Motion Magic for steer. Our older iterations (look at 2015) do all the work on the RoboRio, and use analog absolute encoders.
We haven’t yet published this past season’s code - it needs some cleanup work before we do.