Which sensors should be used throughout the robot?

[Gdeaver]

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.

[marshall]

Originally Posted by Gdeaver

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.

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.

[slibert]

Originally Posted by Gdeaver

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.

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

[Thad House]

Originally Posted by slibert

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

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.

[slibert]

Originally Posted by Thad House

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.

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.

[Thad House]

Originally Posted by slibert

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.

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.

[Tom Line]

Originally Posted by slibert

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.

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?

[AllenGregoryIV]

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.

[carpedav000]

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

[jajabinx124]

Originally Posted by carpedav000

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

^

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.

[thatprogrammer]

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.

[Gdeaver]

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.

[thatprogrammer]

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

[Ari423]

Originally Posted by slibert

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.

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.

[marshall]

Originally Posted by Ari423

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.

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