[FRC Blog] myRIO Expansion Port - What's the Deal?

[Joe G.]

Today’s blog post, a long one, was written by Kate Pilotte, FRC Kit of Parts Manager, who’s facilitating the new control system efforts.

Hopefully, you’ve heard by now that all registered and paid FRC Teams are receiving new control system devices in their 2015 Kickoff Kits (this will include at least a roboRIO, dual-mode access point/bridge, a Power Distribution Panel, a Voltage Regulator Module, a Pneumatic Control Module, and four Talon SR motor controllers. The contents of the Kickoff Kits are typically confidential until Kickoff, but hopefully I can get away with saying that much!



Image credit: ni.com/frc

One of the features of the roboRIO is the MXP, or myRIO Expansion Port. It’s called out in the image above as the “Custom Electronics Port.” This port allows expansion of control system I/O based on the team’s specific needs. Specifically, the pinout is shown below. Did you notice that pins 11, 13, 15, 17, 18, 22, 26, 27, 29, and 31 can be used for DIO or PWM?



Image credit: ni.com/frc

This kind of feature is new to FRC. We recognize that if we didn’t say anything to the community about how it can be used – technically and legislatively – until Kickoff, it wouldn’t be much use as the build season just isn’t long enough to accommodate such an effort. For that reason, we’d like to let you know a few things ahead of time.

We had three driving priorities when drafting the rules and defining controller behavior (even though we’re not sure if the second priority is a real word…):

Safety – implementation of the MXP must mitigate risk of injury to team members and volunteers. Specifically, when a robot is disabled, nothing on the robot should move. When the robot receives a disable command, it will disable all PWM and Relay ports (which are the only ports by which actuators may be controlled). All other ports (SPI, Analog In, Digital I/O, RS-232, I2C, Ethernet, USB, and CAN) will remain enabled (although the “enable” token will not be sent over CAN, effectively disabling devices on the CAN). This includes the 10 pins (in yellow in the image above) that may be used for PWM via the MXP, even if the user has opted to not use them for PWM or actuators.
Inspect-ability – Volunteer Inspectors are able to quickly and sufficiently assess a robot’s compliance with the rules.
Parity – Teams cannot gain considerable advantage by employing highly expensive solutions.
Given those bullet points, we’ve drafted this preliminary set of MXP relevant definitions and rules.

Preliminary Defintions

ACTIVE DEVICE or CIRCUIT: Any device or circuit capable of dynamically controlling and/or converting a source of electrical energy by the application of external electrical stimulus.

MXP: myRIO Expansion Port (aka Custom Electronics Port)

PASSIVE DEVICE or CIRCUIT: Any device or circuit whose capability is limited to the conduction and/or static regulation of the electrical energy applied to it (e.g. wire, splices, connectors, printed wiring board, etc.).

Preliminary Rules

MXP1: If a motor or sevo is controlled via the MXP, it must be connected by one of the following methods:

directly to any PWM pins,
via a network of PASSIVE DEVICES and/or CIRCUITS used to extend the PWM pins, or
via one approved ACTIVE DEVICE.
In a nutshell? It means if you’re using the MXP for sensors, lights, or anything else that isn’t going to actually move or cause movement, the sky’s the limit and you can do whatever custom circuitry you like via the MXP. Remember though that upon disable, the 10 pins that double as PWM pins will also be disabled – so don’t use those pins for anything you’ll rely on while your robot’s disabled.

As soon as you decide to use those PWM pins to cause robot parts to move, you’ll have to use an approved device that FIRST has pre-vetted and listed in the manual as legal. This is to ensure that when those 10 pins are disabled, that disable signal that’s so important to us isn’t obscured or interrupted. It’s also an attempt to keep the inspection of that clean, simple, and objective.

In addition to the MXP specific rules, you can also expect rules comparable to those published in the past. Examples include, but aren’t limited to, the following points:

Robots must be controlled by and only by the roboRIO.
We don’t anticipate rules that prohibit co-processors (have at ‘em!), provided commands originate from the roboRIO to configure, enable, and specify all operating points for all power regulating devices. This includes devices legally wired to the CAN-bus.
Custom electronics must use appropriately sized wire.
Limits on motors, actuators, and power regulating devices for actuators will be defined.
Pneumatic solenoid valves and electric solenoid actuators may not be controlled via the MXP.
Custom electronics and circuits must not modify the power pathways between the battery, PDP, VRM, PCM, motor controllers, roboRIO, RSL, wireless bridge, main breaker, relays, or motors.
Only the robot’s wireless bridge may be used for wireless communication.
We anticipate approving a handful of devices, but we don’t have a specific limit (that will be driven by the number and quality of proposals received). So, what does a device have to do to be an approved Active Device? Here’s the requirements list:

The Active Device must be designed and produced such that
PWM pins must be a direct pass-through
the breakouts for PWM pins are visibly obvious
The Active Device must be previously approved by FIRST. To seek approval, please submit a comprehensive proposal to FIRST via frcparts@usfirst.org.
Approvals will be received up through November 14, 2014. FIRST will review and provide feedback and legality decision within one week of receipt. Legality is considered confidential until disclosed publicly by FIRST (which will be published by Kickoff, at the latest).
To be considered complete, proposals must include the following components
At least 5 device samples.
A description of how inventory and distribution will be managed such that devices will be commercially available to the FRC community.
Submitted by or in conjunction with a company that meets the 2014 definition of "VENDOR".
Preliminary documentation (e.g. user guide, specification sheet, etc.) and description of other relevant user resources (e.g. videos, websites, etc.)
Device pricing.
There’s no prohibition on sending descriptions, documentation, and other information ahead of the samples.

While it’s not required, we do recommend that any Active Device accommodate a pass-through for any unused pins so users can still access them. We don’t have spare systems to lend out to Active Device developers. If you need a system for development or testing, we recommend you team up with a Beta Team that has the bandwidth and is willing to work with you.

NI has provided a comprehensive roboRIO MXP Developer’s Guide (alpha version) with all the tools and guidelines you'll need to create your custom MXP board. The dev kit includes free access to NI's Multisim circuit SPICE software, Ultiboard, PCB layout software, templates, examples, and tutorials that will help you create any kind of board you want.

So, there you have the status of the MXP, as we know it today, for the 2015 FRC season. I will include an admittedly frustrating disclaimer that, if we learn anything via the ongoing beta testing efforts or feedback from the community, we do reserve the right to revise any language, rules, positions, etc. presented above.

If you have any questions about this (surely I didn’t address everything in on blog!), we’ve created a forum in the 2015 FRC Beta Test Forum specifically for MXP discussion - please post your thoughts and questions there. If you’re interested in developing an Active Device and have questions about the approval process or your specific device, please send your question to frcparts@usfirst.org.

Thank you!

MXP legality information for 2015. Also confirmation that the PCM will be included in the kickoff kit, and we will recieve a generous supply of Talon SR speed controllers which should help offset any Victor SP/Talon SRX availability concerns

[Joe G.]

Looks fairly reasonable. Passive devices can be connected in any way the teams see fit. Motors can be connected directly if done through passive electronics (nice to see that we can build our own breakout boards to optimize the interface to our own robot, as long as it consists of passive components only), while any active device requires FRC approval.

Given the relatively short timeframe for device approval, I wonder if CTR, Vex, and other historical electronics manufacturers will be soliciting active device concepts from the community?

[Christopher149]

Ooh, 4 Talon SRs.

[Jon Stratis]

I think this blog post answers another much asked question...

this will include at least a roboRIO, dual-mode access point/bridge, a Power Distribution Panel, a Voltage Regulator Module, a Pneumatic Control Module, and four Talon SR motor controllers

So everyone gets a PCM!

[Thad House]

I'm actually confused. So if the PWM ports are used to control a motor, It has to come through an active approved device? Or can a passive device be used to control a motor if it doesnt interfere with the signal at all?

Because according to this

via a network of PASSIVE DEVICES and/or CIRCUITS used to extend the PWM pins, or

it looks like you can directly connect, but further down it says if it moves it has to be an active approved device.

[Joe G.]

Originally Posted by Thad House

I'm actually confused. So if the PWM ports are used to control a motor, It has to come through an active approved device? Or can a passive device be used to control a motor if it doesnt interfere with the signal at all?

Because according to this

via a network of PASSIVE DEVICES and/or CIRCUITS used to extend the PWM pins, or

it looks like you can directly connect, but further down it says if it moves it has to be an active approved device.

As I understand it, as long as your connection device does not have any components that would qualify it as an ACTIVE DEVICE, you can custom make whatever you want with no approval. This would include anything that essentially serves as a "converter cable," routing pin outputs through conductors and presenting a more usable interface appropriate for your system. Only if you are using your board to do something that would qualify as an active device (for example, performing some kind of pre-processing of digital inputs on a board that also outputs PWM, swapping PWM outputs based on a co processor output, etc.) would you have to get your setup approved as an ACTIVE DEVICE.

I am curious as to what the limits of what could be considered a passive device would be. For example, would LED indicators to show PWM out status constitute an "active device?" Diodes are considered active electronic components due to their differing response to different polarity, although they would not be used as such in this application.

[BigJ]

The blog post (unofficially) presents the interpretation of ACTIVE DEVICE:

As soon as you decide to use those PWM pins to cause robot parts to move you’ll have to use an approved device that FIRST has pre-vetted and listed in the manual as legal.,

[Joe G.]

Originally Posted by BigJ

The blog post (unofficially) presents the interpretation of ACTIVE DEVICE:

Asked about this in the comments on the blog, Kate responded. Sounds like passive connection to PWM pins that drive motors, as I described, is legal.

Thanks for the question - and my apologies for the uncertainty...

The second sentence should read "As soon as you decide to use those PWM pins to cause robot parts to move (and you're not connecting via options A or B), you’ll have to use an approved device that FIRST has pre-vetted and listed in the manual as legal.” The text above will be revised.

The bare PCB with headers sounds like it meets the definition of Passive Device – so you should be fine with what you’re proposing.

[ehochstein]

In a nutshell? It means if you’re using the MXP for sensors, lights, or anything else that isn’t going to actually move or cause movement, the sky’s the limit and you can do whatever custom circuitry you like via the MXP.

This is extremely exciting, I can't wait to start prototyping circuits with my team.

[Michael Hill]

FYI, if anyone is wanting some tutorials on circuit design, I took this class this past year, and it was great (back then, we paid for these videos). The software used is called KiCAD, which is an absolutely free and open source eCAD suite of software.

https://www.youtube.com/user/context...view=0&sort=da

Alternatively, you can use the Altium Designer donation teams get every year, but I find it hard to rely on getting that donation every year.

[MrBasse]

Originally Posted by Jon Stratis

I think this blog post answers another much asked question...


So everyone gets a PCM!

You're very welcome, that happened because I preordered our board from Andymark last night... But now we'll have a spare!

[SoftwareBug2.0]

Maybe this is a stupid question but why do I need to use a SPICE simulation to figure out what the ports are doing? Why can't I just have a table with drive strengths and speeds and such?

And why do they assume that your circuit will be flat on the roborio and tell you clearances for stuff under where they think your PCB will be? Can't they just let you figure it out from the mechanical drawings?

I feel like a ton of effort has been put into this for no reason.

[Michael Hill]

Originally Posted by SoftwareBug2.0

Maybe this is a stupid question but why do I need to use a SPICE simulation to figure out what the ports are doing? Why can't I just have a table with drive strengths and speeds and such?

And why do they assume that your circuit will be flat on the roborio and tell you clearances for stuff under where they think your PCB will be? Can't they just let you figure it out from the mechanical drawings?

I feel like a ton of effort has been put into this for no reason.

Something that laying flat allows is stackability of modules, which is something I hope we can implement. It would be nice to stack things like co-processors on top of a sensor board (or vice versa).

[FrankJ]

So something like an Talon or an spike would be an active device. If you wanted to use a beefier relay than a spike, that would be an active device & would require submittable & approval.

[Aren Siekmeier]

Originally Posted by FrankJ

So something like an Talon or an spike would be an active device. If you wanted to use a beefier relay than a spike, that would be an active device & would require submittable & approval.

FIRST probably won't allow any custom components in the power pathway. Only official KOP relays and speed controllers.

Rather, an active device is one that modifies the signal sent to the Talon or Spike (or Jag or Vic). If the connection to a speed controller is not directly from the roboRIO pins or MXP headers, through passive devices (PCBs, bumpers, etc.), to the speed controller signal port, then the intermediate device has to be approved in advance.