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