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/en...tary/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

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

We have ordered the 10 bit pwm version.

Re: Swerve questions (Languages, CAN)
 

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.

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

Re: Swerve questions (Languages, CAN)
 

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++.

Re: Swerve questions (Languages, CAN)
 

How are you planning to decode that PWM signal?

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

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

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

Bryant,
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.

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

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?

Re: Swerve questions (Languages, CAN)
 

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.

-Bryant

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

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

Re: Swerve questions (Languages, CAN)
 

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?

Re: Swerve questions (Languages, CAN)
 

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.

Re: Swerve questions (Languages, CAN)
 

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
-Cryptography
-Networking
-Distributed systems
-Databases

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.

Re: Swerve questions (Languages, CAN)
 

We just read them in the main teleop.

Re: Swerve questions (Languages, CAN)
 

I'm sorry I missed this earlier. Yes we want to decode it and use it rather than use analog because it will be more precise. I think all I need to do is figure out how to read the duty cycle of the PWM input. I know its not easy but I think it is supposed to be possible. Regardless if we can figure out how to do it then we just put a low-pass filter on it and run it as analog.

Since you ask, do you know how to decode the signal and if not will using a pwm w/ low pass filter effect the quality of the analog signal vs just buying a regular analog absolute encoder?

Re: Swerve questions (Languages, CAN)
 

From my experience, real computer science is often done with borrowed mathematical notation, proofs, and usually some library that is grafted to an existing language favored by the author or advisor. Graphical or visual aspects may be included when they relate to content entered by or presented to end users of the research. UML is a good example of formalized graphics. Sketch systems are another. Visual query specification for databases is a thing too. Perhaps the most important to this discussion are domain-specific languages such as those developed by MIT Media Lab, NI, and LEGO.

I simply saw no reason for the statement to be in this thread. The majority of programming in the real world is done by technical people who do not have a CS degree. All technical professionals should learn how to program and be given the correct tooling to make them successful. Just as math courses aren't only for math majors, FRC programming isn't only for future CS researchers.

Greg McKaskle

Re: Swerve questions (Languages, CAN)
 

I just looked at Lab View and found the PWM Get Value function under the WPI -> I/O -> PWM -> Get Value. I am guessing I can't just plug the pwm into the digital side car can call this function since the Digital Side Car to my knowledge only outputs PWM, it can not read the PWM?

Re: Swerve questions (Languages, CAN)
 

How did you determine that it will be more precise? e.g. Did you consider the tolerances in the encoder datasheet as well as the tolerances in the decoding methods?

"all I need to do"... How do you plan to do that?

I've heard the FPGA sampling frequency will be bumped up from ~153KHz (in 2014) to ~1MHz (in 2015). Maybe the FPGA will be programmed in 2015 to read duty cycle (detect and report consecutive rising-to-falling and falling-to-rising edge pairs). If so, you could decode the PWM quite accurately using that. Otherwise, you'd probably need to use high-priority interrupts to detect and time-stamp the edges. I don't know what the interrupt latency will be in the roboRIO with LinuxRT and WPILib and LabVIEW.

How much filtering would be required to reduce the analog noise to an acceptable level, and how much phase lag would that introduce?

My guess would be yes, but I haven't looked at it in depth.

Re: Swerve questions (Languages, CAN)
 

There will be no DSC in 2015. That function will be integrated into the roboRIO.

See my previous post for thoughts on how a PWM signal might be decoded using digital inputs.

Re: Swerve questions (Languages, CAN)
 

Be sure to read the documentation or description for the Get PWM function. Names can be misleading.

Greg McKaskle

Re: Swerve questions (Languages, CAN)
 

Hi Greg, your post was linked to mine in the threaded view. But I assume your comment was for bharrison6, not me?

My post was not intended to endorse bharrison's inference that "Get PWM" is for decoding an input PWM signal... but rather the opposite. If I need to clarify my post please let me know and I will do so.

Re: Swerve questions (Languages, CAN)
 

I wanted to mention something here to keep others from getting confused. I think when you say "closed loop" you are referring specifically to using the closed loop control on the speed controllers. However, any system that uses sensor feedback is closed loop, whether the feedback is on the speed controller, the roboRIO, or some other controller. So those sensor outputs are usable for closed loop control, just not on the speed controllers.

Re: Swerve questions (Languages, CAN)
 

Your encoder will need to be used with the FPGA or with interrupts in order for it to work properly. Your user code which runs on the CPU would need to run impractically fast to decode the encoder PWM.

You have a few options to try to decode this signal

You can do what Ether recommended, and try to use interrupts. This is likely more difficult than it sounds to get everything working properly. Also, interrupts and less commonly used features are likely the last priority of the roboRIO development team and beta testers, so you may encounter strange, hard to diagnose issues with interrupts.

You could also attempt to read the encoder on a separate device, like an arduino or basic stamp. There are likely software libraries that exist for reading an encoder like this already. If not, you could likely write your own using the "pulseIn()" function on the arduino. You can connect the arduino to the roboRIO through a serial connection very easily.

Re: Swerve questions (Languages, CAN)
 

Yes, Ether. I was responding to the OP. Sorry, but I don't use the threaded view and I simply clicked the Post button. I may need to pay more attention to that in the future.

Greg McKaskle

Re: Swerve questions (Languages, CAN)
 

Hi Jared,

Good suggestion. The arduino (or other microcontroller) could certainly decode the PWM pulse width. (Complexity and cost should be factored into any final decision.)

Decoding PWM duty cycle (which is the datasheet-recommended way to decode the PWM signal for the MA3) would require measuring both the pulse width and the period (or the associated non-pulse width) for the same cycle. I don't think the 2014 FPGA is programmed to do that.

FTR, I wasn't recommending using interrupts (on the RIO). I was trying to discourage that idea.

Re: Swerve questions (Languages, CAN)
 

we haven't got the encoders in yet perhaps we will just get the analog encoder instead which should reduce complexity significantly. thanks for all the responses I'll give you an update once we get the encoders In and get this thing running. we are currently making a wooden prototype Of our new pod as we speak

Thanks Bryant

Re: Swerve questions (Languages, CAN)
 

The original poster was considering changing languages. How helpful a language would be to a student who wanted to study computer science is an appropriate consideration.

Furthermore, even for people who aren't going to study computer science it would be more useful to know a general-purpose language. The world of programming is larger than the core CS topics but it's also larger than controls and data collection. If you were choosing what to teach based on what would be most useful to a majority of students you'd probably teach them a scripting language or if Excel macros.

Re: Swerve questions (Languages, CAN)
 

Why do you say that? Jaguars have a potentiometer mode. Do you know something that makes that mode unsuitable for this application?

Visual languages are used to do cutting-edge work in control systems, signal processing, and image processing. Those seem particularly relevant to FRC.

Re: Swerve questions (Languages, CAN)
 

I'm surprised to hear that you have control lag...I'd also add that the analog MA3 absolute encoder is great for this application. We always use them on our steering.

For reference...the robot linked below is running four independent propulsion loops and four independent steering loops on a run of the mill Arduino.

No lag, plenty of accuracy.

http://www.team221.com/viewproduct.php?id=146