2015 Beta Testing - The Components are Here.
 

Well, the beta test components showed up yesterday and we couldn't resist snapping some pictures.

http://www.fightingpi.org/Resources/...oduction.shtml

There's not a lot that's new, but at least they've all got their official shells, so this is what you should expect to see for next season.

Re: 2015 Beta Testing - The Components are Here.
 

Looks beautiful! Do you guys plan on making a video of how you connect all the components?

Re: 2015 Beta Testing - The Components are Here.
 

Thanks for posting these. A few things (that may have already been addressed by someone, but I couldn't find anything):

-Now that the shells are more or less finalized, any idea when we might get CAD files or interface drawings to plan for fasteners and layout? Schematics, meanwhile, I can understand not being available until almost kickoff.

-Not sure if data on this already exists. Has anyone done testing on when the regulated VRM outputs drop out? Also, do I understand correctly that the rRio does not have a regulated supply, and therefore is sensitive to all battery fluctuations? Probably this isn't an issue since it runs down to 7V, but any testing and data on this would be great, too.

Edit: nevermind, this isn't really that important
-Any option for (regulated) 24V outputs? (for special sensors, etc. not just from 24V solenoids) I suppose the 2015 rules will dictate if it's legal to use the PCM for this purpose (I suspect not). This has not been available in the past either, but it might be nice ...

There's lots of good suggestions for tests over in this thread, in particular concerning I/O timing and how I/O performance depends on voltage outages, brownouts, etc., as well as other concerns about real-time performance. Does anyone know if there is data or testing on any of this posted somewhere?

Re: 2015 Beta Testing - The Components are Here.
 

This white paper http://www.ni.com/white-paper/14613/en/

is probably pretty close to what you are looking for. The cRIOs used by FIRST are very similar to the 9074, and the roboRIO is very similar to the 9068. There are other white papers that discuss the scheduler and other aspects, but this is the first one I located that had benchmarks.

Just saw your other question. I think it is more appropriate to say that the roboRIO doesn't require an externally regulated supply. The supply of the cRIO and roboRIO were both internally regulated, but the cRIO levels didn't match what was available on a FIRST robot. The roboRIO's internal regulation was designed so that the roboRIO can be connected to any 12V PD circuit. I'm pretty sure the rules will specify that you use the blue circuit on the end of the PD, though.

Greg McKaskle

Re: 2015 Beta Testing - The Components are Here.
 

The shells look very nice! They all look like very quality components!

Can't wait for CAD models. Anyone know when they're coming?

Re: 2015 Beta Testing - The Components are Here.
 

Thanks for the link. I'll give that a read. I'm sure the roboRio will be required to be on the 10A fused connection for protection.

I believe the old PDB kept the 24V supply up with a battery even as low as 4V (or maybe I'm making that number up). When it says the roboRio minimum is 7V, is that the same sort of bottom end for the regulator inside? The battery pretty much never drops below 4V, but can certainly get pulled below 7V if several things are going wrong at the same time, and I'd hate to add a controller reboot to the list of consequences. How does roboRio brownout/reboot compare to that of the regulated supply on the old PDB?

Re: 2015 Beta Testing - The Components are Here.
 

The brownout behavior and voltage levels were a major testing area of the alpha. I'll let the alpha teams describe the details.

The goal is to keep the controller from rebooting for as long as possible. This includes having the motor controllers and possibly other components shut down when necessary to keep power to the roboRIO. It may be tweaked further during the beta, and again, I'll let the teams describe their experience with it.

Greg McKaskle

Re: 2015 Beta Testing - The Components are Here.
 

Any reason a backup battery wasn't implemented for this? I believe this was the exact reason it was included in the old IFI control system. I understand why it wasn't included with the cRio, but the RoboRio is a custom unit.

Re: 2015 Beta Testing - The Components are Here.
 

As one of the SW guys, the best reason I can give is .. because FIRST and the HW guys thought this was a better approach.

I'll let one of them or one of the alpha/beta testers describe more about the behavior.

Greg McKaskle

Re: 2015 Beta Testing - The Components are Here.
 

I hated the IFI backup battery.
It was another thing for teams to keep track of and charged without an easy indicator of when it was depleted or the contact was bad.
They always seemed to be dead for 50% of the teams I helped at events.

Re: 2015 Beta Testing - The Components are Here.
 

It doesn't have to be that way though. Those are all completely solvable problems.

Re: 2015 Beta Testing - The Components are Here.
 

I was told in an email by CRE that CAD would be released as soon as beta teams received their parts. So....yeah.

Re: 2015 Beta Testing - The Components are Here.
 

Everything is a solvable problem. It's the perspectives that differ.
From one perspective the best solution was to be rid of the added operational complexity and make the system more tolerant to low voltage conditions.
When the voltage gets that low, the robot is not going to be going anywhere anyway.

Re: 2015 Beta Testing - The Components are Here.
 

So they should be coming soon! Good news!

Re: 2015 Beta Testing - The Components are Here.
 

And the roboRIO models are already available.

Re: 2015 Beta Testing - The Components are Here.
 

Seconded for truth! That backup battery was a big pain to keep track of... One of our mentors ended up designing a charging circuit for it our second year, so it could stay charged off the main robot battery during competition.

Re: 2015 Beta Testing - The Components are Here.
 

I wouldn't necessarily say the robot wouldn't be going anywhere. It could simply be because of large current draw from drive motors, not that the battery is dead. Waiting for the roborio to reset after that is a real killer. Could the solution be to just add a good sized capacitor across the power inputs?

Re: 2015 Beta Testing - The Components are Here.
 

I'd promote better power design.

P.S.
If you really have this problem then an easier solution might be to have your software check voltage and limit your power draw as it approaches the low end.
Both the cRIO and roboRIO designs cut your motor draw when the voltage drops too low, but if you have really severe power problems then you can implement your own smart power management.

Re: 2015 Beta Testing - The Components are Here.
 

The alpha teams at the second weekend event were actively trying to reset, pushing walls for extended periods of time. We were happy with how it behaved, but they decided to tweak a few things in the FPGA. I'm anxious to see how the beta teams do.

Greg McKaskle

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

I call fake. Where is the famous "Cross the Road" chicken logo? :rolleyes:

Thanks to the alpha teams for the pictures. It isn't quite September but teams are getting the start of build fever. Having real pictures tamps the burning hype down.

Nice looking boxes, it's shaping up for another year of the "electronics look professional"

Re: 2015 Beta Testing - The Components are Here.
 

Can it be? Has the power board distribution board gotten smaller?

Re: 2015 Beta Testing - The Components are Here.
 

Yup. That's been confirmed for a while now, if I remember correctly.

Re: 2015 Beta Testing - The Components are Here.
 

Beautifully timed, I'm looking for some pictures to put into a Powerpoint presentation for an upcoming training class.

Permission to use your pictures is requested.

Re: 2015 Beta Testing - The Components are Here.
 

Absolutely!!!!! That's why we put them up, and that's the whole point of Beta.

Re: 2015 Beta Testing - The Components are Here.
 

We have some random Beta pictures too if you need more.
http://www.team358.org/files/program...stem2015-2019/

Re: 2015 Beta Testing - The Components are Here.
 

Thanks Tom. I appreciate it. The pictures are good and clear.

Re: 2015 Beta Testing - The Components are Here.
 

Mark, the diagram showing the architecture of the control system is just what the Doctor ordered. Thanks to you and the Eagles.

Re: 2015 Beta Testing - The Components are Here.
 

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?

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)

Re: 2015 Beta Testing - The Components are Here.
 

Per NI (a year ago), the voltage selection jumper is inside the case. I have not opened ours to check, however.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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


Thanks, I updated that diagram.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.:yikes:

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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:

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

Edge detection isn't handled nicely currently, so the precision of that is not great.

Considering encoders are pretty industry standard, the real (and completely achievable solution) is just to not lose counts.

Re: 2015 Beta Testing - The Components are Here.
 

I'd suggest limit switches as well, if not just for the added protection of your arm.

Re: 2015 Beta Testing - The Components are Here.
 

This solution requires you to lose precision as your ability to sample transitions on the limit switch cannot keep up with the speed of your arm. We build the fastest mechanisms in FIRST and don't plan to change that any time soon. (Typically, we home them at the beginning of the match by VERY SLOWLY controlling it past the edge of a magnet/hall effect pair and capturing the encoder's current state at the edge).

Also, this doesn't help with motion planning as you can still blow right past/into the limit if you lose counts somewhere in the middle of your range of motion.

As Adam said, I think the right solution is to just not drop counts.

Re: 2015 Beta Testing - The Components are Here.
 

The brown-outs also affect analog sensors like pots. What we saw during Alpha that we'll need to test again was this situation:

As we drew the battery down, then hit full throttle on the drivetrain (6 cim), it would drop the voltage to the potentiometer we used to measure position of our hi-lo. As a result, the hilo would begin to raise (closed loop control always commanding a position).

Of course, with the analog sensor the easy solution is to power it off the VRM. The only problem then is potential wind-up during the brown out period.

Of course, I'll point out that this was happening at very low voltages. We were seeing 6ish volts. We NEVER pull a battery that low during competition, and with the new current monitoring features in the PDB, we hope to monitor and control voltage and current as a safeguard against popping the main breaker as well.

Re: 2015 Beta Testing - The Components are Here.
 

I think this is the operative question. If a boost buck on the sensor supply rail fixes the problem (meaning that the RoboRIO's ability to detect edges isn't compromised), then I can live with that.

Re: 2015 Beta Testing - The Components are Here.
 

I have regularly seen (a couple times a match) 5.5 volts for short periods of time on both 254 and 971's bots over the last couple years. We ran into issues with the 5.5 volt dropout on the old system.

Re: 2015 Beta Testing - The Components are Here.
 

I was suggesting a boost buck _instead_ of the sensor supply, rather than to connect a boost buck to the supply. Not sure if that was a typo, or a different solution.

Re: 2015 Beta Testing - The Components are Here.
 

Yes, this is what I meant.

Re: 2015 Beta Testing - The Components are Here.
 

For the arm and brown out with encoders, A high resolution digital absolute encoder would solve the problem.

This whole conversation on power supplies and brown outs is a side effect of a bigger problem facing First and teams. We are in the midst of a drive train power arms race with a power system that was not designed to handle the escalation. There are other implications mechanical that will manifest them selves in the future. Shredded carpet, wheels melted to carpet, failure of field elements from high velocity impacts, melted Anderson power plugs, battery failure, bumper shredding, bent frames, etc.etc. It started this year and will escalate in the future. First could solve this problem by regulation. Limit drive train power. That would get the First community all fired up. Or let things be and the smart teams will learn power management.
I ordered some current sensors this week. Our team did not really quantify our power usage in the past. We intent to put some numbers to the systems on this years robot and start thinking of power budgeting in the future.

Re: 2015 Beta Testing - The Components are Here.
 

With high-speed, multi-turn mechanisms there is always a risk of missing the rollover. In 2013 on 341 we used absolute encoders on our drive, and I will never do it again.

Competitive teams are always going to try to squeeze as much performance out of their robots as possible. I think Aerial Assist was particularly brutal because with a wide open field, one game piece per alliance, and no safe zones, teams were incentivized to play rock 'em, sock 'em robots. Give us a different field, or more scoring objectives, or ways to play the game that don't require out-racing or pushing your opponents, and you'll see the arms race calm down a little bit.

Re: 2015 Beta Testing - The Components are Here.
 

Let's make a few givens clear. There are systems where an encoder is a totally valid and optimal sensor. Teams shouldn't be told to be clever and figure a way around .

There are also reasons a brown out could occur independent of team error or design flaw. A battery just dropped a cell, something gets sucked into drive, etc...

These reasons combined are enough to say it is unacceptable to brown out.

I don't see how losing encoder counts due to low voltage is justifiable at all in this day and age considering it's so easy to solve. A better regulator external or a backup battery. IFI solved this years ago.

Re: 2015 Beta Testing - The Components are Here.
 

I've seen brownouts on robots with only 4 CIMs in their drivetrain in a single match with well cared for batteries. I've been seeing brownouts of encoders for the last 3 years with the cRIO system. If you were to limit drivetrain power to 4 CIMs, that wouldn't fix the problem.

Re: 2015 Beta Testing - The Components are Here.
 

They could limit the drive train to 2 CIMs and it'd still happen.

We need reliable encoders. Period.

Re: 2015 Beta Testing - The Components are Here.
 

To review what is going on with this issue.

The robots are capable of drawing hundreds of amps from the battery and that causes an enormous drop in the voltage seen by robot components. This is also affected by battery condition, wiring loss, gearing, number of motors, etc.

If nothing attempts to manage the current draw, motor controllers, robot controller, VRM, PCM, cameras, and anything else with a micro controller will reboot, fault, and misbehave. Lots of bad behaviors that nobody wants to see.

If the condition persists for very long, the heat will cause breakers to pop or fuses to blow in order to prevent wire failures.

Luckily the system is capable of managing current draw at many levels.
1. The roboRIO monitors its input voltage level and coordinates brownout staging in order to prevent blackout of critical elements. This is the approach that is currently being tweaked.

The general approach of the brownout behavior is to disable high draw components -- motor controllers -- in order to stabilize the voltage level and avoid reboots and further faults. As mentioned earlier, the alpha results were quite promising, but the response is being tweaked in order to maintain the supply rails to sensors -- both analog and digital.

One aspect of this, detailed by Joe earlier, is to identify which PWM devices are motors and which are servos. The FPGA will then be able to disable motors directly instead of simply removing their signal and waiting for their micros to timeout. This quicker response has not been tested by the alpha or beta teams, but it is a ~10X improvement in timing control of the circuit driver.

2. When a brownout does occur, the information will be accessible to robot code. If the motor controllers outputs are zeroed by the FPGA, this can cause integral windup in control loops. If those control loops are aware that their set point was not what they requested, they can adjust their integral state.

If the brownout is more severe and the supply lines to servos and sensors is interrupted, the robot code can know that absolute position of some mechanisms may need to be recalibrated.

3. Motor controllers implement the set point, and as seen with the Jaguar, they can impose limits. Currently this is not a part of the plan.

4. User code is in charge of motor controller set points. Ramping or limits are easy to implement. The Power API now gives feedback from the PD and roboRIO that should help with balancing performance and current draw. I don't personally have a PD to test, but it is hoped that external current sensors and monitoring isn't really required in order to make this approach effective and accessible to many teams.

5. Robots sensors could be allowed to use a suppy that is not shared with servos.

There are probably others. I feel that the next step is to characterize the improvement that Joe has already implemented. I'm sure that will be accomplished in the beta. Probably quite soon.

Greg McKaskle

Re: 2015 Beta Testing - The Components are Here.
 

I'm guessing you were not using Jaguars. If not, then this is on a system with zero ability to disable motors based on battery monitoring. The cRIO did not attempt to stop driving motors when you saw huge battery sag. I believe everything you've seen in the past is not directly applicable to the behaviors of the new system. You will need to reevaluate what you think is regularly seen.

Re: 2015 Beta Testing - The Components are Here.
 

The bus switch that adjusts the signals passed to the FPGA is powered by a supply that is sourced by the buck-boost that powers the controller as a whole. That supply operates down to 4.5 V. That means that if you decide to power your encoder with a supply other than the one provided and the provided supply browns out, the signals will still make their way to the FPGA. As noted earlier, if your sensor depends on pull-up resistors (like limit switches or banner sensors or open-collector output encoders) then you will also need to add pull resistors connected to your external supply. You should be able to test this by either using the new power API to disable the 5 V supply manually or by installing a jumper between 5 V and Ground which puts the supply in protection.

Re: 2015 Beta Testing - The Components are Here.
 

Agreed. That is the next step. Thanks for the thorough description of what is going on. I really appreciate it.

Thanks Joe for describing the signal path to the FPGA, and working on improving the response time.

Hopefully we are all just getting worked up over nothing.

Re: 2015 Beta Testing - The Components are Here.
 

I am an expert in that! :rolleyes:

Re: 2015 Beta Testing - The Components are Here.
 

Does this means that we can use 5v devices (provided they read a 3v3 signal as high) without any risk of damaging the RoboRIO? I'm just thinking about various sensors and custom circuits that were designed for 5v that may perform differently at 3v3. They can probably be re-designed but it would be nice if that wasn't necessary.

Re: 2015 Beta Testing - The Components are Here.
 

yes

Re: 2015 Beta Testing - The Components are Here.
 

I'm looking at the power board/pneumatic bumper, and it seems to me that the pneumatics bumper has a relay/other driver built in to power the compressor. It also is powered from a fuse, which looks like
https://www.eficonnection.com/eficon.../mini_fuse.jpg , which is smaller than the spike fuse, meaning our normal 20 amp resetting breakers won't work here.

How do we replace the 20 amp fuse shown in (http://www.team358.org/files/program...mages/PDP2.jpg) that picture with an auto resetting one?

Re: 2015 Beta Testing - The Components are Here.
 

You don't...

Re: 2015 Beta Testing - The Components are Here.
 

If you use a 20 amp not resetting fuse, as shown in the picture and the robot's battery is a little low, it trips when the compressor starts, leaving your robot without a compressor in the middle of the match. It's happened to me before.

The people who make this know this (as the manual has an exception for this), so either I'm not understanding how this works, or their will be issues with the fuse getting blown during matches. I'm betting that I don't understand how this works, and was wondering if somebody who actually has the part knows how it would work.

Re: 2015 Beta Testing - The Components are Here.
 

Given both the pneumatic module and the power distribution board are connected to the RoboRIO via CAN, there is a possibility that these devices are monitoring the current to prevent fuse blowouts that the comparatively simplistic implementation "on off with a relay" on the old system couldn't compensate for.

Re: 2015 Beta Testing - The Components are Here.
 

To my knowledge - we didn't see any blow fuses during Alpha testing.

The CTRE guys will need to answer this one. I'll fire them an email.

Re: 2015 Beta Testing - The Components are Here.
 

You can get self-resetting circuit breakers in this form factor fairly easily.

Amazon
Grainger

Re: 2015 Beta Testing - The Components are Here.
 

This was exactly our concern when we sat down to wire it up the first time. Fortunately, the PCM is monitoring the current on the compressor and each of the solenoid channels and will disable the channel temporarily if then current is too high. I have not heard of a blown fuse on the PCM yet.

Re: 2015 Beta Testing - The Components are Here.
 

Self-resetting breakers usually do not trip as precisely as fuses. If the downstream circuits really cannot handle >20A, even for a second, you ought to use a fuse.

Re: 2015 Beta Testing - The Components are Here.
 

Fine, but aren't we're talking about an application (powering the compressor) where self resetting circuit breakers have been used successfully for some time?

Re: 2015 Beta Testing - The Components are Here.
 

With different hardware, yes. From what I've been told in the past, Vex (the makers of the spike relay) did specific testing with a circuit breaker to validate it as safe before FIRST allowed it to be used for compressors in the rules. That's the only reason teams were allowed to replace the provided fuse with a breaker for use with compressors.

For FRC usage, breakers, in general, are present to protect the wiring, not the components attached to that wiring. For this 20A fuse, it could protect the PCM from over-current if (for example) something gets shorted out... but my guess would be that the fuse is there to prevent the PDP from burning out by drawing too much current from those outputs. It's probably there to protect against a short much more than to protect downstream circuitry.

Re: 2015 Beta Testing - The Components are Here.
 

I'd be very surprised if replacing the PDB fuse with a breaker will be legal for competition.

Re: 2015 Beta Testing - The Components are Here.
 

May CRE did something fancy like soft starting the compressor.

Re: 2015 Beta Testing - The Components are Here.
 

You can like our Facebook page at:
https://www.facebook.com/FRC2015ControlsBeta

For the latest in Team 116's beta testing of the new controls. We just got most of the 'bot integrated and we're working on getting the software going next. We're working with WinDoze first to figure out the flow. But, since many of us are die-hard Linux fans, getting everything working on Linux is big on our list of to-dos. BTW, the Simulator for C++ and Java runs on Ubuntu 14.04. So, getting everything integrated for the 14.04 release (compilers, etc.) show help streamline most of the activity and get us out from under the tyranny of WinDoze 8. :D

Mike

Re: 2015 Beta Testing - The Components are Here.
 

The CTRE CAD has been posted for:

• Voltage Regulator Module
• Pneumatics Control Module
• Power Distribution Panel

http://www.crosstheroadelectronics.c...ol_system.html

Re: 2015 Beta Testing - The Components are Here.
 

We've posted some short video walkthroughs of the Beta Control System components. Here's a link to a Youtube Playlist of all seven videos.

https://www.youtube.com/playlist?lis...FQhrOJ7KvZbkBQ

The videos cover:
1. Overview
2. RobotRio
3. Pneumatic Control Module
4. Power Distribution Panel
5. Voltage Regulator Module
6. Victor SP
7. Weidmuller Connectors

Re: 2015 Beta Testing - The Components are Here.
 

I have a few questions about the new hardware.

Does the CAN bus support multiple pneumatics modules?
Are the 12 volt connectors with the 20/10 amp fuses on the PDP regulated? (I don't think so, but I'm not sure)

Do the compressor, solenoids, and voltage regulator module, which powers cameras, custom circuits, and the radio share the same single 20 amp fuse? If this trips (because of compressor current spikes or short anywhere) does this mean radio power is lost?

Re: 2015 Beta Testing - The Components are Here.
 

Team 358's website is an awesome resource for the beta test. They really have everything.

From reading their description, you're right about how it works.
I agree that putting the radio, the most critical component of the control system, on a non-resetting fuse that is shared with many other loads is a silly idea. Starting a compressor when the battery is very low often trips the spike's fuse, and in addition, we are also powering 8 solenoid valves (less than .25 amps for all 8 channels going at the same time) and over 3.5 amps (@ 12 volts) from the VRM.

Re: 2015 Beta Testing - The Components are Here.
 

On the new roboRIO, there are dedicated I2C and SPI ports in addition to I2C and SPI pins on the MXP port.

Are those shared signals or separate ports?

Re: 2015 Beta Testing - The Components are Here.
 

separate ports

Re: 2015 Beta Testing - The Components are Here.
 

Are the RS-232 and MXP UART also separate? And do you know if the USB ports could be used to communicate in direct connection with a microprocessor or R-Pi as a serial port or via a USB to RS-232 converter?

Re: 2015 Beta Testing - The Components are Here.
 

The RS232 and the TTL ports are also separate.
The USB device port is already used to communicate with Driver Station and user development PCs.

The other two USB ports don't have any FRC assigned purpose yet and can be used as you wish and extended however you can devise through Linux support. You'd need compatible Linux drivers for any USB to RS232 converter. That development will have to be conducted by you in regards to your special needs.

Re: 2015 Beta Testing - The Components are Here.
 

The most well-functioning USB-serial chipset that works well with the roboRIO is the FTDI. If your device uses an FTDI, you shouldn't have any trouble. Others can function but with more effort.

Re: 2015 Beta Testing - The Components are Here.
 

I'm certain this has been mentioned elsewhere on CD, but in this thread I didn't see any mention of it.

We have a new mentor who does Java programming for a living. He would like to help us migrate from using LabView to using Java. We have not done this in the past because I have ZERO, nada, nothing in the way of Java experience.

So, to help him help us, I need to point him to all the resources available for this new controller and the implementation of Java it will be using.
Basically, where can I point him?

Re: 2015 Beta Testing - The Components are Here.
 

Well, I don't think the libraries are public yet... the RoboRio is running Java 8 SE, and the library API isn't really that different than it was last year. If he knows Java 8, he can look up the javadoc form last year and figure it out pretty easily.

Re: 2015 Beta Testing - The Components are Here.
 

For years we've been trying to get real time debugging working on java over the network and we haven't been able to get it to work, have you used it on the robo rio?

Re: 2015 Beta Testing - The Components are Here.
 

I've been looking for the weights of these components. Has anyone weight the beta components? I've looked in several places. The Fighting Pi weighed the alpha components without cases, but I haven't seen weights of the beta components with cases yet.

Re: 2015 Beta Testing - The Components are Here.
 

I should have posted that.

This is what Rosalie measured for the Beta components:

• roboRIO - 11.0 oz
• VRM - 1.8 oz
• PCM - 2.3 oz
• PDP - 1 lb 5.3 oz

Re: 2015 Beta Testing - The Components are Here.
 

Thanks Mark

Re: 2015 Beta Testing - The Components are Here.
 

We've had intermittent success with debugging with Java on the cRIO, more likely to work when tethered. With the roboRIO, they are asking each beta team to test debugging (for each language) so it should be solid.

Currently, there's been a few minor issues, which have been or are being worked on, however, we've had far more success debugging with the roboRIO then we ever had with the cRIO.

Re: 2015 Beta Testing - The Components are Here.
 

I have a few questions about the PCM and the 20A fuse. Others have expressed concern that the VRM and the PCM paired up on this fuse could approach 20A, and that this endangers the entire system since the radio will presumably be powered off of a 5V or 12V output. It sounds like Alpha teams did not have issues with this; we've yet to hear from Beta teams.

So while a single PCM and a single VRM may not be an issue, what about the possibility of more than one of either of these components. While needing 2 VRMs worth of voltage-regulated current is unlikely, it's totally reasonable to expect teams to want more than 8 solenoid channels for their pneumatic system. So here are the questions:

-Has there been any testing with multiple VRMs or PCMs on the designated, fused output? Does this present a significant risk of blowing the fuse and losing radio power?

-If this is the case, are there other options for powering additional VRMs/PCMs? Would a 20A breaker slot on the PDP be enough to protect their circuitry, and might this be included as an option in the 2015 rules? If someone has seen spec sheets for these components, please share them.

Re: 2015 Beta Testing - The Components are Here.
 

You should know better about asking for the rules before kickoff...
So multiples may or may not be allowed. Beta teams aren't on the GDC, :rolleyes: we're just trying to break things.

Personally, my team won't get additional PCM/VRM to test until December at the earliest, but we will test them when we are able.
We're doing our power extreme tests now, but haven't put max loads on the VRM/PCM yet.

No published power draw specs on the VRM/PCM components yet, but the math looks good and there doesn't appear to be any great risk of being constrained by the 20a PDP fuse, even if some strange game rule wiring scheme allows split wiring.

• 240w: a 20a PDP circuit at 12v will supply 240w.
• 45w: A VRM at max output will draw maybe 45w (12v*2a+12v*.5a+5v*2a+5v*.5a)
• 135w: A PCM at regular output will draw maybe 135w. Assumes an old Thomas compressor ~126w, plus (8) 1w per single solenoid coil or (4) 1w per double solenoid. Compressor startup draws up to 300w momentary, but handling that predictable one time surge is designed into the circuit. Longer compressor stalls are probably treated like short circuits and cut off - we'll test to see what happens in that case that later on.
• 5w to 9w: Additional PCMs will draw maybe 9w (single solenoids) or 5w (double solenoids) since multiple compressors aren't necessary.
• Both VRM/PCM have short circuit protection, so higher draws are prevented.

So,
240w = (45w+135w)baseline + a second VRM (45w) + a second PCM (9w) leaving breathing room.

I would recommend that 16 gauge wire be used if you start doubling up components for any non-FRC usage.

Re: 2015 Beta Testing - The Components are Here.
 

True, but a short on your compressor wiring, your PCM wiring, your VRM wiring, or your radio wiring will cause the radio to drop out for the entire match. Last year's radio supply powered the radio, and the radio only, and didn't have any non resetting fuses.

Re: 2015 Beta Testing - The Components are Here.
 

Actually, no a short will not cause this (except for radio short of course). That's part of the point.
We have already started shorting out the various outputs just to make sure.

Re: 2015 Beta Testing - The Components are Here.
 

That is good news that there is some protection in the individual modules, but that still won't protect that fuse from shorts at the PDB.

If there is a short between the wires that power the VRM or the PCM (not the loads connected to these modules), will the 20 amp fuse trip? This would be the same as just shorting the output of the 20 amp fused output on the PDB, so I'm assuming it would.

I have a fear of these hard to diagnose intermittents shorts after this season. We played with multiple teams (at least 4 that I saw) whose PWM outputs would drop out because of an intermittent connection between the DIO power pins, which caused the DSC's 5V supply to go out.

Re: 2015 Beta Testing - The Components are Here.
 

Any fault that cuts the power path to the radio, cuts the power to the radio. The fuse isn't going to matter, blown or un-blown it's already too late, the match is pretty much over.

Protection cannot do anything about a complete loss of power. It can only help prevent things that are bad from getting much, much worse.

Short protection has been greatly increased, so CTRE/NI have isolated faults to pretty much where they occur and not neighboring systems. roboRIO DIO shorts won't also take out the PWMs, but yea, if our wiring is bad, then there is no genie that will fix that other than our own electrical sub-team.

Beta teams will test the shorts that seem reasonable, so if you have ideas let all of us know. It might not be something we've thought of to test.