Which sensors should be used throughout the robot?
 

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?

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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!

Re: Which sensors should be used throughout the robot?
 

Yes.

Re: Which sensors should be used throughout the robot?
 

I've used the S4 in several different applications. Can you clarify what you mean by doesn't rotate?

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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

Re: Which sensors should be used throughout the robot?
 

I seem to have misunderstood this sentence on the us digital website, sorry! "The S4T miniature optical shaft encoder is a non-contacting rotary to digital converter." My lack of experience with shaft encoders let me to assume that this meant the encoder literally doesn't rotate.

Have you ever experimented with beam breaks for shooters? Any issues with programming or voltage (I've heard a few don't work below 12v?)

Note: To clarify, you mean limiting the range of something by indexing? Like using a limit switch to stop an elevator?

Re: Which sensors should be used throughout the robot?
 

We used beam breaks in 2012 and 2013 for our shooters. I don't know which models, but they were easy to use, and we didnt have any trouble. They were 5V models though, but since we now have a regulated 12V from the VRM, 12V ones should be fine too.

I probably used the wrong word for indexing. For elevators and arms, if using an encoder, you have to have a limit switch/hall effect at some point to zero it. And that is harder with arms then with elevators.

Re: Which sensors should be used throughout the robot?
 

The silver shaft rotates. You mount the encoder with a nut on the brass-colored threaded portion, which will also hold the black housing stationary.

Re: Which sensors should be used throughout the robot?
 

From what I've seen, most teams just mount these by drilling a quarter inch hole and putting them in. How does the shaft still spin with the axle if the hole is a larger diameter than it is?

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

Okay, I thought you'd simply need to select the 1/4 inch diameter option for the encoders.
When would you use a high cpr vs a low cpr? It seems to me that using a high cpr encoder on a fly wheel might overwhelm the fpga. Any formula to figure out the max possible?

One last question: 971's mentor mentioned their robot featured:
How much % of error can one expect simply using an encoder rather than this set up? Is this set up really necessary or simply a practice that, while good for inspiration and education, is a bit overkill?
Thanks for all the help so far!

Re: Which sensors should be used throughout the robot?
 

High cpr is good for accurate distance, but pulse timing gets pretty jumpy when moving fast. Low cpr allows for smoother pulse timing at high speed. We usually run 256 cpr at 4x for distance, and 6 cpr at 1x, which works great for anything faster then 1000 rpm.


As for distance accuracy, 256 cpr at 4x with a 1.125 inch spool gives an accuracy of 0.003 inches per pulse. That is way more accurate then ever needed, and controlling to that accurate isn't possible.

Re: Which sensors should be used throughout the robot?
 

I really love the allen-bradley photosensors from 2011 KOP. They come in super handy for indexing of game pieces, rpm measurement, elevator indexing (homing). The square body and threaded barrel make them easy to mount and they do a great job at rejecting IR light interference from the field lights.

We also had a good experience with the AMT10-V encoder this year. The CPR of the encoder can be adjusted via on-board dip switches and they can be mounted on shafts from 2-8 mm (1/4",3/16",1/8") making them exceptionally versatile. At $23 a piece we can keep lots spares around.

Re: Which sensors should be used throughout the robot?
 

I don't know what brand/model specifically we use, but:

Drivetrain - Encoders
Elevator - Combination of Encoder and String Potentiometer, as well as Limit Switches to detect the ends and to zero/calibrate
Flywheels - IR/Photo Sensors
Proximity (detecting whether there is a tote/can in the robot or not) - Ultrasonic and/or IR/Photo Sensors

We also used a Limit Switch last year to determine when our catapult had returned to its starting position. The most common sensor we use is definitely IR/Photo (other than the encoders on the drivetrain) because they're so versatile.

Re: Which sensors should be used throughout the robot?
 

What ir sensors would everyone reccomend? Same question for retroflective sensors.

I assume any sensor that's digital and merely returns a boolean value can be programmed the same as a limit switch?

Re: Which sensors should be used throughout the robot?
 

http://m.ebay.com/itm/190892864042?_mwBanner=1

These are from China and take absolutly forever to ship, but if you stock up on them now they're great to have, especially given the price.

We used them everywhere this year, two to sense totes, two to sense the tape on the floor for our 3 tote, and one to sense a container. Last year we used it to sense the limit on our catapult. Just don't be foolish like us and point two towards each other to try and sense the totes, you'll end up bending a sensor mount up so they don't interfere. :rolleyes:

http://www.wcproducts.net/sensors

I also love these made for FRC sensors, thanks 971! We used them as the upper and lower limits for our elevator. Put velcro on the sensor and a 1/8 rivet on the magnet and you have an easily adjustable, great sensor.

Between these two sensors we've totally eliminated our use of pesky limit switches. I love their price and their ease of use.

Re: Which sensors should be used throughout the robot?
 

Our school is unlikely to allow us to buy stuff through ebay. Any similar sensors from a more official website? Thanks!

Re: Which sensors should be used throughout the robot?
 

Have you tried them for a flywheel?

Re: Which sensors should be used throughout the robot?
 

No.

Re: Which sensors should be used throughout the robot?
 

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:

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

Re: Which sensors should be used throughout the robot?
 

Re: Which sensors should be used throughout the robot?
 

Here is a basic chart of what I've come up with so far, based on responses in this thread:

Re: Which sensors should be used throughout the robot?
 

A cheaper more durable alternative to the 971 WCP sensor are these inductive proximity sensors.
http://www.ebay.ca/itm/New-LJ12A3-4-...em338fe7 6170

Since they are inductive instead of magnetic they can be triggered by anything ferrous like a steel rivet.

There are also magnetic hall effect versions http://www.ebay.ca/itm/Hall-Effect-H...em487c2a 613c

Re: Which sensors should be used throughout the robot?
 

Alternate Amazon links for those in need:

http://www.amazon.com/Effect-Sensor-...y+Switc h+NPN

http://www.amazon.com/Amico-DC6-36V-...J12A3-4-Z%2FBX

Re: Which sensors should be used throughout the robot?
 

After accidentally posting in battlebots thread...

We used these Chinese encoders in place of S4's for practice bots to save some money.

They're way bigger, but worked well for us. Took about two weeks to get to us.

Re: Which sensors should be used throughout the robot?
 

Arms: Potentiometer. Encoders have to be zeroed every time the robot boots up which can be a problem if the arm starts in a different position in each match.
Elevator: String Potentiometer. They output a value directly proportional to lift height. This is how 1065 measured our lift height this season.
Flywheel: Optical. Encoders produce too much information for this and caused problems for us in 2013 before we switched to optical measurement on our shooter.
Stops: Hall effect/ Optical. They don't break like limit switches do. We used them as a backup to our string potentiometer this year to prevent from hitting hard stops. They output a solid state signal and some have a 3rd "reversed output" wire.
Hoppers: Limit switches or optical.
Drive: Encoders for distance, Gyro for orientation. Use 2 gyros 1 upside down positioned above or below to account for gyro drift. Make sure the driver can zero it if the gyros are used for field oriented omni drive.

Re: Which sensors should be used throughout the robot?
 

String pots work well for a game like this year, but most years they are not a good option. Most elevator games need more then 50 inches of travel, which was the longest we could find. 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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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

Re: Which sensors should be used throughout the robot?
 

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

Re: Which sensors should be used throughout the robot?
 

gyros and encoders

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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?

Re: Which sensors should be used throughout the robot?
 

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

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

Most teams will never notice latency issues. 971 happens to be special in that we design complicated systems which require tight timing to make work at the levels of precision and reliability that we target.

Tom from 254 reports that he was able to get it down to ~2 ms in Java. I have never used Java on a FRC robot, so I can't confirm or deny. When 254 was doing thread.sleep, to time a loop in a separate thread, he reported up to 0.25 seconds of latency.

Latency can be modeled as another source of noise. We used the fast response time to zero our claws in 2014, and other systems this year. Our control loops could hit somewhere in the order of +- 0.002 radians, and measure another order of magnitude more precise than that. If you are zeroing at 2 rad/sec, that means that you are going to add 0.002 rad of noise per millisecond of error. To hit 0.0002 rad/sec (below your positioning accuracy by an order of magnitude), you need to move at either 0.2 rad/sec or have less latency.

I'm not sure where you heard the rumor that we over-clocked CAN, but we chose to not use CAN after benchmarking the latency of it and looking at the other options (and it being new). We couldn't figure out how to synchronize our control loops with the CAN send cycle, and after hooking up some external CAN monitoring equipment from my work, saw high peak latency on the bus. PWM is a known quantity, so we moved on. Reading sensors over CAN has the same issues you described, so we kept them connected to the FPGA so we could read them faster. (The FPGA is memory-mapped into the process's address space, which makes accesses fast.)

The WPILib C implementation uses NI's library, which spawns a thread, does an ioctl until the interrupt happens, and then calls a handler function. Similar to you, I don't know how that interfaces with the JNI/Java code and the GC.

Re: Which sensors should be used throughout the robot?
 

I see now why such accuracy would be necessary, we never aimed for anywhere close to that level of detail.

So if I understand this DMA thing, the FGPA reads off the sensor values on an event happening, and the relatively slow accessing of the memory can be done later? Wouldn't that still give you inaccurate data unless you added on the expected change since it was read?

Also, by upstreamed, do you mean it will be part of default WPILIB?

Also, I read about CAN a while ago and iirc it isn't designed to have a specific frequency of changing the message frame, it just does it whenever it has time within a certain range. You can mess with the frequencies, but then you run the risk of maxing out the buffer. I would guess that it's intended for more complex data communication, and PWM is definitely better for a sensor that outputs a single value.

As for the JNI bindings, wpilibJ loads up a library called "libwpilibJavaJNI.so", which I would assume is either the NI library or a bridge to it.

Re: Which sensors should be used throughout the robot?
 

All of the WPILib code is public, but its kind of a pain to find. It also uses the NI implementation. This is the callback that gets called by the interrupt.

So any slowness with interrupts would happen in this function. My guess would be that it attaches the interrupt thread to a new JVM thread, and then gets sent to the JVM scheduler, which doesnt have to start the thread in Java immediately.

Re: Which sensors should be used throughout the robot?
 

For a gyro-IMU-AHRS solution we used the NavX MXP in 2015. It has worked for us, but we have had problems. We bought 2 boards. One has failed, will not initialize. We have had problems with the IO ports. Some are unusable and others are not reliable. We mounted our Roborio vertical. This forced us to use a cable between the Rio and the Navx. We use the NavX for 2 tasks. The NavX tells us which way our robot is pointing. (not which way our robot is moving). Second, it tells us if the robot is tilting. We fell over 3 times in competitions this year. We use the navx to stop us from tipping. If the the angle of tilt goes beyond x degrees, reverse the drive motors. It works.
For 2016 we are looking for a better IMU. We recently purchased a Arduino Shield with a Bosch BMO055 orientation sensor. It has a 3 axis accelerometer, gyro and magnetometer. Plus a Arm cortex M0 core running fusion code. Easy set up. Initialize the I2C port, write to a few registers and its running. We bought the Arduino shield for testing. Will use the Adafruit board on the robot if we go with it. Only have 1 hour of testing. Gyro, accelerometer fusion looks rock solid. Add in the mag and it is not good. Interesting is the linear acceleration output. It's a little noisy but with a little clean up could give direction of motion. Not suitable for distance. Better than the Invensense outputs. Looks good but you never know until it's on the robot.

Re: Which sensors should be used throughout the robot?
 

Scott from Kauai Labs has implemented some changes for the NavX recently that help significantly with mounting the sensor and improving the stability of readings. Also, you should contact him about the failed board, he might be able to help revive it. He's a really nice guy and he takes care of his customers. We ordered 2 and only received 1 but he made it right and it's been a good friendship since.

I wasn't aware of the Bosch sensor but it looks cool. Hopefully we'll see some additional MXP boards based around more sensors for this coming year.

Re: Which sensors should be used throughout the robot?
 

Please do send in the board that won't initialize, we'll get it replaced for you. Just send it and return address info to:

Kauai Labs
2371E Nimualu Road
Lihue, HI 96766

The updated firmware (it'll be loaded on your replacement board) includes the new Omnimount feature which enables vertical, horizontal and upside-down mounting, and has some reliability improvements. The addressing of the Digital IO pins has given folks some trouble, it has gaps in the address space, documented on this page. If you have details on a port that isn't working, please send that information along, too.

We're getting ready also to release new Java/C++ Libaries w/SPI support at 2Mhz, with that enhancement the measurement latencies and RoboRIO CPU usage are very low.

Which board are you are using w/the Bosch sensor? I'd like to compare the linear acceleration values it generates with those from the navX MXP. I'd agree Invensense has some work to do on accelerometer noise levels on the MPU-9250, but wasn't aware the Bosch sensor specs were that much better, am very interested to hear your findings.

Thanks,

- scott

Re: Which sensors should be used throughout the robot?
 

Do we have any idea if FIRST is going to fix the FPGA bug with SPI and I2C? It was nice finding a workaround, but it would be even better if they would fix the MXP ports.

Re: Which sensors should be used throughout the robot?
 

Will the new firmware be available to put on previous NavX boards or will teams who want the Omnimount feature be required to buy a new one? Hopefully it is the former.

Re: Which sensors should be used throughout the robot?
 

No word on a resolution by NI - it's likely been because we can't give them a reproducible case; Joe Hershberger of NI has indicated suspicion of a lock not being held correctly during opening of the MXP port, but that hasn't been confirmed.

However in testing it's been discovered that the various communication peripherals on the navX MXP are experiencing bus errors sometimes when the RoboRio is starting up (e.g., upon initial power up, and when "Reboot RobRIO" is selected in the driver station, but not when restarting the robot code). In these cases, a few seconds after the reboot occurs (about one in every ten times) I2C circuits on the navX (including - notably - the internal I2C bus which communicates with the MPU-9250) experience bus errors. My suspicion is that problems occur when the robot app opens a MXP port before the RoboRIO FPGA code that manages the MXP port has completed initialization, and the result is the navX MXP experiences random noise during that time. And the fact that an internal (non-MXP) I2C bus is experiencing error implies the noise is on the power/ground which are used to pull up the internal I2C bus lines. I haven't got it captured on a scope yet, but my hunch is there's a noisy MXP ground sometimes during RoboRIO startup.

[These errors can cause navX MXP comm to the MPU-9250 to lockup. The visible symptom of the internal I2C bus lockup is that only one of the two Green LEDs on the navX MXP will be lit up (in normal operation, both LEDs should be on).]

So the reasonable conclusion is that when using MXP-based SPI/I2C, the navX was being exposed to more of these glitches than when using non-MXP communication, and every now and then could no longer talk to the MPU-9250.

The recent navX MXP firmware has added code to detect these bus errors and reset the affected communication peripherals. In testing, we were able to reproduce the error, and demonstrate successful recovery by the navX MXP firmware. Based on that, I believe the latest navX MXP firmware is resilient to these transients. However these transients could impact other MXP devices too, so the plan is to document this and send the findings to NI and to the ChiefDelphi community.

I'll send out a general update to ChiefDelphi once the latest navX MXP firmware has passed all our tests and is ready for release; I'd recommend retesting at that time, believing the above was the root cause for the sporadic startup failures you saw.

Re: Which sensors should be used throughout the robot?
 

I didn't carry it out but it was an easy upgrade for ours. I'll let Scott elaborate on the process.

Re: Which sensors should be used throughout the robot?
 

The latest installation program will include a firmware installation utility, so that existing navX users can upgrade their existing boards to the new firmware. With this new utility, the firmware upgrade process is pretty straightforward.

An announcement will be posted on ChiefDelphi once the released version of this new firmware and the firmware update is ready for public consumption.

Re: Which sensors should be used throughout the robot?
 

Ah. Luckily we have the workaround, and with the new firmware allowing sideways mounting, we will probably just use that from the start. We wouldn't want to take the risk of the gyro failing mid competition again, and would rather run a few extra cables, especially since we have to run USB for power anyway.

Re: Which sensors should be used throughout the robot?
 

It's interesting that you have problems with the MXP. We experienced exactly the opposite. Our Lidar would simply not function on the dedicated I2C port on the roborio, but worked perfectly on the MXP port with the exact same code.

Anyway, this thread has been outstanding so far. I've always had trouble finding inexpensive sensors that work well for our system and have relied on what I've seen on other robots. For instance, one of our favorites was always the sick ZL1 series that we ordered from automationpartsexpress.com for under $40 (credit to 33 and Jim for finding them), but they seem to be out of business.

It'd be fantastic if people kept suggesting sensors they use. So far, I have this list:

Sensor Type Part # Website

Encoder, multiple shaft, multiple counts per rev AMT10-V http://www.cui.com/product/component...ar/amt10-v-kit

Magnetic reed switch / position switch 59140-010-ND http://www.digikey.com/product-detai...0-010-ND/43977

IR reflective 42EF Rightsight http://ab.rockwellautomation.com/Sen...tSight-Sensors

IR Reflective / cheap 30 CM E18-B03P1 http://www.amazon.com/6-36V-Photoele...lectric+sensor

Hall effect switch / position switch WCP-0971 http://www.wcproducts.net/sensors

Hall effect switch / position switch MC1104 http://www.amazon.com/Effect-Sensor-...y+Switc h+NPN

SICK photoelectric Z series IR sensors ZL1-E2415 Not available

So we've got IR reflective and hall effect reed/limit switches. What about cheap through beams (that aren't garage door sensors)? One of the nice features on the Allen Bradley RightSight was the manual adjustability so that it would work with reflectors, or even colored tape. It was also capable of 10000+ samples / second. What else is out there with those capabilities?

Re: Which sensors should be used throughout the robot?
 

I'd go back through this thread as well.

http://www.chiefdelphi.com/forums/sh...d.php?t=117219

Some very good suggestions by a lot teams.

Re: Which sensors should be used throughout the robot?
 

I'm not a programmer, but I would say a gyro would be very useful if you want to drive field-oriented.

Re: Which sensors should be used throughout the robot?
 

^

A gryo can be a huge help in autonomous. Our team used a gryo in autonomous and it was very simple to make 90 degree or 180 degree turns, making it simple to implement turns/movements.

So to make life easier for autonomous, definitely consider using gyros. You won't have to rely on random numbers that you think will make it turn or move the way you want it to, instead you can rely on a sensor.

Re: Which sensors should be used throughout the robot?
 

We were possibly looking to use the Bosch BNO055, but we were unsure of how to connect it to the RoboRIO (via Arduino or otherwise). Can you please explain how you did it and how difficult it was to do.

Re: Which sensors should be used throughout the robot?
 

Looks like it is an I2C device so you could break out the pins to the RoboRIO. I'd probably avoid the arduino and go straight for a breakout like this one: http://www.adafruit.com/products/247...VwFxoCpIzw_wcB

If you want/need to do some formatting of the stream first then I suppose you could go the RIOduino and shield route:

http://www.andymark.com/product-p/am...tm&Click=35018
+
http://www.robotshop.com/en/arduino-...icIRoCJTXw_wcB

Re: Which sensors should be used throughout the robot?
 

From what we've done in previous years you can use limit switches to do a lot in a very simple way, so when you have boolean aplications, like an arm that only has two positions switches can do the job very well. This year we've used them to set a zero point on our elevator, this way every time it went back down the zero on our encoder would reset to avoid problems with it getting lost. Our team really likes to use this kind of limit switch http://www.amazon.com/ME-8108-Adjust...s=limit+switch they are very robust, adjustable and cheap, so we can keep it simple and still do a lot with them.

Re: Which sensors should be used throughout the robot?
 

I agree with a number of posters on this thread that limit switches are very good and extremely valuable in FRC robots.

However, I want to emphasize one item. Do NOT overlook the mechanical design of the switch actuation. I have seem too many (including our own robot in 2014) switches that were designed to be impacted by a mechanism, versus acting in a bypass fashion.

Thanks

Re: Which sensors should be used throughout the robot?
 

This is why hall effect, beam break, and inductive sensors are great! Non-contacting is the way to go.

Re: Which sensors should be used throughout the robot?
 

Just to clarify, you use a beam break by using a piece of tape to reflect its own laser back to it, and if that laser is not reflected, it returns a false value?

Re: Which sensors should be used throughout the robot?
 

It depends on the specific switch, and how it's wired.

Generally you decide based on what you want the failure mode to be. Do you want a disconnected/broken switch to read the same as seeing an object? Or do you want a broken/disconnected switch to read the same as never seeing an object.

Re: Which sensors should be used throughout the robot?
 

Yes, part of WPILib. I sent out patches in December ish, but there were too many other issues for the patches to get much attention.

With DMA, you get to read the captured data when you want. But, that capture can include both the signal that changed, all digital inputs, the timestamp of the event, all encoder values, all analog inputs, etc. If you are trying to correlate a digital input change to an encoder value, that delay is fine. If you are trying to correlate an analog input with an encoder at an edge, the delay is also fine. And by delay here, I mean up to 5 ms for our system, since we run our control loops at 200 hz and only pull out of the DMA buffer at that frequency.

Re: Which sensors should be used throughout the robot?
 

Say you planned to use a beam break to detect if a tote was in the robot or not. When the beam broke, you'd know it saw the tote. In that case, would you use the tape to reflect back to it?
Thanks!

Re: Which sensors should be used throughout the robot?
 

What would you guys use to know the position of the robot on the field at all time? And do you know any not drifting gyro?

Re: Which sensors should be used throughout the robot?
 

The gyros we've used tend to drift as well, but the drift isn't significant enough to mess up movements. (At least in autonomous) Our team only uses gyros in autonomous, and when autonomous initiates we reset the gyro in the code (so it resets the drift right when auto starts, so we don't have to worry about drift). Since auto usually is 10-15 seconds, the drift isn't significant enough to mess things up for us.

I don't know any gyros that don't drift.

Re: Which sensors should be used throughout the robot?
 

So it would be pretty hard to get a good measure during an entire match... Could we use something else to balance?

Re: Which sensors should be used throughout the robot?
 

This is something that's actually very difficult to do.

Pretty much any gyro within FRC budget is going to drift, at least a little bit. Things like the NavX, or 2 gyros stacked on top of each other upside down can help, but since a gyro is a rate sensor, getting angle requires integration, and any integral error just adds up and compounds, which is actually what creates the drift. A compass could work if the motors didn't create so much interference, but with FRC robots compass's are not reliable enough.

Position is difficult as well. Things like encoders on drive wheels can give a start to position, but since you need a gyro to detect angle, you still get error, plus if your wheel's slip everything goes bad fast. You could use a non driven wheel to measure, but those can slip too, and you still have the gyro error.

The only good options that would be within FRC price ranges would be something like a FIRST provided HD camera above the field, that teams could use to track their robots. But with current items, getting 100% accurate position and angle of the robot throughout an entire match is not easy, and I would say its not possible within the current budget and DS rule limits.

Re: Which sensors should be used throughout the robot?
 

That is a neat idea... Hard to realise but pretty cool :)

My goal is to create a semi-autonomous robot (or autonomous if possible)...

Re: Which sensors should be used throughout the robot?
 

For a non-drifting gyro we use the NavX which only drifts 2 or 3 degrees in a match. If you wanted to track position you could doubly integrate an accelerometer and combine that with the gyro, but again you will need a good accelerometer as doubly integrating adds even more opportunity for accumulated error.

Re: Which sensors should be used throughout the robot?
 

That is a lot more positive then the last comment... I'll try the NavX... Do you think that triangulation is a possible option? Maybe with a fisheye camera on top of a bot or something like that...

Re: Which sensors should be used throughout the robot?
 

Far better than integrating an accelerometer would be a non-driven omni wheel to track position

Re: Which sensors should be used throughout the robot?
 

But if the wheel slips?

Re: Which sensors should be used throughout the robot?
 

As long as it isn't driven and is spring loaded down there should be no slip

Re: Which sensors should be used throughout the robot?
 

Anecdotally, the new NavX firmware improves upon that drift. ;)

I don't know that triangulation is the right term for this. I think you might be after something similar to Simultaneous Localization And Mapping (SLAM). SLAM is becoming more common in consumer and hobbyist robotics but it's still early days yet. I can tell you that it is something to keep digging into but I'm not sure it is the best area to invest resources into for an FRC team. It is definitely cool stuff though.

Re: Which sensors should be used throughout the robot?
 

The triangulation approach you mention has been done w/active landmarks like wireless beacons (requiring installation of multiple wifi transmitters), passive landmarks (well-known "checkerboard" patterns at well-known positions, w/identification/range calculated by a scanning camera), and by systems not dependent upon landmarks, including range-finding vision sensors (stereoscopic cameras, structured light sensors like Kinect [which are very short range, e.g. a living room], scanning LIDAR sensors, and scanning (or alternatively fisheye lens, as you say) video camers w/image recognition.

The optical approaches are non-trivial, rarely used in FIRST, and typically considered university-level. So a lot of folks tend to get a funny look on their face when these topics are discussed, and wonder why we're making things so complicated. :)

The algorthms for localization are becoming more and more available online, and there's free online courseware from MIT in probabilistic localization and related technologies.

More close to home, the Zebracorns have published as open source their 2015 vision software, which used OpenCV-based classifiers that were trained to recognize game pieces, pushing forward the State of the Art in vision processing in FIRST. If the same approach were used to recognize fixed-position field pieces, and then range to those objects was calculated and fused w/a map of the field (known ahead of time, in FIRST), you'd have what you were looking for. Again, not-trivial, but for those with interest, worth looking into in my opinion.

Looking ahead, a colleague of mine pointed out this fascinating new research from MIT that fuses object recognition with SLAM.

Re: Which sensors should be used throughout the robot?
 

I just thought of something (apologies if it has already been mentioned and I've missed it), could you not use a hall effect sensors to count wheel revolutions? It seems like a simpler solution than using a banner sensor.

Re: Which sensors should be used throughout the robot?
 

We did this in 2014 on our swerve modules. 6 neodymium magnets were mounted alternating north south on the under side of the 3.5" timming belt pulley. A Melexis US2881 Latching hall sensor was then used to give a non-contact solution. A counter was used set up for counting on the rising and falling edge. We used this to measure distance traveled. This year we used these boards.
https://www.pololu.com/product/2458
12 strips of KOP retroflective tape were mounted under the pulley. Although this is listed as an analog device, The c-rio did the chopping on a digital input set up as a counter.

Re: Which sensors should be used throughout the robot?
 

I noticed that we haven't mentioned using camera in this thread. What cameras have teams used, and how have they found them?

Re: Which sensors should be used throughout the robot?
 

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.

Re: Which sensors should be used throughout the robot?
 

Oh, geez, let's not do this - anchoring the housing/body of the encoder via securing its wires (and I've seen it). If you're using an encoder with 360 counts/rev for example, a wobble of one degree is one count. Although we're not going to use them ($$$) encoders are available with > 10K counts/rev. and imagine the error if it's poorly mounted. What you are learning (and I'm supposed to be teaching) should be applicable to an engineering job. Please mount encoders such that the threads on its body go through an appropriately-sized hole, and secure it with the lock washer and nut that come with the encoder. Have this in your CAD!

It's a good idea to mark the position of the encoder on its mount by drawing a line (sharpie, etc.) from the body of the encoder onto its bracket/panel, same thing for a pot. That way, if it comes loose (as did ours at Champs in 2010) you can put it back in about the right place, until you have time between matches to accurately remount it.

Re: Which sensors should be used throughout the robot?
 

It seemed to work well enough for 254 😜

Re: Which sensors should be used throughout the robot?
 

They have also since said that they have implemented more secure techniques to deal with the backlash.

Re: Which sensors should be used throughout the robot?
 

It's also going to work in your first engineering job if your goal is not to get a raise :)

Re: Which sensors should be used throughout the robot?
 

yes but it still won them a couple championships

Re: Which sensors should be used throughout the robot?
 

It probably worked for them for a number of reasons. 254 runs very well-built and smooth robots; correct me if I'm wrong, but I bet the runout on those shafts and the encoder bore itself was extremely low, for one. The average team might not have all the construction techniques that go into making a floating encoder setup work.

Re: Which sensors should be used throughout the robot?
 

Engineering is about creating a solution to solve some specified problem. If there's 15* of backlash to the encoder, than on my 4in wheel, that's 0.5in of linear error in position - the resolution of the encoder doesn't really matter. If you're driving an elaborate trajectory (e.g. some of the advanced game piece acquisition routines in 2011, 2013, and 2014), then the error will stack up, but if the average team is just driving forward 10ft to be in range of the high goal, it's probably sufficient, considering even the best drivers will have an order of magnitude larger positioning error in teleop.

When instrumenting arms, elevators, wheel pod steering, etc, the problem specifications are different.

I think it's well established that many of the techniques that are used in FIRST to create machines that run for a few tens or maybe hundreds of hours (and for only 15 seconds "unsupervised" at a time) aren't on parity with the techniques used in industry where machines have to run for tens of thousands of hours or more.

Re: Which sensors should be used throughout the robot?
 

Exactly. It's OK to have FRC 'good' design practices diverge from professional 'good' design practices. This is not the same thing as cutting corners-- it reflects the fundamental differences in the design environment. There's several examples of this in the 973 RAMP videos.

Re: Which sensors should be used throughout the robot?
 

It's all about understanding the situation. One needs to understand the system accuracy requirements, and then develop a solution that meets the requirement. For example, 10* of error on our 1.5" elevator pulley amounts to slightly over an 1/8" of error. This was plenty tolerable for us. 10* of error would not be acceptable however, for example, on a 5' long arm.

Even better than drawing a line is using a zeroing sensor. Hall effects are great for this, and you won't have to worry during sensor replacements.