Swerve questions (Languages, CAN)

[Greg McKaskle]

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

[Gdeaver]

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?

[s1900ahon]

Originally Posted by bharrison6

Or better yet use the Jag's CAN closed loop to hold a position with PWM (If it was supported).

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.

[SoftwareBug2.0]

Originally Posted by Greg McKaskle

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.

Originally Posted by magnets

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

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.

[bharrison6]

Originally Posted by Gdeaver

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?

We just read them in the main teleop.

[bharrison6]

Originally Posted by Ether

How are you planning to decode that PWM signal?

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?

[Greg McKaskle]

I said that they weren't used to do real computer science...

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

[bharrison6]

Originally Posted by bharrison6

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?

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?

[Ether]

Originally Posted by bharrison6

Yes we want to decode it and use it rather than use analog because it will be more precise.

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?

I think all I need to do is figure out how to read the duty cycle of the PWM input.

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

Since you ask, do you know how to decode the [PWM] signal

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.

just put a low-pass filter on it and run it as analog.

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

will using a pwm w/ low pass filter effect the quality of the analog signal vs just buying a regular analog absolute encoder?

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

[Ether]

Originally Posted by bharrison6

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?

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.

[Greg McKaskle]

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

Greg McKaskle

[Ether]

Originally Posted by Greg McKaskle

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

Greg McKaskle

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.

[Zaque]

Originally Posted by bharrison6

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

...

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?)

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.

[Jared]

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.

[Greg McKaskle]

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