Hi it is our teams first time using swerve and we don’t really know where to start with the programming.
We have looked around on for some basic code to get a starting point but most of the code from teams we are finding are using Falcon 500s, while we are using Neos with CTRE Cancoders.
If anyone has anything that can help point us in a direction to start, we would appreciate it very much.
Might not be what you wanna hear, but please please use Java. There is much more help and resource, and support for you if you do. REV provide code examples for their modules, pretty sure SDS do as well, and there are many posts regarding swerve here on Chief Delphi, in Java.
It might seem painful, but trust me, it’s worth the pain, and it will open up so many more possibilities for you in areas outside of just swerve.
And really, it’s not painful at all. Java is really easy to pick up, and WPILib is fairly straightforward.
I second this recommendation. There will be a learning curve if no one on the team has Java experience, but using a swerve drive to its full potential in LabView will likely not save much time or energy. There aren’t many examples out there. There are lots of Java repositories.
You can do a search in Google for Java code that uses Neo’s and Mk4i’s with a search something like this:
site:github.com neo mk4i java
Try to find a more recent repository that was used successfully in competition. Simpler projects that don’t try to do everything will be easier to digest and learn from.
Our latest LabVIEW code targeted Falcons for the drivetrain; we didn’t use NEOs in a drivetrain until after switching to Java last season.
That said, they’re not substantially different, especially on the LabVIEW side of things. You should be able to look at code that uses Falcon 500s and understand it, I’d think, and either recreate it yourself using Rev’s stuff, or just try to swap it in to code you find directly.
If you really think you need it, I could probably whip up a basic template for you. I’d like to ask, though; how familiar are you with swerve programming? Do you know the math that goes into it? (If not, do you have programmers who’ve taken a physics course, or an advanced enough math course to be familiar with vectors?)
My preference isn’t to just do the work for you, but at the same time, I recognize how disadvantaged LabVIEW teams are in terms of existing libraries.
with the decline of LabVIEW plummeting over the past few years our team switched to java over the summer and it’s been very successful so far. with that being said for OP here is LabVIEW code for the mk4i’s with falcon’s hopefully the conversion from CTRE to NEO is easy: Ironclad / ironclad-2023 · GitLab
Hi, I dealt with all the pain you did throughout the build season last year. Here is a code explanation including links to all of the repos required. Here is our repository from last year. Feel free to reach out to me with any questions!
Please do not discourage them as you may not know their reasons. Labview is able to do swerve with odometry, with the only limitations being dedication. If someone asks a question you cannot answer, don’t answer it instead of telling them to conform to your preferences.
Encouraging people to make things easier for themselves is still a valid answer. LabView is objectively dying in FRC. They’d have fewer issues, and more help in achieving their objectives.
stack overflow got its bad reputation for criticizing people when they ask a question. I’d like chief delphi to avoid that. They asked for advice on swerve in labview, not advice on switching to java. I’m not denying that java will give less headaches, as I coded swerve in labview and know the pain myself.
Sure, but I wasn’t criticizing or demeaning anyone at all. I simply made a recommendation.
This kind of recommendation that I have seen quite a bit on Chief lately is not very productive.
The OP’s team has made the decision that they are using LabVIEW for their software, and are looking for support within that framework. Lots of these kinds of questions get responded with some form of “just use Java”. That’s on the team to decide, and they were asking for support with LabVIEW.
It would be just as bad if a team was asking for Java support and people started posting “just use C++” and justifying why that programming language is more optimal for FRC purposes. People need to stop doing this.
Stick to the context of the post, if they want help with LabVIEW, offer help with it. We don’t know what the team needs, or what factors they are considering for their own unique situation. If they want help with choosing a new language because after they ask for swerve support with LabVIEW they find it isn’t enough, then you can jump in with recommendations on changes.
So we should encourage teams to stick to a language that is OBJECTIVELY dying, and isn’t as well supported? The statistics for this are clear. How is it not productive to help a team that clearly needs help to nudge them in the right direction towards something that will lead them to greater success?
Excuse me for wanting teams to succeed, and trying to point them down a path of least resistance.
This isn’t equivalent to your example. I’m suggesting a language that is more popular, not less.
Although I agree with you, and I personally love sarcasm. I haven’t found sarcasm nor being condescending to be an effective form of persuasion.
When I was a student on my team we used LabVIEW for all 4 years i was there, Im now a mentor on that team and the best decision i made was having the team switch to java. teaching LabVIEW to new kids was much more difficult than it has been teaching them java and WPILIB. Not saying LabVIEW is bad by any means but i honestly think that it is productive to encourage teams to switch to an ecosystem with more support and better documentation. trying to find frc resources for LabVIEW was a massive pain because mose of what you would find is either not useful for you situation or is just flat out outdated. LabVIEW is dying in FRC and in general as even NI is shutting down features of labview so i think its fair to encourage teams that it might be a good time to start trying something new.
There is a very big difference between encouraging teams to use labview and giving help IN LABVIEW when someone asks for help IN LABVIEW. A physics tutor won’t help you with your english essay. I fully agree that java is superior. I tried to make it so labview on my team would die as I leave. That doesn’t change the fact that it is rude to persuade someone to change their programming language when they ask for help.
You should avoid imposing your preferences on a team that wasn’t asking for it.
I firmly believe that Java is the best option for the vast majority of teams. If this team asked for what programming language they should use, I would strongly recommend Java. They didn’t ask for that, and instead of providing a positive useful response we went into all the reasons Java might be better for them.
There is nothing wrong with encouraging teams to move off LabVIEW. What’s not cool is telling teams who aren’t looking for input on why their programming language sucks, and just want help with what they are using right now.
Sorry I haven’t replied to anyone yet as I have been busy with things, how ever I do have a few things to say.
First thank you to those who have posted labview things, I will take a look at those and see if I can get started with that.
Second, I understand why you are saying use Java however our team has very little resources for anything other then labview as no one besides me on our team has the slightest experience in it, even then I have just the very basic understanding.
Third, I do preferer if you stop going back and forth about why we should switch or why we/other people shouldn’t. Both have their ups and downs for teams and use.
Finally I am going to look at the labview and see if I can get anything working, if not I have talked to the other programmers and our coaches about switching, if we do deicide to you will most likely see me or someone else ask about that.
I do not believe that this opinion is very conducive to the conversation. The user asked specifically for a direction to start in and that should have been what was provided. If you do not recommend LabVIEW I believe you could have simply relented from mentioning it at all, rather than putting it down. While I agree that LabVIEW is one of the less supported languages, there are still resources available because there are teams that still use it or have used it in times past. Simply shutting down even the possibility of this pathway does not encourage the exploratory values of STEM at all.
Can you please link your code for LabView we are currently working on on optimization our labview swerve code
I won’t be able to access it until at least Tuesday; we never published it, since we never had to reuse it due to switching to Java.
In the meantime, have you looked through what 1712 shared in this post?
Edit: alternatively, if you’re just optimizing and want suggestions, feel free to post snippets of code here and I’llLimelight, an integrated vision coprocessor happily give pointers. If specific things aren’t working, I can probably help with that too.
