RoboRIO MXP Breakout

[Jaci]

As something to keep me busy during the offseason, I've looked into possibly making some circuits for the RoboRIO's MXP Breakout Port.

Unfortunately, upon reading this article, it seems that PWM devices MUST be a direct passthrough. I suspect this will bear some issues regarding sensor based response (i.e. a Trim) for the PWM port.

While I can see why FIRST is doing this (in the interest of safety), I was wondering if there's a way to interface with the PWM on the breakout without passing it directly to a motor controller, i.e. putting circuitry inbetween. While there is an approval process, there is nothing in the article that I can see stating it as being coherent enough to include this type of control.

Additionally, approval process states that the report must be in conjunction with a company as a vendor, and all information disclosed at kickoff. I see the MXP board as an extremely powerful tool, but for some teams they may want to keep this interface board private, or just not have to deal with manufacturing for other teams (i.e. build for their own usage). I hope to see FRC make this interface legal for single-team use, as Electrical Engineering in FRC hasn't really delved much further than 'plug the thing in the thing'.

[Michael Hill]

You're correct that it's a safety concern. FIRST needs to be guaranteed that if the refs (or your team) disable your robot, it will be disabled, so if the PWM gets generated by a breakout board (or monkeyed with), they can't be guaranteed the motor controllers won't get a signal. What you can do, however, is make a breakout board that talks to something like a beaglebone or some other platform that handles sensor input and does control loops and interface that with the MXP. I know 971 has had success with doing that (albeit with Ethernet and UDP broadcasting). You could also do some fancy off-board image processing as well. If you just need to tell your robot to turn right or left, then you could just transmit that information digitally through the MXP port.

[cgmv123]

Under the 2015 rules, as long as you're not trying to control a motor or servo, there are no restrictions* on circuitry connected to the MXP. It's just another CUSTOM CIRCUIT.

*Please use common sense when interpreting the phrase "no restrictions".

[Greg Needel]

Originally Posted by Jaci

As something to keep me busy during the offseason, I've looked into possibly making some circuits for the RoboRIO's MXP Breakout Port.

Unfortunately, upon reading this article, it seems that PWM devices MUST be a direct passthrough. I suspect this will bear some issues regarding sensor based response (i.e. a Trim) for the PWM port.

While I can see why FIRST is doing this (in the interest of safety), I was wondering if there's a way to interface with the PWM on the breakout without passing it directly to a motor controller, i.e. putting circuitry inbetween. While there is an approval process, there is nothing in the article that I can see stating it as being coherent enough to include this type of control.

Additionally, approval process states that the report must be in conjunction with a company as a vendor, and all information disclosed at kickoff. I see the MXP board as an extremely powerful tool, but for some teams they may want to keep this interface board private, or just not have to deal with manufacturing for other teams (i.e. build for their own usage). I hope to see FRC make this interface legal for single-team use, as Electrical Engineering in FRC hasn't really delved much further than 'plug the thing in the thing'.

I don't want to directly speak for FIRST here, but I will share our experience putting a few boards last year through the process (and maybe some new ones for this year ). The main concern that FIRST has is when a robot is disabled, nothing moves. Inside the roboRIO this is taken care of and if all PWM lines are just passed through they don't have to worry about any problems. If there are any active or passive components on pwm lines between a motor controller and the RIO, there is a chance that the robot will keep moving when disabled. Things like pots and capacitors can cause motor controllers to read false signals and even a twitch of a motor can be very dangerous. Some of the motor controllers on the market even have this twitch problem with nothing more than a bad Y-cable in the mix, so you can see why FIRST is cautious.

All that being said, if you wanted to do a trim Pot on a motor controllers, why not just plug it into an analog port and modify the pwm signal in code? I figure it would have the same results with probably a more predictable outcome.

[Jaci]

Originally Posted by Greg Needel

I don't want to directly speak for FIRST here, but I will share our experience putting a few boards last year through the process (and maybe some new ones for this year ). The main concern that FIRST has is when a robot is disabled, nothing moves. Inside the roboRIO this is taken care of and if all PWM lines are just passed through they don't have to worry about any problems. If there are any active or passive components on pwm lines between a motor controller and the RIO, there is a chance that the robot will keep moving when disabled. Things like pots and capacitors can cause motor controllers to read false signals and even a twitch of a motor can be very dangerous. Some of the motor controllers on the market even have this twitch problem with nothing more than a bad Y-cable in the mix, so you can see why FIRST is cautious.

All that being said, if you wanted to do a trim Pot on a motor controllers, why not just plug it into an analog port and modify the pwm signal in code? I figure it would have the same results with probably a more predictable outcome.

I can see FIRST's concern, but if a schematic for something as simple as a Trim were to be sent in and put through approval (i.e. a direct passthrough, but will be blocked when an external signal is active, therefore no auxiliary signal generated for the PWM), I would hope it would be at least possible

I'm not saying this is something I'd do, I'd just see it as a good theory to use in upcoming boards. I guess it's more a principal than anything, although I have no intention of running PWM on the board I'll be making, 10 ports is more than enough

[philso]

Originally Posted by Jaci

...

Unfortunately, upon reading this article, it seems that PWM devices MUST be a direct passthrough. I suspect this will bear some issues regarding sensor based response (i.e. a Trim) for the PWM port.

While I can see why FIRST is doing this (in the interest of safety), I was wondering if there's a way to interface with the PWM on the breakout without passing it directly to a motor controller, i.e. putting circuitry inbetween. While there is an approval process, there is nothing in the article that I can see stating it as being coherent enough to include this type of control.

Additionally, approval process states that the report must be in conjunction with a company as a vendor, and all information disclosed at kickoff. I see the MXP board as an extremely powerful tool, but for some teams they may want to keep this interface board private, or just not have to deal with manufacturing for other teams (i.e. build for their own usage). I hope to see FRC make this interface legal for single-team use, as Electrical Engineering in FRC hasn't really delved much further than 'plug the thing in the thing'.

Why do you feel that directly interfacing with the PWM signals is necessary? It is much, much easier (and safer) to manipulate the PWM signals in software as Greg suggests. Much more can be done in software than can be done in hardware. Some teams use co-processors, as Micheal indicates. It would be difficult to find a co-processor with enough horsepower and speed to put in the path of the PWM signals that would not compromise the PWM signals in some way. There are other ways you can apply your creativity without endangering yourself and others.

By directly manipulating the PWM signals, you will be adding complexity to a safety critical system. That complexity can lead to an unsafe condition if not tested very, very thoroughly. This is likely why FIRST wants to see a company as a vendor. It is also likely that they will want to review the company's policies regarding making and documenting design changes. Otherwise a system that was deemed to be safe can become unsafe.

[Jaci]

Originally Posted by philso

Why do you feel that directly interfacing with the PWM signals is necessary? It is much, much easier (and safer) to manipulate the PWM signals in software as Greg suggests. Much more can be done in software than can be done in hardware. Some teams use co-processors, as Micheal indicates. It would be difficult to find a co-processor with enough horsepower and speed to put in the path of the PWM signals that would not compromise the PWM signals in some way. There are other ways you can apply your creativity without endangering yourself and others.

By directly manipulating the PWM signals, you will be adding complexity to a safety critical system. That complexity can lead to an unsafe condition if not tested very, very thoroughly. This is likely why FIRST wants to see a company as a vendor. It is also likely that they will want to review the company's policies regarding making and documenting design changes. Otherwise a system that was deemed to be safe can become unsafe.

This is all theoretical -- I have no intention of actually doing so. It would just be nice to get an idea of how this could work and what potential it could unlock. The MXP is often referred to as a custom electronics board, and I wanted to see just how custom you could get. I'm aware it's a safety concern, but I'm trying to find out what is theoretically possible, and on that line, what is considered dangerous and unsafe.

[FrankJ]

Originally Posted by Jaci

I can see FIRST's concern, but if a schematic for something as simple as a Trim were to be sent in and put through approval (i.e. a direct passthrough, but will be blocked when an external signal is active, therefore no auxiliary signal generated for the PWM), I would hope it would be at least possible

That is not exactly simple. You are intercepting the PWM signal and sending out a new one with the trim added. I don't see this ever getting approved. (disclaimer: I have nothing to do with the approval process.)

[philso]

Originally Posted by FrankJ

That is not exactly simple. You are intercepting the PWM signal and sending out a new one with the trim added. I don't see this ever getting approved. (disclaimer: I have nothing to do with the approval process.)

I think you would unlock much more potential for controlling your motors by investigating using different motor control software algorithms and incorporating sensor inputs in innovative ways. You would not need approval from FIRST to do any of this.

Intercepting the PWM signals and then modifying the pulse widths is not a trivial thing to do. It will be even more difficult to do it well enough that you would consider submitting it for approval. As I stated earlier, it would take a lot of real-time processing horsepower to do this.

My day job is designing the hardware that goes into large (100 ~ 1200 hp), 3-phase motor controllers for industrial applications. I have never seen any of my employers, any of our competitors or any academic papers intercept the PWM signals and manipulate them in hardware. What is done by everyone in the industry is to have many software modes (Volts/Hertz, Vector Control, ...) for generating the PWM signals. Much of the research in this field is in improving the (software) control algorithms used to generate the PWM signals. It is often the quality of the software that gives one motor controller an advantage over another.

[AustinSchuh]

Originally Posted by Jaci

Additionally, approval process states that the report must be in conjunction with a company as a vendor, and all information disclosed at kickoff. I see the MXP board as an extremely powerful tool, but for some teams they may want to keep this interface board private, or just not have to deal with manufacturing for other teams (i.e. build for their own usage). I hope to see FRC make this interface legal for single-team use, as Electrical Engineering in FRC hasn't really delved much further than 'plug the thing in the thing'.

As someone who made a serious MXP board last year, I can give you a bit of info on how things went for us. We made the decision to passively pass the 10 PWM signals from PWM ports 0-9 through a board with active circuitry on it for power regulation and a gyro. This held the board more securely and gave us nice latching connectors for the PWM ports. We even had a very clear 1/4" wide section of board where there were no traces. We talked with FIRST, sent them our schematic, and were unable to get the board approved for use by our team. They agreed with us that there should be no issue given the schematic but were unable to make exceptions. And this was for a board with nothing active in the control path. We were able to make the board pass inspection by physically separating the PWM part of the board from the rest of the board.

Electrical engineering in FIRST is pretty limiting mostly due to the safety involved. You can do some pretty cool stuff with sensors though. Back in the cRIO days, we ran a BeagleBone Black with a custom cape to interface with sensors and run our control logic. We had boost-buck voltage regulators to keep the board up through the whole match. We also had a micro-controller to count encoder pulses and interface with our gyro on the custom cape.

Sorry to rain on your parade.

[FrankJ]

One element of the 2015 approval was that it had to be produced by a "Vendor". Presumably as a COTs device with stock available for purchase by other teams. So a board made by a team would not meet the approval criteria unless they had a vendor make in sufficient quantities so that it was available to any team that wanted it. Rephrase from Frank's blog: "myRIO Expansion Port - What's the Deal?" 9/23/14

[GeeTwo]

Originally Posted by FrankJ

One element of the 2015 approval was that it had to be produced by a "Vendor". Presumably as a COTs device with stock available for purchase by other teams. So a board made by a team would not meet the approval criteria unless they had a vendor make in sufficient quantities so that it was available to any team that wanted it. Rephrase from Frank's blog: "myRIO Expansion Port - What's the Deal?" 9/23/14

And even this plan didn't work with the NavMXP. Given the amount of navigation that was required to score autonomous points, we would have purchased a couple last year had there been any in stock for more than a few milliseconds. (OK, I slightly exaggerated on the time window.)

[Greg Needel]

Originally Posted by FrankJ

One element of the 2015 approval was that it had to be produced by a "Vendor". Presumably as a COTs device with stock available for purchase by other teams. So a board made by a team would not meet the approval criteria unless they had a vendor make in sufficient quantities so that it was available to any team that wanted it. Rephrase from Frank's blog: "myRIO Expansion Port - What's the Deal?" 9/23/14

IMO if a team wanted to make their own active MXP board to use if they just posted the gerber files, BOM, and schematic online I believe that would be sufficient. Teams (even with no experience) can easily use services like the ones provided by Dangerous Prototoypes (dirty pcbs), Seeed studio, osh park, etc. It would be less convieniant for teams than AndyMark but still a solution.

Speaking from the standpoint of a FIRST supplier company, forecasting for the FRC community is one of the hardest things with such a short window for sales. If you build too few of an item and it goes out of stock there is almost no way to recover inside the season. On the flip side if you build too much, you will likely have to sit on that inventory for a year before sales start again. That inventory is just "money sitting on a shelf" that can't be used for other things like developing new products or investing in tooling.

Specifically when it comes to MXP boards, last year there was not any history of sales to make a guess at demand. I know that we have put a lot of though into how much we will stick this year and I would assume that they people who make the NAVX have as well.

P.S. yes,the more board will be back in stock soon for the upcoming season.

[FrankJ]

First has spoken. Same rules has last year. In order to produce an approved active board. The PWM pins will have to be pass through. You will need to be a Vendor & be willing to produce it in commercial quantities for the FRC community. If you are not using the MXP port to control movement, you board does not have to be approved.

I wonder if the blog post wasn't at least in part a response to this thread.

[AustinSchuh]

Originally Posted by FrankJ

I wonder if the blog post wasn't at least in part a response to this thread.

They've been planning the blog post for a while.