Which sensors should be used throughout the robot?

[wireties]

We use encoders on the wheels and prefer limit switches on elevators and beam breaks to track game pieces. The Grayhill encoders are pretty tough and smooth. This year we used hall effects from wcproducts and loved them. For beam breaks we like the Optek OPB720B family. We are getting away from mechanical limit switches unless we can protect them so there is no bending or stress. Going past the optical or hall effect sensors is not as big a problem as mechanical sensors.

Finally the maxbotix sensors are great for ultrasound ranging and the ADXRS453 the best gyros (at a reasonable cost) we've used lately.

[Max Boord]

Originally Posted by Thad House

It also cost more then $200 just for 1 50 inch one. An encoder is a much cheaper option, and your only option in budget if you need more then 50 inches of travel.

We 3d printed an adapter and housing to connect a tape measure to a 10 turn potentiometer as our lift has around 60 inches of travel. Total cost: around 1/4th of an encoder. We also could not use an encoder easily because of our gearbox configuration.

[topgun]

A question for those teams trying to limit the use of mechanical limit switches, don't you need some to have a "dry" connection to stop your mechanism at the extreme limits?

We have used and continue to use mechanical limit switches to feed directly into the jaguars to stop the jaguar if the limit switch is hit. We have struggled to mount them securely and precisely so they do the job without breaking. They always seem to be an afterthought. So I am looking for something better.

[wireties]

Originally Posted by topgun

A question for those teams trying to limit the use of mechanical limit switches, don't you need some to have a "dry" connection to stop your mechanism at the extreme limits?

If I understand you, this is not allowed in FRC. You can't route power through a limit switch. Switches must be routed back to the roboRio or, in recent years, to the speed controller. I think using mechanical switches is a good idea if a mechanism is against a hard stop (so you can't go past the switch).

HTH

[marshall]

Originally Posted by topgun

A question for those teams trying to limit the use of mechanical limit switches, don't you need some to have a "dry" connection to stop your mechanism at the extreme limits?

We have used and continue to use mechanical limit switches to feed directly into the jaguars to stop the jaguar if the limit switch is hit. We have struggled to mount them securely and precisely so they do the job without breaking. They always seem to be an afterthought. So I am looking for something better.

It's always a mix. We implement mechanical stops when we need them and then implement robust limit switches (Trust me, we're still refining what robust means). I really like the coil spring style switches though since they can be easy to trigger and hard to permanently break:

http://www.amazon.com/ME-8169-Flexib...qid=1438006707

[mipo0707]

gyros and encoders

[marshall]

Originally Posted by mipo0707

gyros and encoders

I have to take a moment and point out the amazing NavX board from Kauai Labs: http://www.kauailabs.com/store/index...&product_id=56

It integrates directly with the RoboRIO and provides a single fused heading as well as individual sensor feedback.

There has been a lot of work going on the last few weeks for making the LabView libraries even more robust for the board for the coming season. I suspect the other platforms are seeing similar upgrades.

[GeeTwo]

Originally Posted by Max Boord

We 3d printed an adapter and housing to connect a tape measure to a 10 turn potentiometer as our lift has around 60 inches of travel. Total cost: around 1/4th of an encoder. We also could not use an encoder easily because of our gearbox configuration.

We managed without a 3-d printer. We used a knob from radio shack as a hub to connect the tape measure reel to the potentiometer. We drilled a hole in the top of the knob, and ran the shaft backwards into the ferrule. We attached the "bottom face" of the knob to the tape measure reel using plastic model glue. The hardest part was winding the spring back up. I posted some preliminary pics here back in February.

[AustinSchuh]

Originally Posted by Thad House

So the input shaft of the encoder is 1/4 inch. So its press fit in. Then teams zip tie the wires down, which stops the housing from spinning.

We drill a 1/4" hole and then tap a small hole in the side so we can set-screw the encoder in. I've seen too many encoders that were slipping when we thought they weren't to risk it anymore...

Be careful zip-tieing the wire down. I've seen cases where there was added backlash due to the wire moving when changing directions. We now always make a small lexan bracket and use that to secure the encoder rotationally. It couples the high frequency information in much better.

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