Assistance Requested: Rev Color Sensors + Pi Pico + NavX MXP

[czb]

Our team has been having a go at getting a Rev color sensor up and running despite the I2C issues. We are able to get it working intermittently, but it stops working after shortly after installation. We’ve been using @Thad_House Pi Pico solution, but since we use a NavX MXP, we’ve been plugging the Pico into that instead of the MXP port itself. (Thank you for making this Thad, we’re very grateful.)

The TLDR is that it seems to work well immediately after we connect a board to the color sensors, but becomes intermittent in odd ways shortly thereafter. We’d love to hear from anyone who has this stack working because, while my understanding is that the NavX breaks out the MXP port, I am not sure if the addition of the NavX changes anything or not. My theory is that the problem is either something electrical or perhaps there is something obvious we’re missing, but frankly, no one on our team is an electrical expert and I’d love any advice anyone can offer. A detailed explanation of what we’ve attempted is below.

–

As stated we’re running Thad House’s Pi Pico solution with two color sensors. We would be fine running just a single sensor but since the solution accepts two, we used two. We’ve tried it with three separate boards. The first board worked for a couple minutes and then the color sensor lights turned off and we never received a signal again. We believe the board somehow shorted, so we wired another board, and this one worked for a bit longer, but after a few minutes one sensor stopped returning values. At some point during debugging that, the other sensor also stopped returning values, so we may have shorted that board as well. We had to focus on other priorities for our event so we paused at that point.

Today we made a third board, being as careful as we could to avoid any shorts. We installed header pins on the board and 3D printed a nice case. (If anyone needs a 3d model for a Pico case let me know, I don’t have the file handy but I’d be happy to get it from our design team and share it. I imagine other public options may already exist.) We plugged into the board and once again, our color sensors worked. We then hot-glued the pins in place on the Pico. During our first test post-gluing, only one sensor worked. After stripping the hot glue off, swapping which sensor was plugged into which pins on the Pico changed which sensor worked, indicating an issue with the board (or possibly the header pins.) Connectivity checks with a voltmeter also support this as all of our wires pass the check.

At some point, after connectivity checking all our wires and plugging them back in, we noticed that the one sensor that had been working, was now working intermittently. It will sometimes read just fine for many seconds/minutes and sometimes it will simply not read at all. Additionally, sometimes even the non-working sensor will send a single value (we observe this as SmartDashboard will have changed to just showing 0 for all colors for that sensor, to showing a value.) Sometimes BOTH sensors will read values for a period of time, but will update values roughly once per second, instead of continuously.

All of this leads me to believe we have one or more loose/slightly broken wires, but over the course of multiple connectivity checks, we have not been able to find one. It’s also possible that the header soldered to the Pico is bad. Unfortunately we did not test this yet so if you’re reading this and think “it has to be that”, let me know - we can rip the board out of the case tomorrow and try checking connectivity from the header to the underside of the board. But I am wondering if there is something else that might be causing our problems.

Photos of our wiring setup will follow in the next post.

Other things we have tried:

• Switching the NavX MXP dip switch for TTL UART between off and on
• Checking voltage drop from the NavX power pin that goes to the Pico, vs the ground - it’s 5v. (We did run it at 3.3v at one point just to see what would happen - ironically this did make both sensors work for a short period of time, before the problem re-occurred.)
• Tried re-instantiating the PicoColorSensor class in code if all colors read 0 based on this thread, but that throws “resource already allocated” errors, which makes sense as the Readme says you can only have one instance of the class.
• In our code, we do wrap the PicoColorSensor class with our own that has a couple additional methods, and we tried running the base class instead. No change. We don’t think it’s a code error based on the symptoms but our code is public here: https://github.com/RoboRavens/RapidReact the relevant code is on lines 212-230 of Robot.java as of this posting, plus perhaps the RavenPicoColorSensor class which is in the ravenhardware folder.

Things we have NOT tried:

• Connectivity checks on the headers of the Pico, as described.
• Pulling the NavX out entirely and plugging the Pico directly into the MXP port. We have a NavX micro on hand but have never tried using it. This may be a possible solution for us.
• Running a single sensor on the NavX’s I2C port (I wasn’t sure whether or not this could possibly trigger the I2C crash issue - based on the WPI known issues page, it seems like it would be safe as it’s a breakout of the MXP I2C, but if someone knows for sure I’d also appreciate hearing from you.)

Things we’d love to hear from the community on:

• Is anyone running this same stack and/or is there any reason adding a NavX between the Pico and the MXP port would cause complications
• Is there anything relating to configuration we’re missing entirely
• Any ideas on what is going wrong or how to continue debugging
• Any suggestions for a change in stack that would simplify things/increase the reliability of the sensors. Again, we’d be OK with dropping down to a single color sensor.
• For anyone successfully using a Pico: any wiring/casing/mounting tricks to prevent shorts and ensure wire connectivity?
• Anything else worth mentioning. Again, custom circuits are not our team’s strong suit so we’ll accept any advice.

Overall, while our robot can’t do everything, we’ve been happy with how we’ve accomplished the goals we set for ourselves and getting this working is our last technical goal for the season (our season ends next weekend at Michigan State Champs regardless of whether we qualify for worlds.) If anyone can help us out we would be very grateful! Thank you in advance.

[czb]

A picture of our Pico wiring. This is actually from our attempt a couple weeks ago, but this is the same setup on our newer (slightly neater) board. The yellow cable in the back right is the signal out to the NavX (plugged into the NavX’s TTL UART Rx pin) and the other yellow and purple wires are the SDA and SCL wires going to the sensors. The black and red cables are ground/power. Since the lights on the color sensors turn on, and the Pico is receiving 5 volts from the NavX, we believe those are fine. The Pico is outputting 2.9-3 volts to the color sensors, checked by voltmeter.

[ngreen]

I don’t have the navx in the mix, but it seems that is least likely the issue, from my recollection of how it connects.

I did have the first pico I wired were the second color sensor didn’t work (it still had the light, but no signal when running code). I suspected that I shorted a pin. I also had SDA and SCL swapped initially, but I think it was not that for the persistent issue.

But later I didn’t seem to have any intermittent issues on our second pico. I don’t have a good reason that it should not be working in mind.

[bovlb]

That’s a great write up! It sounds like you’ve tried all the obvious things.

I know you said you checked the conductivity of the connectors, but it’s possible there’s a problem there that you’re not detecting with the multimeter, say because the probe is longer than the GPIO header pins. I’m not sure exactly which type of connector you’re using there, but with some of them it is easy to get a bad connection if you don’t push the crimped connector all the way in. For example, is that bare metal visible on one of your ground connectors?

[Ambroses]

We are running this exact stack with only one color sensor and we’ve had no issues (yet). We’ve not done anything special with Thad House’s images - just implemented with one sensor and it is working fine.
Our intentions is to add the second color sensor to reduce the occasional “missed read” we seem to get every now and again.

[Knufire]

We had the exact same issues with this stack. We were never able to really figure out a root cause for these issues, and swapped to using a Teensy 4.0 with Spectrum’s code.

GitHub - Spectrum3847/Spectrum-Photon at PlatformIO-REVColorSensor

Wiring was a bit simpler for this, as the Teensy connects to the Rio over USB, which provides both power and a serial interface. The format of the string sent back to the Rio over serial is the same as Thad’s Pi Pico setup, so you can still use the same code on the Rio side, just change the port number to use the USB serial port instead of the MXP port. Port numbers should be in the SerialPort.Port enum.

The onboard 3.3V regulator on the Teensy 4.0 can also handle powering 1 (but not 2) color sensors.

[czb]

Thank you all for the responses. Perhaps we are continuing to short the boards somehow. The Picos are shockingly inexpensive and, while this is speculation, a hostile environment like an FRC robot is probably outside of what they were designed for.

@bovlb yes, there is some exposed wire there. This is an older photo and I’m not sure if our current wire has that same issue or not. I do believe if the ground connection were broken then the sensors would not receive power but again I will re-iterate that this is not my area of expertise so perhaps I am wrong about that. I will double-check that, and try your suggestion regarding the header pins.

@Knufire thanks for the alternative suggestion. It also feels a bit better to know we’re not the only ones. It looks like Micro Center carries the Teensys but our local store is out of stock so it’s probably too late for us to pursue this this season. Perhaps we’ll try it out in the offseason if we can’t get the Pico working.

I think I’ll run to Micro Center today and grab a couple more Picos (if the downside is that they’re cheap, the upside is that they’re replaceable) and maybe some additional header pins, and give it one more go. It’s encouraging to hear that two of you have gotten it to work, especially if you initially had shorting issues. Maybe we’ll try it with one sensor to start in case that somehow has something to do with it. At the very least, fewer wires means a smaller chance of putting a wire in the wrong spot and shorting something.

Not positive I’ll get a chance to work on this tonight as we have a couple other priorities, but if I do, I’ll make sure to post an update. Thanks everyone!

[Knufire]

@czb

It looks like Micro Center carries the Teensys but our local store is out of stock

They should be available on Amazon, I see Prime Overnight shipping as an option for me.

[Peter_Johnson]

I didn’t realize someone had done a Teensy version–might be worth adding that to the WPILib docs page list of alternatives.

[czb]

We’re ordered and will try the Teensy, but I am a little confused on the implementation details, even after reading all the documentation. Would you be willing to share your broad steps? I tried checking your team’s 2022 repo but didn’t find anything relevant yet.

I have a number of questions which I’ll list here, but simply seeing the broad steps might answer them more effectively than answering them individually - IF you are willing. I have no prior experience using co-processors but am willing to read documentation.

Here is my interpretation and some of my questions:

• We start by installing Teensyduino. Then we download the entire folder you linked from Spectrum’s repo, plus the two libraries Spectrum links in their guide doc (FastLED Library and cmdMessenger.)
• We open Spectrum-Photon in Teensyduino, per Spectrum’s guide. I am not sure exactly what this means but I’m hoping it becomes self-evident when we do it.
• The guide goes on to reference Photon but we won’t be driving LEDs with this, at least not this year. Do we ignore this and the rest of the steps from Spectrum’s guide?
• Spectrum’s guide links to this CD post. Do we install this on the Teensy in addition to Spectrum’s code, instead of Spectrum’s code, or not at all (if it’s already integrated?)
• Once the Teensy code is installed, we would change the port in our Java code from the MXP to the USB port, but I am unsure on this because in the C++ version of Thad’s code I see where the SerialPort.Port enum is being used, but in the Java version it’s using the SerialPortJNI class instead.

I am concerned this is a bit more complicated than we have the resources to handle in just a couple of days, but you make it sound easy so I’m hoping I’m missing the obvious step here. We really appreciate the help.

EDIT: One additional question - do we need the ethernet adapter board for the Teensy if we’re not driving LEDs? It seems to me like we would not but I am concerned that one of the libraries could crash if it does not exist.

[Joe_Ross]

@czb

Is anyone running this same stack and/or is there any reason adding a NavX between the Pico and the MXP port would cause complications

From the NavX website I/O Expansion | navX-MXP

Note that this TTL UART connector can be used to communicate between the RoboRIO and the navX2-MXP’s onboard processor (in fact, this is the default). navX2-MXP will respond to the UART TX signal from the RoboRIO if and only if the UART Enable dip switch is set to the “ON” position. Thus, the UART Enable dip switch should be set to the “OFF” position if you wish to communicate with an external device via the TTL UART connector.

[czb]

Thanks Joe - we did try this, it was actually one of your posts in a different thread that taught us this switch even existed! Unfortunately, it did not solve the problem. We’ve used NavXs for years and never knew about these dip switches before; it’s always amazing how much there always is left to learn.

[Knufire]

Yup! I think part of the confusion is that Spectrum is using a Teensy to drive LEDs as well, and just recently added in support for running the color sensor through it, so I’m not sure all that documentation is up to date.

Step 1: Clone the Spectrum-Photon repo to your computer. Ensure that you’re on the PlatformIO-RevColorSensor branch (the link I gave earlier should link directly to that branch).

Step 2: They are currently using PlatformIO to build and deploy code to the Teensy. This seems to be a third party tool distributed as a VSCode plugin. I installed this plugin straight to the WPILib-installed version of VSCode on my computer. This may require you to install Python as well if you don’t already have it installed.

Step 3: Open the Spectrum-Photon folder in VSCode. The PlatformIO home page should automatically open up, and you can use it to open the Spectrum-Photon project within the extension. Once properly opened, PlatformIO has built-in build and upload commands that should upload to the Teensy. Remember, Ctrl+Shift+P opens up the Command Palette in VSCode, and the relevant commands here should be “PlatformIO: Home”, “PlatformIO: Build”, and “PlatformIO: Upload”.

This should get the right code on the Teensy.

Now on the RIO side, if you look at the SerialPort.Port enum, you’ll see that each entry in the enum has specific values assigned.

These, as far as I understand, are the values being passed into SerialPortJNI.serialInitializePort, which Thad’s code is using directly. We simply changed the hardcoded 1 (for MXP) to a 2 (for USB port 1) to connect to the Teensy over USB serial. I’m unsure if it will always come up on kUSB1 or whether you’ll need to try kUSB2 (setting the value to 3) depending on which Rio port you plug the Teensy into.

[czb]

Thank you - what a fantastic response! We will try this when our Teensy arrives.

One outstanding question - do you know if we need the Ethernet adapter for the Teensy to run JUST the color sensing code, without the LEDs? We may buy one just in case but I’m not sure just yet.

For anyone following along, I’m talking about this: PJRC Store

[khillans]

Our team was running two color sensors off the top which was causing the i2c lock up but once we switched to only running one off the navx we we’re fine i belive the i2c lock up dosent occur our system is a bit more inefficient as we have to run a motor continuously now but it’s better than dying on the field please post if using a teensy works as we were looking into using picos since we though it would be plug and play

[czb]

Thanks for the reply - I will definitely follow up based on our results with the Teensy. I am also still planning on giving the Pico boards another shot (will try the Teensy even if the Pico boards work.) Of course, since Rahul’s team is already using the Teensy and it’s working for them, I would say it’s clear that it can work.

[Knufire]

You shouldn’t need the ethernet adapter just for color sensing, we simply have it plugged into the Rio USB port with a micro USB to USB cable. Make sure that the cable you’re using actually has the data pins connected; we found that a lot of the micro USB to USB cables lying around our shop were power only.

Our Teensy came with this on a printout as a handy guide. We have the REV Color sensor plugged into the GND, 3.3V, SCL0 (19) and SDA0 (18) pins.

PlatformIO also has a built-in serial monitor that you can launch using the VSCode Command Palette. This is really handy; since the Teensy is already setup to use serial-over-USB, you can plug the color sensor into the Teensy and see the values streamed to your computer to ensure that it’s all wired correctly before transferring to the robot.

[czb]

Last night we implemented the Teensy solution, and it’s working! Since we tried this first and it worked, I unfortunately don’t have a perfect follow-up answer for anyone who might look at this thread in the future and wants to use the Pico. We were able to diagnose that one of our color sensors itself was broken, and for the other, the cable that plugs into it had an intermittent signal wire (one of the Rev cables that it comes with.)

This leads me to speculate that had we continued with the Pico we may have been able to get that to work as well had we swapped the same hardware out, but we did not investigate it further once it was working. We prefer the Teensy now anyway as the USB connection to the rio seems considerably more robust than individual pins to the NavX (or MXP). Our rio is not in the most accessible location so this was nice for us but YMMV.

I appreciate all the replies. Thanks, everybody!

[bbonner]

FWIW, we are also running the standard stack with a single sensor to the Pi. The only issues we had were needing to flip the UART DIP switch, and a mis-downloaded image on the Pi Pico, which was human error. Once we got the code properly loaded it’s worked OK since.