Chief Delphi - Swerve questions (Languages, CAN)

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)

- Programming (http://www.chiefdelphi.com/forums/forumdisplay.php?f=51)

- - Swerve questions (Languages, CAN) (http://www.chiefdelphi.com/forums/showthread.php?t=131266)

Re: Swerve questions (Languages, CAN)

Quote:

Originally Posted by Jared (Post 1410405)

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.

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)

Quote:

Originally Posted by Greg McKaskle (Post 1410394)

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.

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)

Quote:

Originally Posted by Tyler2517 (Post 1410295)

I do not believe that you can use the closed loop control for the analog absolute controllers.

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

Quote:

Originally Posted by SoftwareBug2.0 (Post 1410358)

I guess should clarify. Would you use a visual language to do cutting-edge work in any of the following areas:

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