TechHOUNDS roboRIO Expansion Board

[Swiezy868]

Hello Everyone! Team 868 is proud to announce the release of our roboRIO MXP Expansion Board.

Our expansion board is designed around an Arduino chipset featuring the Atmega32u4. It not only breaks out 10 versatile Arduino pins, but also allows access to the additional 10 PWM ports on the MXP port. Communication between the Arduino and the roboRIO is achieved through UART, SPI, or I2C. The communication mode is selected via on board DIP switches. This board also features a prototyping area, a direct connection for a GYRO (this includes the power, ground, and signal connection as well as mounting holes), a 5V power connection to provide extra power for peripherals, fused power from the roboRIO, and a mini-USB port for programming the on board Arduino. This board was designed to be extremely versatile and is great for controlling LEDs, breaking out extra PWM ports, and easily connecting a GYRO.

The schematic, board design, and parts list for the expansion board are available here on the TechHOUNDS website. The board has also been uploaded to OSHPark and can be purchased through OSHPark here. The BOM has been uploaded to Digikey and can be directly purchased here. This board does contain a fair amount of SMT components, so be aware of this before attempting to build the board. Also be aware that this design is our second revision and has not yet been tested; however, its close predecessor has been extensively tested.

For those who are uncomfortable soldering SMT parts, I've been designing a through hole version of the above board with similar specs and features, and if there is any interest I will try to release that board with its schematic and parts list in the near future.

I hope that teams are able to benefit from this expansion board, and I wish everyone the best of luck in the 2015 season. If you have any questions about the board feel free to send me a message.

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