I have been looking at the creation of custom circuit boards. Despite not knowing how they could be used for FIRST, would custom circuit boards/ processors and electrical systems be ok for comp, and are there any specific requirements for having such systems?
As long as your coprocessor does NOT control motors and communicates over legal wired connection (i.e. UART), or through any of the network ports allowed by R704, and does not bypass any safety features of the DS, RIO, or FMS, you’re golden.
3 Likes
Just fill me in on what UART and r704 are.
It also needs to obey the development span rules, just like any other fabricated non COTS component. So fabricated after kickoff, pre-kickoff designs used published before kickoff.
1 Like
As a sample point, we ran 2x of these on our raspberry pi’s on our 2023 robot -
we ordered prototypes before the season started to verify functionality, released the designs before kickoff, then re-ordered the final design after kickoff and got them delivered before competition.
As far as legality, we went through inspection claiming them under the CUSTOM CIRCUIT rules.
3 Likes
UART is a method of communication with the RIO, which can be done through the MXP expansion port (I believe). There are many methods of wired communication with the RIO, like UART, SPI, I2C (which is broken and unusable), and perhaps the most reliable and easy to use being Ethernet. Ethernet allows simple communication over NetworkTables, versus having to deal with direct serial reads from various different ports.
R704 allows the following ports to be used by communication within the RIO-coprocessor-radio-DS ecosystem:
As well as ports 5800-5810, for “team use”.
1 Like
I2C is usable with a NAVX or other MXP expansion that adds on a separate I2C port. Only the built in roboRIO port causes the lockup issue
From what I’ve heard, teams have had the same or similar issues with the MXP I2C port, no matter how it’s connected.
The general recommendation is pretty much “only use I2C if you’re bridging it from a microprocessor to another communications method like UART or NT”
2 Likes
oh interesting, my personal experience with the MXP port has been pretty good, we ran 2 rev color sensors off the port for our ball indexers in 2022 and never had an issues there.
All the roboRIOs I’ve tested never locked up on the MXP I2C with one device and always locked up at random times with more than one device (tried various devices).
This has a couple of methods to communicate with the roboRIO OP could use (I2C replacement interface but that part may not be of interest to OP).
How did you handle overlapping I2C addresses?
2 Likes
we had a multiplexer (i believe this one https://www.tindie.com/products/closedcube/tca9548a-i2c-multiplexer-with-jst-ph-20mm-headers ) for the 2 or 3 sensors we had
3 Likes
Thanks for the information. Your successful experience may still be consistent with my test results that one device works and more than one do not work depending on how many devices the roboRIO thinks it’s seeing including the multiplexor. The MXP I2C failures I had were with two or more devices running at the same time and you apparently only had one at a time.
Thank for that, to my knowledge my team has avoided using that port due to issues I’ll check this out further
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.