Swerve questions (Languages, CAN)

So I am making this thread to ask a couple of specific questions that has not been fully answered in other post that I have read. I am a new mentor for a veteran team, was fully involved last year and this year I am encouraging the team to “push the envelope.” The major task we are attempting this year is a swerve pod system.

We are a very financially limited team which means that we are careful not to make anything just yet physically because we can not afford to remake it with some changes in order to meet the rules about off season development, however we do have all our CAD files ready and we have fabrication methods lined up for the first week in January. (I wish off season rules would be less limiting)

While we wait to make our physical pod system we are turning our attention to the other half of the system, the code. One major concern is finite pod angle control. We are experimenting with CAN right now to see what it can do for us. We are planning on using a PWM absolute encoder from us digital to get information about pod angle. http://www.usdigital.com/products/encoders/absolute/rotary/shaft/ma3

**My first question is “Can the new can motor controllers be used to hold position from a PWM absolute encoder signal?” ** I know it can use quadrature input from an incremental encoder but those would require at least one full revolution of the pod to find the index in order to work correctly, which is why we are using an absolute encoder. If the motor controllers do not accept PWM from an absolute encoder then that throws out closed loop control of our pods, in this case is there any advantage to CAN since you can get current readings from the PDB now? (Other than having nice and pretty wires)

My second question is “Is there any advantages to using a specific language to make our swerve pod code in” We currently use lab view but here is our worries. 1. If we can’t use a closed loop control for pod rotation then we will have to use the RoboRIO to issue commands for motor control. Is there any language which might run faster on the RoboRIO? 2. If we can use closed loop to control our pods is there any advantage to using Java since it has just had a CAN overhaul. (according to “Behind the Lines” S0E02) 3. In the past certain notable teams have used other languages. Bomb Squad uses C++ and Cheesy Poofs use Java. Is there any particular reason for this or is it just personal preference? I know if we had been using java we could have implemented Cheesy Vision. (Not sure if we could have since we are using lab view)

Sorry for the length but I wanted to voice all my concerns in one go. Thanks in advance for the help.

Bryant Harrison

I do not believe that you can use the closed loop control for the analog absolute controllers. I can tell you that you absolutely do not want to use the quadrature encoders to keep track of the position of the swerve you will loss track of ticks so fast i would give you about 25-60 seconds tell you are ±15 degrees. Closed loop control is a must with out it will be semi impossible to control properly.

I know currently you plug the analog encoders in to the analog break out on the digital side car i am not sure how this works in the future but it is not very difficult to set up.

We used that encoder last year it worked pretty well after about 25 ish minutes of good rough use. The engineer from US digital said that some times they need to “lock in place” tell they stop slipping and that might take some time to do. If that happens do not be alarmed.

We use C++ we use it because it is what we have always used along with most of our programming mentors come from the world of C type programs. I have been told that C++ is the “fastest” but i don’t know how true that really is.

It should be possible to use the new motor controllers to hold a position based on any sensors you want. However, you might have to run the control loop on the robot controller rather than on the motor controller. FYI, closed loop control is using sensor feeback to automatically control your output automatically. It’s not essential that this happen in the motor controller itself. Even if you decide not to use the fancy features of the motor controllers there is at least one advantage I can think of for CAN: you won’t run out of places to put PWM wires.

I don’t know of anything that you want to do that shouldn’t be possible in all three supported languages. Regarding speed, C++ should be the fastest, but any of them should be sufficiently fast for what you have described. A few things to consider when choosing a language:

  1. For the first year with new hardware I would choose one of the three supported languages.
  2. There is value in choosing something that at least one person (student or mentor) on your team already knows
  3. Real computer science isn’t done in a “graphical language”.
  4. While C++ is the most complex and powerful of the available languages its advantages won’t become obvious until you’re trying to do “advanced” things.

I don’t think this project is going to force you to switch away from LabView but I would consider it if you have students how are interested to learn how to program.

We have ordered the 10 bit pwm version.

As far as what sensors the motor controllers can use. I’d suggest you use a Jaguar to investigate the various rotational feedback mechanisms and control options. If it cannot be done on a Jaguar, I suspect that it cannot be done on the newer motor controllers.

All three languages can do Cheezy Vision, Cheezy Drive, Cheezy Score, or whatever. It isn’t the language, it is the mentors and students identifying a problem, implementing a solution, documenting it and releasing it.

In my opinion, you have lots of new ambition with the HW. Switching languages at the same time only makes sense if you aren’t any good with the tool you have.

The key to being successful will be knowing what your system is doing and when it does it. If your SW timing jitters by 20ms, that is going to throw things off. If your math is wonky, it will throw things off.

So pick the tool that your members can use to author, model, test, and debug the best. Be sure to test the code through full ranges of motion before you ever run it on the robot.

A few other factoids:
All languages are getting a CAN overhaul, it was mentioned by Java member, but applies to all.

  1. Real computer science isn’t done in a “graphical language”.

Really? There is an IEEE conference on just that topic, though they prefer visual languages. I guess they aren’t working on real CS problems like turning a wheel.

Greg McKaskle

Tell that to the kid who makes almost twice as much as I do (an engineer with 20+ years of experience) straight out of college who was only hired because he was an excellent labview programmer. Labview is way more than powerful enough for your swerve drive, and Id argue that it’s debugging tools and more sophisticated built in control signal processing and analysis libraries would make it more practical and less work than c++.

How are you planning to decode that PWM signal?

We have been using LabVIEW, and it’s been fine for our swerve drive.
We run the closed loop control on the cRIO for our absolute encoders (using 4 PIDs), and speed has not been an issue.

Could you post a couple more details?

  • are you using CAN or PWM to send commands to the motor controllers

  • what part number encoders are you using

Right now I would say the answer to you question is " I don’t know". I have not seen any documentation on the new can controller that details the firmware on the controller. It would be allot to ask for the controller to handle timing of a PWM signal, Modulo math and be 5 volt tolerant. The hardware is most likely able to do what you want but would require CRE to write some very specific firmware. If they did include this type of control option, they would probably do it for an analog sensor output. This would still have the problem that most absolute affordable analog rotary position sensors are based on 5 volts and they most likely have a 3.3 volt chip in the controller. So right now I would not plan on closing the loop on the can controller. Why did you choose a PWM solution? We have used an analog voltage sensor and it works fine. I don’t like ma3’s. 0-5 volt can give noise error at the bottom and they are a little sloppy at the top. The sensor we use is .25 to 4.75 V output. We had problems with static electricity and the MA3s years ago. Do not know if they have improved. There are cheaper options. While pricey, there are some nice SPI based rotation sensors on the market. They eliminate the analog ratiometric issues and allow the 0-360 point to be programmed. Gives a software calibration as opposed to mechanical calibration. I would not want to go into build season with out a working swerve module and developed software. Even with a mature module and software, swerve puts a severe load on the team resources. In my opinion, any team that does not have a working swerve platform by now or in the next couple of weeks, should put it aside and go forward as a 2015 off season project. An off the shelf frame and 6 cim tank drive can meet the needs of many teams. Even after a team gets a working drivable swerve system, the hard work begins with driver training.

First, congratulations on wanting to push the envelope. Just some caution: This makes a great off-season project, where you can figure out exactly “how” to do it all. The 6 weeks of build season is a bad choice of time for learning all this: You have too much else going on at that time. Consider putting off implementation on a competition robot until next year. (It is a good path to failure and frustration, otherwise)

That being said:

  1. Yes, you can use most any kind of sensor for feedback on pod position, including an analog absolute encoder. But the evaluation of that sensor may need to be done in the RoboRIO, and not directly in the Jaguar. Not a big issue.
  2. Not really, they can all do it, and all very well. The ONLY advantage would be if someone knows a particular language better than any of the other languages. In your case, it appears LabView would be the logical choice.

Encoders won’t lose counts due to the steering speed. We used then an entire season without issue. Its actually s relatively slow rpm by FRC standards.

Control system brownout can cause loss of counts though.

More details please. e.g. If you are speaking from personal experience what is the part number of the encoders, how did you have them mounted, and how were you decoding the signal?

Hey guys thanks for your replies. First off, I thank you all for your concern about us pulling this off, however we have a working prototype from last year. It is crude, using team 226’s pods and a 1 turn pot to get position, but it works. We are simply refining the design… a lot.

As I said we have already got the mechanical drawings done, we just have to be careful not to actually make a final version yet due to rules. If I am reading the rules right, unless you make significant changes to your drive system you can not make this an off season project and be FRC legal.

I can get an analog input version of the sensor or I can use a low pass filter to make the PWM an analog signal so that’s no problem. As it is mentioned earlier there is a risk that the signal having noise at the top and bottom which will cause a problem. This could probably be fixed by using two encoders per pod being offset by 180 degrees. A more elegant solution would be just to figure out how to get a duty cycle of a PWM input in Labview to get the position. Or better yet use the Jag’s CAN closed loop to hold a position with PWM (If it was supported).

At this point we have enough data from last year to know that our mechanical systems work well enough. They were heavy and geared wrong, but our updated design should fix those problems. We think our code should be very close to what we need since it did work decently last year. The 2 problems we had with code that we need to fix was. 1. The robot lagged. It was about ~100ms late responding to changes. 2. We had noise around the top and bottom of our pot signal.

Our solutions are. 1. Use close loop CAN instead of analog input to PWM output in order to reduce lag in system. (Maybe the RoboRIO will be powerful enough to fix this on its own). 2. Use PWM input on an absolute encoder instead of a $3 single turn pot to eliminate noise around the top/bottom of the pot signal.

We also added slip rings in addition to the encoder to enable continuous rotation of our pods which gets rid of the last issue of unwinding.

I thought you could use PWM to control a closed loop CAN but it turns out to be just quadrature that is supported. (Which is just 2 PWM signals plus an index signal)

So what I have gathered so far from the responses is 1. Switching from lab view to anything else will not likely fix or help our lag issue from last year. 2. PWM input from an absolute encoder will not work in a closed loop. 3. Analog input for an absolute encoder will not work in a closed loop. So my questions are. 1. Can you use quadrature input which is supported by a closed loop to get position of the pod? (I assume it would required a quick 360 at the beginning of the match to get the index and then just keep up with position from there) 2. If quadrature input to closed loop CAN will not work to control position, then what do swerve teams use? (If it isn’t closed loop how do they deal with lag in the system?)

Again thanks for your responses and I look forward to hearing more from you guys.


We’re using PWM.
All I know is that we use analog absolute encoders, I don’t know the part number. Maybe I can look it up.

The roboRIO is indeed faster, and it has multiple cores, but if you were able to analyze the existing code and identify why it is lagging, that would give you a big head start. Do you have ideas why it is lagging? CPU usage numbers, graphs of sensor readings for known transitions, control updates on the same time scale?

Greg McKaskle

Assumptions to be made at this time - chances of the new can motor controller having a rich enough firmware to handle the positional control of the module steering is very low, even less for PWM sensor input. The robo rio will have to close the loop. The robo rio should be more than fast enough to handle the well written swerve code and any other robo processing. Vision is the exception.

We use labview and lag is not a problem. 1st year we did. The code did not embrace data flow. One source of lag is the reading of the sensors. Is it in a periodic task or the main teleop loop?

Jaguar only supported a single input gear tooth sensor, quadrature encoder inputs, and an analog input (0-3V) as closed loop sensor inputs. It never supported a PWM input as a closed loop sensor input.

But you should be able to use an absolute analog encoder output on a Jaguar provided that it is within the input range.

I didn’t say that visual languages were useless. I also didn’t say that they weren’t a serious area of study. I said that they weren’t used to do real computer science. I guess should clarify. Would you use a visual language to do cutting-edge work in any of the following areas:

-Data structures
-Formal verification
-Information theory
-Artificial intelligence
-Computer graphics
-Distributed systems

I think the answer is no. I’m not saying that it’s impossible. I’m saying that it’s not done, or at least it’s very unusual.

We just read them in the main teleop.