2015 Beta Testing - The Components are Here.

[BitTwiddler]

I have a question regarding the discrete wire terminals used for low current power distribution and the CAN bus. I'm not familiar with that style of terminal. Can someone post a link to the manufacturer or some document describing how they are used?
Thanks.

[RufflesRidge]

Originally Posted by BitTwiddler

I have a question regarding the discrete wire terminals used for low current power distribution and the CAN bus. I'm not familiar with that style of terminal. Can someone post a link to the manufacturer

http://www.digikey.com/catalog/en/pa...mt-series/3103

or some document describing how they are used?

Push button down, insert stripped wire, let go of button.

[Tom Line]

You'll find a good description of the connectors here:
http://www.fightingpi.org/Resources/...20Module.shtml

manufacturer:
http://catalog.weidmueller.com/catal...15980277147218

With the right wire you don't need to push the button to insert it, but we've found most stranded wires require us to push the button. You also need to strip the correct amount of insulation, but really that's not any different than other connection styles.

[Mark McLeod]

Originally Posted by timytamy

On the diagram under the custom electronics port, it shows that the DIO has been pulled up to 3v3, implying that it uses 3v3 logic levels. Could you clarify, what logic levels does the RoboRIO use on both the main IO and MXP port? I believe I saw a voltage selection jumper on some alpha pics, implying that voltage is selectable, does this work and does it affect both the main-IO and MXP or just one?

Here's the jumper. The DIO power is 5v by default.

Also your MXP pin-out is out of date. It appears that the roboRIO will get a different configuration to the myRIO (https://decibel.ni.com/content/docs/DOC-30419)

Thanks, I updated that diagram.

[jhersh]

Originally Posted by timytamy

On the diagram under the custom electronics port, it shows that the DIO has been pulled up to 3v3, implying that it uses 3v3 logic levels. Could you clarify, what logic levels does the RoboRIO use on both the main IO and MXP port? I believe I saw a voltage selection jumper on some alpha pics, implying that voltage is selectable, does this work and does it affect both the main-IO and MXP or just one?

The jumper only affects the DIO power pins on the built-in DIO connectors. The MXP has both power supply rails included, so the board may use either one as needed. The I/O itself in both MXP and built-in DIO is not affected by the jumper. All DIO is 3.3 V drive and 5 V tolerant.

[AustinSchuh]

Originally Posted by Tom Line

We spent a long time trying to get the robot to die and couldn't manage it. We could not move the robot because our voltage was so low, but the roborio never reset. I don't expect if to be a problem.

My big question is whether or not we will lose encoder counts while that happens (encoder brownout). The digital side car would brown the encoders out below 5.5 volts, which caused us to destroy a gear once. We'll have to add that to our list of things to test.

[coolhandluke811]

I had an opportunity to take mount hole measurements of the 3 new CRE parts.

If you would like my super rough CAD (boxes with holes), message or email me.

Can't be off than more than a hundredth or two here or there.

Sorry ahead if I don't respond immediately. Will be out of town till the weekend.

[timytamy]

Originally Posted by coolhandluke811

I had an opportunity to take mount hole measurements of the 3 new CRE parts.

If you would like my super rough CAD (boxes with holes), message or email me.

Could you post the quick measurements? I expect that at this stage most people are mainly interested in seeing whether the centre-to-centre distances are multiples, 1/4", 1/2" 10mm, 20mm, etc.

[Joe Hershberger]

Originally Posted by AustinSchuh

My big question is whether or not we will lose encoder counts while that happens (encoder brownout). The digital side car would brown the encoders out below 5.5 volts, which caused us to destroy a gear once. We'll have to add that to our list of things to test.

Unfortunately the topology of the power supplies that feed external user devices like the encoders is part of the system that does not "survive". Based on alpha team feedback, we are making some small adjustments to make it last longer, but the topology doesn't help with that case. The structure looks like this:

VbattIn ----[6 V "servo" supply]-----[current limit/disable]---6 V terminals
                                    \
                                     ----[5 V user supply]-----5 V terminals
                                      \
                                       --[3.3 V user supply]---3.3 V terminals

The change we made was to not disable the 3.3 V or 5 V supplies when we detect a brown-out condition (VbattIn < 6.8 V). This helps a bit for the 5 V to survive, but when the VbattIn drops to about 6.2 V, the 6 V servo supply is no longer able to stay active, so the 5 V and 3.3 V supplies drop out with a source voltage fault.

It does mean there is now ~ 0.6 V between when the motors are disabled and when the 5 V and 3.3 V supplies shut down instead of them happening at the same time.

I'm also working on a feature that will allow the FPGA to stop motor controllers (probable source of brown-out in non-pathological case) in far less time. The plan is to actively send one PWM pulse of "idle" when commanded to disable by the watchdog / power monitor before stopping the generation of PWM signals. Because the motor controllers are not continuing to draw high current for as long, the voltage drop should be less severe. This should reduce the time from brown-out detection to load removal from 100 ms +/- 5ms to about 10 ms +/- 5 ms.

[AustinSchuh]

Originally Posted by Joe Hershberger

The change we made was to not disable the 3.3 V or 5 V supplies when we detect a brown-out condition (VbattIn < 6.8 V). This helps a bit for the 5 V to survive, but when the VbattIn drops to about 6.2 V, the 6 V servo supply is no longer able to stay active, so the 5 V and 3.3 V supplies drop out with a source voltage fault.

Bummer, thanks for the clarification. This just means that the 5V supply browns out, not the robotRIO's ability to read the digital inputs? I'm trying to figure out whether or not if we were to power the encoders another way, if that would fix it.

[Jon Stratis]

Originally Posted by AustinSchuh

Bummer, thanks for the clarification. This just means that the 5V supply browns out, not the robotRIO's ability to read the digital inputs? I'm trying to figure out whether or not if we were to power the encoders another way, if that would fix it.

I would imagine that the Voltage Regulator Module (VRM) would be more tolerant to voltage drops. It provides both 5V and 12V regulated output, but I don't know what the specs are for brownout conditions on it.

[Aren Siekmeier]

Originally Posted by AustinSchuh

Bummer, thanks for the clarification. This just means that the 5V supply browns out, not the robotRIO's ability to read the digital inputs? I'm trying to figure out whether or not if we were to power the encoders another way, if that would fix it.

Originally Posted by Jon Stratis

I would imagine that the Voltage Regulator Module (VRM) would be more tolerant to voltage drops. It provides both 5V and 12V regulated output, but I don't know what the specs are for brownout conditions on it.

However, since the DIO signal pins are pulled up to the same 5V supply in the roboRIO, I'm sure they will have the same brownout behaviour as the power pins. It doesn't matter if the encoder is powered if you can't read when the signal is shorted to ground.

[AustinSchuh]

Originally Posted by compwiztobe

However, since the DIO signal pins are pulled up to the same 5V supply in the roboRIO, I'm sure they will have the same brownout behaviour as the power pins. It doesn't matter if the encoder is powered if you can't read when the signal is shorted to ground.

The pullup will be a weak pullup (~50k or 10k.). That amounts to 0.1 mA or 0.5 mA of current required to pull the line down under normal use. Say, for the sake of argument, that the pullup was now connected to 0 volts (gnd) due to the brownout. You would only need to source 0.5 mA max to overcome the pullup. This isn't all that much different than sinking 0.5 mA when overcoming it normally, though the direction is different and components are generally rated differently for source vs sink.

This ends up being a rules and robotRIO internals question. Designing a board (and/or using the CTRE regulator) to supply encoder power is far easier than designing an entire co-processor setup, which 971 has been doing for years. I've debugged enough problems on bots over the last couple years which ended up being encoder brownouts that I take this pretty seriously.

[Tom Bottiglieri]

Originally Posted by AustinSchuh

I've debugged enough problems on bots over the last couple years which ended up being encoder brownouts that I take this pretty seriously.

This has been our number one issue with the control system every year. The issue goes something like this:

You are driving the robot, while moving an arm. You change directions quickly on the drive base and pull a ton of current to the motors. The +5V rail browns out for about 100ms, but the arm is still moving, so you "skip" maybe 5-10 degrees worth of rotation on a quick arm. Next time you command the arm to a position near the limit, it slams in to it without remorse.

We have built custom electronics to overcome this in the past, but perhaps it would make sense to make something more generic. Maybe a board that sits of the expansion port and takes power from the VRM? All high priority inputs would route through this.

[Jon Stratis]

What about adding in limit switches to your mechanism to detect max travel distance and calibrate the encoder on the fly?