TechHOUNDS roboRIO Expansion Board

[otherguy]

Thanks for sharing the PCB and parts list! This looks like a great little board for teams.

Looks like you put some thought into protection as well, 3 resettable fuses on board. I haven't gone through the schematic closely yet to look at everything closely, so sorry if its obvious, but would you be able to elaborate on what gyro this is designed to work with and how how it is interfaced to the roborio (serial, through arduino?)?

Has the board been sent to FIRST for approval for use in this coming season per: http://www.usfirst.org/roboticsprogr...whats-the-deal

If I understand the proposed rules for the MXP correctly I think you're fine to have the active components on the board (if its not one of the 'approved' boards) as long as you don't also control output devices (like motor controllers). Correct me if I've misunderstood what they've outlined.

[Swiezy868]

Originally Posted by otherguy

Looks like you put some thought into protection as well, 3 resettable fuses on board. I haven't gone through the schematic closely yet to look at everything closely, so sorry if its obvious, but would you be able to elaborate on what gyro this is designed to work with and how how it is interfaced to the roborio (serial, through arduino?)?

The board is designed to work with any 3-wire analog gyro which has a pinout of GND-5V-SIG, but it is optimized to work with the gyro provided in last year's KOP because the 2 bolt holes on the board are designed to match the mounting holes on that gyro.

As far as communication is concerned, the board is able to interface with the roboRIO using 3 different protocols (UART, SPI, I2C). Each method of communication can be enabled/disabled using on board DIP switches. For example the UART bus has 2 wires between the roboRIO and the atmega32u4 (TX, RX); therefore, there is a DIP switch in line with each of those wires to enable/disable UART communication. Overall there are 8 DIP switches to control the 8 communication lines (UART-TX, UART-RX, SPI-MISO, SPI-MOSI, SPI-SCK, SPI-CS, I2C-SDA, I2C-SCL) that go between the roboRIO and atmega32u4 to support the 3 different methods of communication. If you look at the bottom of the schematic this should make a little more sense.

Originally Posted by otherguy

If I understand the proposed rules for the MXP correctly I think you're fine to have the active components on the board (if its not one of the 'approved' boards) as long as you don't also control output devices (like motor controllers). Correct me if I've misunderstood what they've outlined.

The Arduino outputs provided on the board were implemented more for controlling LEDs and other nonessential portions of the robot. As long as the Arduino outputs aren't used to cause/control motion, I believe the board should be legal even without approval from FIRST.

[RyanShoff]

The way I read the rules was this: if you can control something (ie break out pwm signals) and have active components, you needed to send it to FIRST a while ago.

I assume the reason is this: there could be a trace from the arduino to the pwm that could cause a motor is run outside of the safety systems.

I also read the rules to say that if you don't break out the pwm signals, you can do whatever you want. Lights, sensors, and coprocessors would all be allowed.

Not populating the pwm headers would be good enough in my eyes. I'm not sure every inspector would agree.

[AustinSchuh]

Originally Posted by RyanShoff

Not populating the pwm headers would be good enough in my eyes. I'm not sure every inspector would agree.

The PWM signals are shared with digital inputs, so not connecting to them would be a bit stringent. As long as you don't take them off-board to an actuator, you are fine.

[Joe Ross]

Originally Posted by Swiezy868

The Arduino outputs provided on the board were implemented more for controlling LEDs and other nonessential portions of the robot. As long as the Arduino outputs aren't used to cause/control motion, I believe the board should be legal even without approval from FIRST.

Like James and Ryan, this does not match my reading of the rule. If you connect an actuator to the MXP board, FIRST needs to approve the design to make sure you didn't connect the actuator to an active path.

[aryker]

Originally Posted by Joe Ross

Like James and Ryan, this does not match my reading of the rule. If you connect an actuator to the MXP board, FIRST needs to approve the design to make sure you didn't connect the actuator to an active path.

That was how I read it as well.

[SquishyIce]

Just for a bit of clarity, is it OK if we were to use this board for LEDs and sensors ONLY? What I'm gathering is that the board has to be approved by FIRST if anything like motors, solenoids, and whatnot are controlled through the board, but I'm not sure if my understanding of the situation is adequate.

[Greg Needel]

I will chime in here as I have first hand knowledge of what FIRST means with this rule. This year, we (REV Robotics) developed 3 different MXP boards.

1) the protoboard
2) the more board
3) the RIOduino

We approached FIRST with each one of these boards and sent them through the approval process. We were told that the first 2 boards (which are both breakouts) did not need to be approved because they considered passive. The third (RIOduino) would need to be approved as it is an active device. Just because the intent of it is to be connected to sensors, arduino shields, and LED's because it has the potential to drive motors they wanted to look at it.

The outcome of of that approval process is up to FIRST to release, and while we are hopeful in the results, until they say something about legality we won't know.

We have produced RIOduino's and they will be shipping next week to people who are interested in them, hopefully with a full FIRST endorsement.


You can check out the info for the RIOduino on our site here http://www.revrobotics.com/product/rioduino/



*on a personal note, I like your take on the board. We discussed many of the additions that you implemented, but decided against them because we wanted to maintain the standard arduino footprint. We see some major advantages of tapping into the arduino platform for FRC, specifically the many shield (LCD, sensors, LED drivers) and code examples which are out there.