Which sensors should be used throughout the robot?

[thatprogrammer]

Note: This is in response to a disucssion I had with 971's technical mentor, thanks for the help!
I've been wondering what sensors are the "best" for certain areas of the robot. The areas I'm thinking of are: Fly wheels, Elevators, turrets, and drivetrains.
What different sensors have you used for these applications, and how have you found them?

P.S. Has anyone used the S4t? Am I right in my assumption that it doesn't rotate?

[GeeTwo]

That's about like asking what is the best gear ratio: it depends.

And speaking of depends, that's proven to be the most critical feature when it comes to selecting which limit switch, encoder, camera, potentiometer, rangefinder, or optical interrupt (we've used all of these at one time or another) -- that it be dependable. A flaky sensor is often worse than none at all.

We've gotten sensors from AndyMark, RobotShop, Lynxmotion, Adafruit, Mouser, Jameco, McMaster-Carr, and even Radio Shack. We even played with some magnetic reed switches from Home Depot or Lowes. That's probably not a complete list.

[z_beeblebrox]

We've had good experiences with the AMT-102 encoders, which are inexpensive and robust.

We also like these reed switches for proximity or limit sensors. They're easy to mount and more durable than mechanical switches.

[thatprogrammer]

Originally Posted by z_beeblebrox

We've had good experiences with the AMT-102 encoders, which are inexpensive and robust.

We also like these reed switches for proximity or limit sensors. They're easy to mount and more durable than mechanical switches.

How exactly are the reed switches programmed? Same as limit switches?

Thanks for the feedback so far, keep it coming. Would like to use the same sensor *encoder, ir, ect* in as many places as possible!

[z_beeblebrox]

Originally Posted by thatprogrammer

How exactly are the reed switches programmed? Same as limit switches?

Yes.

[Thad House]

Encoders such as Greyhills or S4s on drive and elevators. Some teams like 10 turn pots on elevators, but I think encoders are easier. Then hall effects for indexing, or anywhere you would use a limit switch. Pots work better for arms because indexing an arm is hard. Any type of object indexing we use beam break sensors, which we buy from Adafruit. Then for shooters you either need a fast reacting beam break, or the smallest CPR encoder you can find.

[jajabinx124]

Originally Posted by thatprogrammer

How exactly are the reed switches programmed? Same as limit switches?

Reed switches and limit switches are both digital inputs that return boolean states, so both would be programmed the same.

[garyk]

Originally Posted by jajabinx124

Reed switches and limit switches are both digital inputs that return boolean states, so both would be programmed the same.

Just to clarify - a "limit switch" is not a special kind of switch, it's a switch that we use to limit motion. One doesn't buy a "limit switch", you choose among microswitches, optical switches, magnetic [reed] switches, ..., for a switch that mechanically fits and triggers at that point in the motion of whatever you need to stop on your robot. They are not wired directly to a motor, but to a Digital Input on the roboRIO/cRIO/Arduino, etc. The program running on that computer will sense that the switch has opened/closed and will control that motor's Jaguar/Victor/Talon speed controller appropriately.

[Necroterra]

Originally Posted by thatprogrammer

How exactly are the reed switches programmed? Same as limit switches?

I see people already let you know that you can use these magnetic reed switches as a standard DigitalInput, or set it up as the Limit Switch on a TalonSRX, but there's a few others. The class Counter can be used as such:

Counter reedSwitchWatcher = new Counter(channel)

or

Counter reedSwitchWatcher = new Counter(digitalInput)

As well as a few others. This tells the FGPA to directly watch the digitalInput and count when it is active / rising edges / falling edges / whatever you set it to. This means you don't have to check the switch as often as you would if you were accessing it directly, and you can use it to act on a switch's activation much more precisely.

There is also an Interrupt system built into the processor, but I never used it. From what I understand, it's essentially an event handler which executes a function handler when a DigitalInput is fired.

[AustinSchuh]

Originally Posted by Necroterra

There is also an Interrupt system built into the processor, but I never used it. From what I understand, it's essentially an event handler which executes a function handler when a DigitalInput is fired.

Interrupts work, but have about a 100 uS delay between when the interrupt triggers and it gets captured. That is assuming that you are running the interrupt code in C++, have it in a thread, and have bumped the RT priority up of that thread so that it is very high priority. We have used them to capture the encoder count when we pass by a hall effect (or when we see an index pulse).

The FPGA image on the roboRIO supports DMA. That lets you save the state of all of the sensors, counters, and encoders to a buffer every time the event happens, and then go retrieve it when you have time. We patched WPILib last year to enable it, but the patches should be upstreamed this year. DMA is very handy and useful. This is how we calibrated 4 of the 5 encoders this year on our robot.

[Necroterra]

Originally Posted by AustinSchuh

Interrupts work, but have about a 100 uS delay between when the interrupt triggers and it gets captured. That is assuming that you are running the interrupt code in C++, have it in a thread, and have bumped the RT priority up of that thread so that it is very high priority. We have used them to capture the encoder count when we pass by a hall effect (or when we see an index pulse).

What kind of delay is there on the interrupt system if you are running everything default, no thread priorities, on Java? I feel like 0.1-1 ms is more than a fast enough response time for virtually every FRC application, considering that other methods like CAN can have >10ms of cycle time, but I know think I remember hearing that you guys had overclocked the CAN rates too.

Also, I'm not super familiar with JNI or the fancier parts of WPILIB, but it looks to me like you just pass your Handler function into the FGPA, which I assume would be watching it on a specified thread already. It might be different if you are working with WPILIBC though, since WPILIBJ just stops once you hit the native calls and I don't remember where/if you can look up with implementation.

[thatprogrammer]

What are some good gyros to use? I know the nav-x is supposed to be good, but my team would rather use something a bit simpler. Are there any special changes needed in the code if the gyros used are not the KoP ones?

[madz]

Can some of these be used for FTC this year with the new control system?

It says it will take digital, analog, PWM, and I2C. I'm trying to learn about the new sensor possibilities before the season starts.

http://www.modernroboticsinc.com/cor...rface-module-2

[Knufire]

Originally Posted by madz

Can some of these be used for FTC this year with the new control system?

It says it will take digital, analog, PWM, and I2C. I'm trying to learn about the new sensor possibilities before the season starts.

http://www.modernroboticsinc.com/cor...rface-module-2

Almost all of the sensors used in FRC are either digital or analog.

Describing both is pretty simple. Most sensors that return a on/off or true/false value are digital sensors. These include things like the brake beam sensors and hall effect sensors lifted.

Analog sensors are continuous, and ususally output a voltage between 0V and 5V. A potentiometer would fall in this catagory.

Of course, check with the FTC Game Manual when it is fully released to make sure that whatever sensor you're trying to use is legal. I don't see a technical reason why most of the sensors on this thread couldn't be used on a FTC robot.

Encoders are a bit counterintuitive; they actually take up two digital ports.

[marshall]

Originally Posted by thatprogrammer

What are some good gyros to use? I know the nav-x is supposed to be good, but my team would rather use something a bit simpler. Are there any special changes needed in the code if the gyros used are not the KoP ones?

As with most engineering, there are trade-offs. I'm not entirely sure what you mean by "simpler". Do you mean electrically? Do you mean code? Do you mean cost?

A lot of the single purpose gyros have significant drift that you have to account for, including the gyros included in the Kit. As for code, you'll need to look at the sensor you are looking to use and start by searching for existing code/libraries that other teams or people might have created. If that doesn't work then you need to reference the datasheet for the part and start writing your own libraries.

I can tell you that from a "getting started" standpoint, the LabView samples with the Kit sensors are a great place to begin. I suspect the C++/Java samples for those sensors are good places to start as well.

For our team, we're big fans of the NavX (we also wrote and maintain the LabView libraries with Scott's gracious help). It is simple to code for and provides a fused heading without a significant amount of drift for field oriented driving.

I hope that helps.