2015 Beta Testing - The Components are Here. [Archive]

Aren Siekmeier

16-08-2014, 13:25

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

http://www.fightingpi.org/Resources/Controls/Beta/2015_Beta/Introduction.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.

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 (http://www.chiefdelphi.com/forums/showthread.php?t=119883), 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?

Greg McKaskle

16-08-2014, 16:26

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

cadandcookies

16-08-2014, 16:32

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

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

Aren Siekmeier

16-08-2014, 16:51

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

...

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.

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?

Greg McKaskle

16-08-2014, 17:09

Michael Hill

16-08-2014, 18:05

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

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.

Greg McKaskle

16-08-2014, 18:41

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

Mark McLeod

16-08-2014, 18:44

Michael Hill

16-08-2014, 18:57

coolhandluke811

16-08-2014, 19:02

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

Mark McLeod

16-08-2014, 19:04

It doesn't have to be that way though. Those are all completely solvable problems.
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.

cadandcookies

16-08-2014, 19:16

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

So they should be coming soon! Good news!

cgmv123

16-08-2014, 19:29

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

And the roboRIO models are already available (https://decibel.ni.com/content/servlet/JiveServlet/download/30419-53-80491/roboRIO+CAD.zip).

Jon Stratis

16-08-2014, 19:30

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.

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.

Michael Hill

16-08-2014, 19:34

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.

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?

Mark McLeod

16-08-2014, 19:38

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.

Greg McKaskle

16-08-2014, 20:22

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

Tom Line

16-08-2014, 20:49

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.

Foster

16-08-2014, 20:56

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"

Nemo

16-08-2014, 22:19

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

cadandcookies

16-08-2014, 22:24

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

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

BitTwiddler

17-08-2014, 14:57

Tom Line

18-08-2014, 15:27

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.

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

Mark McLeod

18-08-2014, 15:47

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

BitTwiddler

18-08-2014, 19:58

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

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

BitTwiddler

18-08-2014, 19:59

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

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

timytamy

18-08-2014, 20:05

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

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)

Joe Ross

18-08-2014, 20:15

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?

Per NI (a year ago) (http://www.chiefdelphi.com/forums/showpost.php?p=1286934&postcount=114), the voltage selection jumper is inside the case. I have not opened ours to check, however.

BitTwiddler

18-08-2014, 20:55

RufflesRidge

18-08-2014, 21:45

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/partgroup/lsf-smt-series/3103

or some document describing how they are used?

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

Tom Line

18-08-2014, 22:07

You'll find a good description of the connectors here:
http://www.fightingpi.org/Resources/Controls/Alpha/2015_Alpha/Pneumatic%20Control%20Module.shtml

manufacturer:
http://catalog.weidmueller.com/catalog/Start.do?localeId=en&ObjectID=group15980277147218

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

19-08-2014, 00:02

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.
http://www.team358.org/files/programming/ControlSystem2015-2019/images/sm_DIOinternaljumper2.jpg

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

19-08-2014, 00:18

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

19-08-2014, 01:52

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

19-08-2014, 08:41

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:

timytamy

19-08-2014, 09:59

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

19-08-2014, 11:07

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

19-08-2014, 11:50

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

19-08-2014, 12:20

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

19-08-2014, 12:28

AustinSchuh

19-08-2014, 13:36

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

19-08-2014, 13:48

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

19-08-2014, 14:45

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

AdamHeard

19-08-2014, 14:47

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

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.

Michael Hill

19-08-2014, 14:59

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

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

Tom Bottiglieri

19-08-2014, 16:23

What about adding in limit switches to your mechanism to detect max travel distance and calibrate the encoder on the fly?
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.

Tom Line

19-08-2014, 18:38

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.

Jared Russell

19-08-2014, 18:47

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

AustinSchuh

19-08-2014, 18:49

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.

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.

AustinSchuh

19-08-2014, 18:50

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.

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.

Jared Russell

19-08-2014, 20:05

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.

Yes, this is what I meant.

Gdeaver

19-08-2014, 22:22

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.

Jared Russell

19-08-2014, 22:48

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

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.

We are in the midst of a drive train power arms race with a power system that was not designed to handle the escalation.

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.

AdamHeard

20-08-2014, 01:15

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.

AustinSchuh

20-08-2014, 01:26

It started this year and will escalate in the future. First could solve this problem by regulation. Limit drive train power.

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.

AdamHeard

20-08-2014, 01:28

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.

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

We need reliable encoders. Period.

Greg McKaskle

20-08-2014, 09:02

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

Joe Hershberger

20-08-2014, 11:02

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.

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.

Joe Hershberger

20-08-2014, 11:39

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.

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.

AustinSchuh

20-08-2014, 12:46

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.

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.

AdamHeard

20-08-2014, 12:49

Hopefully we are all just getting worked up over nothing.

I am an expert in that! :rolleyes:

timytamy

20-08-2014, 23:33

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.

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.

jhersh

21-08-2014, 17:33

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.

yes

Jared

21-08-2014, 19:37

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/eficonnection/images/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/programming/ControlSystem2015-2019/images/PDP2.jpg) that picture with an auto resetting one?

RufflesRidge

21-08-2014, 20:00

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

You don't...

Jared

21-08-2014, 20:51

You don't...
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.

Trent B

21-08-2014, 21:17

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.

Tom Line

22-08-2014, 00:32

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.

Nate Laverdure

22-08-2014, 08:02

You can get self-resetting circuit breakers in this form factor (http://www.cooperindustries.com/content/public/en/bussmann/consumer/products/automotive_circuitprotectionprdandacc/automotive_marinecircuitbreakers/atm_atc_max_glasstube.html) fairly easily.

Amazon (http://www.amazon.com/Bussmann-CB211-20-Brass-Colored-Type-Breaker/dp/B000CSXIEU)
Grainger (http://www.grainger.com/product/BUSSMANN-Automotive-Circuit-Breaker-5KDL2)

Jefferson

22-08-2014, 09:31

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.

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.

Jared Russell

22-08-2014, 12:27

Nate Laverdure

22-08-2014, 13:21

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

Jon Stratis

22-08-2014, 14:53

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?

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.

cgmv123

22-08-2014, 19:12

Gdeaver

22-08-2014, 19:27

May CRE did something fancy like soft starting the compressor.

taichichuan

24-08-2014, 00:54

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

Mark McLeod

26-08-2014, 10:24

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.

The CTRE CAD (http://www.crosstheroadelectronics.com/control_system.html) has been posted for:

Voltage Regulator Module
Pneumatics Control Module
Power Distribution Panel
http://www.crosstheroadelectronics.com/control_system.html

Karthik

28-08-2014, 16:35

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?list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ

The videos cover:
1. Overview (https://www.youtube.com/watch?v=CUhJJPYx-QI&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=1)
2. RobotRio (https://www.youtube.com/watch?v=WU7M7iEQOEg&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=2)
3. Pneumatic Control Module (https://www.youtube.com/watch?v=aGVH7hwl-eo&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=3)
4. Power Distribution Panel (https://www.youtube.com/watch?v=ol7BdxSHwkM&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=4)
5. Voltage Regulator Module (https://www.youtube.com/watch?v=gbnVAMKmUes&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=5)
6. Victor SP (https://www.youtube.com/watch?v=YV_j0eMeG4s&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ&index=6)
7. Weidmuller Connectors (https://www.youtube.com/watch?v=NmmIXMIfdSs&index=7&list=PLG_KOHBuXHNdUeoDkGSFQhrOJ7KvZbkBQ)

Jared

29-08-2014, 19:22

magnets

29-08-2014, 22:43

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?

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.

(2) dedicated power for Pneumatics Module and/or Voltage Regulator w/20a fuse

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.

jvedder

30-08-2014, 22:19

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?

Mark McLeod

30-08-2014, 23:10

separate ports

jman4747

08-09-2014, 18:38

separate ports

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?

Mark McLeod

09-09-2014, 09:54

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.

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?

jhersh

09-09-2014, 14:04

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.

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.

billbo911

10-09-2014, 19:31

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?

Jon Stratis

10-09-2014, 20:45

Bryce Paputa

10-09-2014, 22:26

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.

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?

Michael Hill

10-09-2014, 22:52

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.

Mark McLeod

11-09-2014, 20:12

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

Michael Hill

11-09-2014, 20:21

I should have posted that.

This is what we measured for the Beta components:

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

Thanks Mark

Joe Ross

11-09-2014, 20:27

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?

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.

Aren Siekmeier

12-09-2014, 04:31

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.

Mark McLeod

12-09-2014, 09:49

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.

Jared

12-09-2014, 20:02

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.

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.

Mark McLeod

12-09-2014, 20:39

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

Jared

12-09-2014, 21:42

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

Mark McLeod

13-09-2014, 08:16

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?

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.

kstl99

14-09-2014, 20:16

My biggest issue with the controls components we have been using is with the PWM cables and their lack of a locking device on the motor drives and Spike relays. With the amount of shock and vibration the robots get they will and do fall out unless something is done to lock them in place. The two most common methods I have found teams using are to either secure the cable near the connection meaning that the tiny wires are holding the connectors in place, or they use hot melt glue to glue them in place. Neither of these methods are acceptable on real automation equipment.

Hoe secure are the PWM connections on the new components?

Aren Siekmeier

14-09-2014, 20:35

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.

But hopefully the rulemakers are reading these threads and listening to their beta testers. I was just asking if there's been any discussion of power alternatives for the radio/VRM/PCM.

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

Thanks for the numbers, that does make me more comfortable. It may be better to talk about current than power, since the power will depend on both current draw and Vbat (and power to start the compressor will depend on a lot of things including those, etc.). The fuse is sensitive to current only, and presumably the protection features in the PCM and the VRM are as well.

Not sure what stage you're at in the test right now, but I think many people would be interested in data regarding compressor current draw vs. time and pressure, if you can fit it in. EDIT: I should clarify: since this will depend a lot on the exact compressor model, maybe compare it to the current draw when running off a spike using pre-2015 control logic (hard starts), so we can see how the PCM manages the current draw.

timytamy

14-09-2014, 21:01

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.

In addition to say shorting the outputs of the VRM (ie does shorting a 12V take out the other 5V and 12V supplies and vica versa.

I'd be interested in any over-current on the VRM, ie what happens when something connected to the 12V 2A supply tries to pull 3A, and similar data for the other three outputs.

Tom Line

15-09-2014, 18:20

A couple of things we've learned - the PCM monitors the current draw to the compressor and protects against blowing the fuse. Beta testing will tell us just how smart it is, but so far I haven't heard about any of the fuses blowing.

We don't know that extra PCM and VRMs will be allowed under the rules, however the vendor suggested that additional ones could be powered from the 20/30 amp breakouts on the PDP.

In addition, (and this may have been just me), I had assumed that the VRM connections were individually rated at the amperages listed. However, the connections at each voltage / amperage rating share a rail. For instance, the 12V 2A connections are 12V, for a total of 2 amps. Not 12V 2A each.

Also, I strongly recommend visiting Mark's team webpage (358). The testing they've been doing is really above and beyond:

http://www.team358.org/files/programming/ControlSystem2015-2019/

Tom Line

15-09-2014, 18:23

Jared

15-09-2014, 20:42

On the roboRIO, loose PWM's are our biggest complaint. We've already resorted to hot glue.

But hot glue was not legal under the 2014 rules with certain inspectors...:(

kstl99

15-09-2014, 21:01

But hot glue was not legal under the 2014 rules with certain inspectors...:(

What rule did they site? I can't think of any.

cgmv123

15-09-2014, 21:20

What rule did they site? I can't think of any.

Search is (http://www.chiefdelphi.com/forums/showthread.php?t=122997) your friend (http://www.chiefdelphi.com/forums/showpost.php?p=1299032&postcount=99).

Tom Line

15-09-2014, 21:39

Yep. Good thing we're not competing right now.

We'll have to think of something else for the competition season if the rule isn't changed. That shouldn't be hard.

kstl99

15-09-2014, 22:21

Michael Hill

15-09-2014, 22:25

Wow, I have read the rules many many times since 2010 and never even considered hotmelt to be an issue even though it is very clear, and I have inspected for the past three years. I do not like hotmelt and it would not be accepted in a real piece of automation equipment but neither would a connector that comes out as easy as the PWMs. I also do not like securing the cables such that they force the connectors to stay on as it is not good for the thin conductors.

Looks like a good mechanical guy will just have to create something to lock them into the various devices where they are used....

Not to beat a dead horse, but I've seen/heard of hot snot/melt/glue used in nearly every industry, including aerospace. The only reason NASA doesn't use it is because it wouldn't pass degassing. If it weren't for the need to travel in space, you bet they would use it.

kstl99

15-09-2014, 22:31

Not to beat a dead horse, but I've seen/heard of hot snot/melt/glue used in nearly every industry, including aerospace. The only reason NASA doesn't use it is because it wouldn't pass degassing. If it weren't for the need to travel in space, you bet they would use it.

But there are so many locking connectors on the market. Components do fail and I want to be able to unplug a cable without having to cut through glue and not have to worry about it loosening up.

AdamHeard

15-09-2014, 22:38

But there are so many locking connectors on the market. Components do fail and I want to be able to unplug a cable without having to cut through glue and not have to worry about it loosening up.

Low temp hot glue is very easy to remove w/o issue.

You also can't modify COTS electrical components in FIRST to include a locking connector unfortunately, so that's not an option.

kstl99

15-09-2014, 23:03

I was thinking more of a sort of clip that would sit between the device and the board it is mounted on that would bend around and lock the connector in place. The clip part would be like the clip on the digital side car.

FrankJ

16-09-2014, 12:01

You can wire tie the pwm cable to the chassis close to the plug. You can make a bracket like this (http://www.thingiverse.com/thing:174063). I am not sure which team to credit for this.

kstl99

16-09-2014, 13:58

You can wire tie the pwm cable to the chassis close to the plug. You can make a bracket like this (http://www.thingiverse.com/thing:174063). I am not sure which team to credit for this.

The bracket is exactly what I meant. Positive locking of the connector without stressing the wires.

Mark McLeod

19-09-2014, 23:41

Not sure what stage you're at in the test right now, but I think many people would be interested in data regarding compressor current draw vs. time and pressure, if you can fit it in. EDIT: I should clarify: since this will depend a lot on the exact compressor model, maybe compare it to the current draw when running off a spike using pre-2015 control logic (hard starts), so we can see how the PCM manages the current draw.

There's no difference in the performance of a compressor under the old control system vs. the new control system.
The only difference between systems is how they react to problems.
If the compressor is too large and tries to pull too much current for too long, the old system would trip a self-resetting breaker for longer and longer periods as it heated up, while the new system would react much faster and immediately cut power for a second, try again, cut power, etc.

Here's a plot of the current draw of an old KOP Thomas compressor filling one storage tank. There is a momentary spike when the motor is starting (locked rotor) of ~36a for a fraction of a second, then it drops way down before starting a climb as the pressure in the tank increases.

A ViAir 90C compressor draws much less current, but takes longer to fill the same small volume. The difference is more noticeable with more storage tanks.

This test was done with the new control system on an older robot that didn't have a pressure transducer to record the corresponding pressure. The same test on an older control system looks identical. Somewhere I've got time vs pressure graphs from tests we ran for these two models- here's a post comparing them (http://www.chiefdelphi.com/forums/showpost.php?p=1239286&postcount=11).

Caleb Sykes

20-09-2014, 01:36

Will it be possible to override the logic that controls the compressor via CAN? I have been seeing many teams suggesting that it can be beneficial to cut power to the compressor during a pushing match, which would not be an option this year if the code has no control over this.

Gdeaver

20-09-2014, 07:40

Being able to control the on off of the compressor is important for power management. Is this ability present in the software?

Mark McLeod

20-09-2014, 07:48

Yes, we have the same control over enabling/disabling the compressor from user code as we did before.
We can check just it's status to see if it is currently on or not as well.

The only difference there that I can think of is that teams cannot bypass or ignore the pressure switch cutoff in user code any longer.
They have to use the given functions for compressor control that have always been there.
So user code cannot drive the compressor past the FRC legal limits, but it can shut it off whenever it wants.

marshall

23-09-2014, 11:30

On the roboRIO, loose PWM's are our biggest complaint. We've already resorted to hot glue.

Tom, can I ask what your team is doing that is resulting in loose PWM cables? Do you do any sort of cable management or strain relief with zip ties? Could you post some pictures of your setup?

I ask as a fellow beta team. We haven't seen any issues yet and I'm just trying to figure out if it is something we need to be looking at more in depth than we are. I'm not saying the RoboRIO is perfect on this... I think there is a crap ton of wasted space between the pins where something could have been placed to help with strain relief but that being said, we haven't seen any issues with loose cables yet.

We're off to Rumble in the Roads to compete with the beta robot next week so I'm eager to see if this comes up on the field.

timytamy

27-09-2014, 07:48

Would someone be able to confirm whether or not the VRM/PCM/RoboRIO ports have current monitoring? ie Do the three ports along the bottom of the PDP have current monitoring like the rest of the panel?

Also it would be good to know a little more detail about said current monitoring, things like resolution, accuracy, sample rate etc. Would someone be able to comment?

It would be interesting if the current measurement was good enough to integrate and sum the currents to be able to have a proper measure of battery charge, although this relies on accuratly knowing the state of charge at the beginning of the match.

Mark McLeod

27-09-2014, 08:51

The PDP does not monitor those dedicated power outputs directly.
The PDP does monitor:
The current outputs of each (16) of the high power draw wago connectors
Short circuits detected on each of the (16) wago connectors
The incoming battery voltage
The internal PDP temperature
Any over-temperature faultThe PCM monitors compressor current, and faults for shorts and compressor over-current.

Resolution of the current monitoring is displayed to two decimal places, but we haven't independently verified the accuracy yet.
Haven't seen any specs for the sample rate or other internal details. Probably because the documents are still being written.

Ether

27-09-2014, 09:12

It would be interesting if the current measurement was good enough to integrate and sum the currents to be able to have a proper measure of battery charge

The integral of 60 amps for 2 minutes would be the same as 2 amps for one hour. Would the effect on battery charge be the same?

Michael Hill

27-09-2014, 09:25

The integral of 60 amps for 2 minutes would be the same as 2 amps for one hour. Would the effect on battery charge be the same?

As far as coulomb counting goes, I would think so, but for it to be useful, you'd really have to know the state of charge of the battery before it was put into the robot, which is a non-trivial task.

Joe Ross

27-09-2014, 09:34

As far as coulomb counting goes, I would think so, but for it to be useful, you'd really have to know the state of charge of the battery before it was put into the robot, which is a non-trivial task.

I'd recommend looking at a battery data sheet before trying this, even if you know that a battery is fully charged.

timytamy

27-09-2014, 11:09

The integral of 60 amps for 2 minutes would be the same as 2 amps for one hour. Would the effect on battery charge be the same?

At 60 amps you would get more losses through heat/resistance (P = I^2*R), including losses to the internal resistance of the battery? However the PDP will only let us get a measurement on the power being used by the robot, not the losses of the battery's internal resistance and it's cabling. ie the charge will be the same iff heat losses are zero. Whether this will be anything more than negligable however, I don't know.

Is it possible to get a good idea of the battery's initial condition from measuring it's voltage and internal resistance? If not what other information would you need? I know the battery beak does this and gives a percentage, but how accurate is this? Potentially you could have a system where you plug in a battery, measure it's characteristics before the match start and then do the intergral throughout the match to get the state of charge. This assumes that the power draw by the RoboRIO/PCM/VRM can be assumed constant or estimated accurately.

Finally what would you use this for? I'm not sure but it's 1am here and I'm bored and speculative :)

Jared

27-09-2014, 14:59

Aren Siekmeier

28-09-2014, 07:38

What (I think) Ether is trying to say is that the result of drawing 300 amps for 1 second and drawing 1 amp for 300 seconds will be equal to the same charge, but the effect on the battery's state of charge will be drastically different.

That said, it would be pretty cool to see how much power the robot uses over the course of an entire match.

Who says you're integrating current? You could easily integrate a function of current to get a much better model of battery state. But this requires a theoretical model.

However, the sampling rate will introduce some pretty significant integral error that stacks up over time.

wireties

29-09-2014, 00:31

On the roboRIO, loose PWM's are our biggest complaint. We've already resorted to hot glue.

We are laying out a board to pass all the signals to latching connectors. It will be completely passive but FIRST will still have to approve it - not sure if we can get it done in time. We are thinking of adding a second active circuit using common Arduino components, maybe a nav6 or something similar.

Ether

29-09-2014, 12:50

You could easily integrate a function of current to get a much better model of battery state.

What easy function did you have in mind?

Joe Ross

29-09-2014, 12:54

On the roboRIO, loose PWM's are our biggest complaint. We've already resorted to hot glue.

We just ran through 2 days of competition with the roboRIO, and did not have a single loose PWM cable. We did not do any type of cable retention or strain relief. I have not looked at which cables we specifically used, but our stock of PWM cables are a mixture of AndyMark, IFI, locally sourced servo cables, and cables ordered from deal extreme.

Joe Ross

29-09-2014, 12:58

We are laying out a board to pass all the signals to latching connectors. It will be completely passive but FIRST will still have to approve it - not sure if we can get it done in time.

I'm not sure I understand this statement. FIRST does not need to approve a passive MXP board by the November deadline. It will be approved at inspection, when you prove to the inspector that it is passive.

AdamHeard

29-09-2014, 13:00

FrankJ

29-09-2014, 14:24

I'm not sure I understand this statement. FIRST does not need to approve a passive MXP board by the November deadline. It will be approved at inspection, when you prove to the inspector that it is passive.

Maybe he is talking about the PWM connectors not on the MPX plug. The preliminary rule on the blog does not cover the non-MPX pins. Picky distinction I know, but I have seen worse.

AdamHeard

29-09-2014, 14:28

Maybe he is talking about the PWM connectors not on the MPX plug. The preliminary rule on the blog does not cover the non-MPX pins. Picky distinction I know, but I have seen worse.

If that's the case then I would say no rule covers it, and it is therefore legal.

Any board that interfaced w/ the PWM outputs would be a glorified connector. This is assuming it is all signal pass through, with no active components.

If this is considered illegal, we're entering a realm of craziness by dictating to teams exactly how they are to interface in terms of connectors that have no affect on signal.

Joe Ross

29-09-2014, 15:31

Have you been happy with the cables from deal extreme?

Yes, no problems. The only negative is you have to remove the shroud around the male pins, but that is very easy.

Aren Siekmeier

29-09-2014, 20:45

What easy function did you have in mind?

I don't, one would have to find a suitable model, for example one that is consistent with your statement about 60A for a minute vs 1A for an hour.

I'm just saying that once you have such a function, it's just as easy to numerically integrate that as it is the current itself.

Ether

29-09-2014, 21:38

You could easily integrate a function of current...

Let S be the state-of-charge.

Your statement is equivalent to saying that

dS/dt = f(I)

But how do you know that the rate of change of state-of-charge at a given instant in time depends only on the instantaneous current at that time?

For example, how do you know that dS/dt is a function of I only, and not, say, a function of both I and S: dS/dt = h(I,S) ?

This would make an interesting pre-season project.

wireties

29-09-2014, 22:08

I'm not sure I understand this statement. FIRST does not need to approve a passive MXP board by the November deadline. It will be approved at inspection, when you prove to the inspector that it is passive.

Strictly speaking, it is not just an MXP board. This will connect to all the digital and analog I/O pins. And FIRST will not allow that without approving the design. Make sense?

wireties

29-09-2014, 22:13

Maybe he is talking about the PWM connectors not on the MPX plug. The preliminary rule on the blog does not cover the non-MPX pins. Picky distinction I know, but I have seen worse.

Exactly, but not everything - just the MXP, DIO, AIO, PWM, I2C, RSL, RS232 and relay pins.

If I can get it approved, do you CDers think people might buy it?

TIA

wireties

29-09-2014, 22:14

If that's the case then I would say no rule covers it, and it is therefore legal.

I hope so! But I'm gonna run it by FIRST to make sure. They want 5 of the boards for some reason - crazy. I'm hoping to get a couple betas to try it and send a single unit to FIRST.

wireties

29-09-2014, 22:17

We just ran through 2 days of competition with the roboRIO, and did not have a single loose PWM cable. We did not do any type of cable retention or strain relief. I have not looked at which cables we specifically used, but our stock of PWM cables are a mixture of AndyMark, IFI, locally sourced servo cables, and cables ordered from deal extreme.

That is great news! But I can't get the memories of the old IFI boards out of my head - they were a constant headache. To be honest, my OCD is probably kicking in a bit - the idea of unsecured connectors keeps me up at night (we make navigation equipment for the Navy).

AdamHeard

29-09-2014, 22:18

I hope so! But I'm gonna run it by FIRST to make sure. They want 5 of the boards for some reason - crazy. I'm hoping to get a couple betas to try it and send a single unit to FIRST.

I must be missing something, where does it say passive connections need to get approved?

If I make a 27" long PWM cable custom, doesn't that therefore need approval?

wireties

29-09-2014, 22:33

I must be missing something, where does it say passive connections need to get approved?

If I make a 27" long PWM cable custom, doesn't that therefore need approval?

I agree with you - just trying to be thorough. We are thinking that anything not in a MXP form factor will get special attention. Proving that is is passive during inspection would be a big hassle (possibly removing board so inspector can see the solder side etc).

Caleb Sykes

29-09-2014, 22:44

Let S be the state-of-charge.

Your statement is equivalent to saying that

dS/dt = f(I)

But how do you know that the rate of change of state-of-charge at a given instant in time depends only on the instantaneous current at that time?

For example, how do you know that dS/dt is a function of I only, and not, say, a function of both I and S: dS/dt = h(I,S) ?

This would make an interesting pre-season project.

What is the definition of state of charge?

I know that a "fully charged" battery should have 100% charge, but what is the criterion for a battery to be 0% charged? Would it be a terminal voltage of zero? For a given battery, is S a function of terminal voltage alone?

Ether

29-09-2014, 22:57

What is the definition of state of charge?

I will re-direct your question to "timytamy":

It would be interesting if the current measurement was good enough to integrate and sum the currents to be able to have a proper measure of battery charge, although this relies on accuratly knowing the state of charge at the beginning of the match.

timytamy

30-09-2014, 10:44

What is the definition of state of charge?

Interesting question, I'm hoping someone more qualified will step in but I'll try anyway.

The easiest answer is that 100% of charge is when 204Wh (12V*17Ah) of energy can be drawn from the battery, and 0% is when 204Wh has been drawn. This of course requires a few assumptions, such as we ignore any aging affects and the battery is able to push reasonably large currents at near 12V (say 10.5V and above).

Maybe a more useful answer is that 100% corresponds to what a useful charger will say is charged, and 0% is the point at which most robots will no longer completely function (ie have difficulty driving/turning). Perhaps you could go one further and say 0% is when non-motor electronics start failing (such as the RoboRIO or the VRM) and have another point, say 10% which is when robots stop turning. ie 0% is when the robot can no longer "idle". This one would require characterising some batteries in that you would need to find an amount of energy that you could draw before reaching this point.

An even simpler answer is that state of charge is just what a battery analyser such as the Battery Beak or the CBA will say. Does anyone know how the Battery Beak works out what it's state of charge is?

Unless we can get an answer on how the CBA/Battery Beak defines state of charge, I'd suggest we go with the 0% - idle, 10% - motors, 100% - off chargers model for this discussion. Of course I'd be happy to be corrected by someone with a better understanding of lead acid batteries.

Caleb Sykes

30-09-2014, 18:03

Interesting question, I'm hoping someone more qualified will step in but I'll try anyway.

The easiest answer is that 100% of charge is when 204Wh (12V*17Ah) of energy can be drawn from the battery, and 0% is when 204Wh has been drawn. This of course requires a few assumptions, such as we ignore any aging affects and the battery is able to push reasonably large currents at near 12V (say 10.5V and above).

It seems that you are saying that state of charge has no formal definition, but rather that it is defined uniquely for each system to provide a useful value representing the state of a system. Would you agree with that?

Maybe a more useful answer is that 100% corresponds to what a useful charger will say is charged, and 0% is the point at which most robots will no longer completely function (ie have difficulty driving/turning). Perhaps you could go one further and say 0% is when non-motor electronics start failing (such as the RoboRIO or the VRM) and have another point, say 10% which is when robots stop turning. ie 0% is when the robot can no longer "idle". This one would require characterising some batteries in that you would need to find an amount of energy that you could draw before reaching this point.

If we are defining S for FRC batteries ourselves, then I would suggest the relationship S = Eavailable/Emax where Emax is the difference in energy of the battery between the state that some standard charger says "fully charged" and some standard 0 energy value E0, such as the energy at which non-motor electronics on the robot start to fail. If we just define these two points, the relationship between S and E is linear, but if we also try to define a third point (such as the point at which motors start failing), we will not generally be able to use a linear relationship to describe S in terms of E.

An even simpler answer is that state of charge is just what a battery analyser such as the Battery Beak or the CBA will say. Does anyone know how the Battery Beak works out what it's state of charge is?

Unless we can get an answer on how the CBA/Battery Beak defines state of charge, I'd suggest we go with the 0% - idle, 10% - motors, 100% - off chargers model for this discussion. Of course I'd be happy to be corrected by someone with a better understanding of lead acid batteries.

I too would be interested to learn how the battery beak defines state of charge. If the beak says 78% charged, does that tell me anything quantitative about the battery or does it just mean I should leave it on the charger longer before using it in a match?

SteveGarward

02-10-2014, 22:17

On the roboRIO, loose PWM's are our biggest complaint. We've already resorted to hot glue.

We also had issues with cables coming off easily, both bought pre-made cables, and ones we make ourselves. Older, well used cables were especially an issue.

I was thinking more of a sort of clip that would sit between the device and the board it is mounted on that would bend around and lock the connector in place. The clip part would be like the clip on the digital side car.

We've been working on a part to be 3D printed that would (hopefully) help with cables coming off, and also the large space between the pins. We've just published a blog post about it here (http://wildstang.org/blog/?p=225). We are still iterating over the design. But, you'll get the idea of where we're headed.

Jared

03-10-2014, 17:01

It seems that you are saying that state of charge has no formal definition, but rather that it is defined uniquely for each system to provide a useful value representing the state of a system. Would you agree with that?

If we are defining S for FRC batteries ourselves, then I would suggest the relationship S = Eavailable/Emax where Emax is the difference in energy of the battery between the state that some standard charger says "fully charged" and some standard 0 energy value E0, such as the energy at which non-motor electronics on the robot start to fail. If we just define these two points, the relationship between S and E is linear, but if we also try to define a third point (such as the point at which motors start failing), we will not generally be able to use a linear relationship to describe S in terms of E.

I still don't see this working well for what you're trying to accomplish. Your value of "E available" is not really quantifiable for the battery. If you read the datasheet (http://www.mkbattery.com/images/ES17-12.pdf), you'll see that the battery's capacity (which affects E_available) varies greatly with current draw.

Basically, this means that your effective energy consumed is proportional not only to the energy you're actually using, but the rate at which you're using this energy (or some weird function of the rate).

Assume that we can estimate state of charge in a battery by timing how long it takes a 10 amp load to cause the battery voltage to drop below 10 volts.

If we play one match where we draw 43,200 joules (12 amp hour volts, or 1 amp hour for our battery), and we run the test on the battery, we may see that the battery can power the 10 amp load for 15 minutes before dropping below 10 volts.

We may then completely charge the battery, and play another match where we also draw 43,200 joules (again, 1 amp hour for our battery), but the load test will cause the voltage to drop below 10 volts after only 2 minutes.

Our integration of current over time gives the same result both times, but in the second match, we ended up depleting a larger portion of the batteries capacity because we used our energy in short, high power, fast spikes, rather than a slow steady draw in the first match.

It would be interesting to see if a function for effective energy used (out of the rated 18 amp hours) could be used if we took into account both the current and the integral of the current with respect to time.

Also, does anybody have specifications for the new PDB's current sensing (latency, resolution, sampling rate, maximum current)?

Mr V

03-10-2014, 18:01

There are two common methods of determining the SOC of a lead acid battery. The most accurate is to measure the specific gravity of the electrolyte, unfortunately with a sealed AGM battery that is not possible. The other method is the resting voltage, that means a battery that has not recently been charged or had a load applied to it. The definition of recently varies depending on who you ask. Some say as little as 15min while others say it should be 24hrs. Most do agree on a fairly narrow range of around 11.8v as a 0% SOC. I'm pretty certain that the battery beak determines the SOC based on voltage particularly since the instructions I saw stated the battery needed to be "at rest" for an accurate reading.

Joe Ross

05-10-2014, 23:11

Also, does anybody have specifications for the new PDB's current sensing (latency, resolution, sampling rate, maximum current)?

Sample rate is 40hz, resolution is 1/8 amp. Latency seems to be less then then the sample rate, we compared it to an analog current sensor we used last year and didn't see any unexpected latency. I haven't seen any specs on max current, but it measured 60+ amps per channel on our drivetrain.

I've attached data we collected from the PDP during a match at the SCRRF Fall Classic. Note that each channel has a small steady state error, which will be calibrated out in a later firmware update.

marshall

06-10-2014, 16:48

Tom, can I ask what your team is doing that is resulting in loose PWM cables? Do you do any sort of cable management or strain relief with zip ties? Could you post some pictures of your setup?

I ask as a fellow beta team. We haven't seen any issues yet and I'm just trying to figure out if it is something we need to be looking at more in depth than we are. I'm not saying the RoboRIO is perfect on this... I think there is a crap ton of wasted space between the pins where something could have been placed to help with strain relief but that being said, we haven't seen any issues with loose cables yet.

We're off to Rumble in the Roads to compete with the beta robot next week so I'm eager to see if this comes up on the field.

Well, I can safely say that we did not see any issues with loose PWM connectors at Rumble in the Roads. We had some hard defense played on us too and we got into some real pushing matches. One of them bent a bolt on the robot and the other ripped off our green LED ring lights. Hard stuff. I was happy with the performance of the RoboRIO though and we didn't have any loose PWM or sensor cables. We aren't doing anything special to tie them down or apply strain relief to them.

Caleb Sykes

06-10-2014, 16:51

I still don't see this working well for what you're trying to accomplish. Your value of "E available" is not really quantifiable for the battery. If you read the datasheet (http://www.mkbattery.com/images/ES17-12.pdf), you'll see that the battery's capacity (which affects E_available) varies greatly with current draw.

Basically, this means that your effective energy consumed is proportional not only to the energy you're actually using, but the rate at which you're using this energy (or some weird function of the rate).

I guess I still don't fully understand why we wouldn't be able to easily calculate Eavailable assuming we account for the internal resistance of the battery. We should be able to integrate the power over time to get the energy. Something like Eavailable(t) = Emax-(time integral of (V(t')*I(t') + I(t')^2*Rinternal) from t'=0 through t'=t) where V(t) is the terminal voltage of the battery at time t, I(t) is the current supplied by the battery at time t, and Rinternal is the internal resistance of the battery.

This should be all we need to calculate Eavailable, since the initial energy of the battery either has to turn into electric energy that moves through the circuit or turn into heat due to the internal resistance of the battery. I don't see anywhere else that the energy of the battery can go. The only thing I might not be considering here would be that Rinternal might not be a constant, but a function of current and/or temperature. Does anyone know if this is the case? Because if so, that could explain why the battery loses charge more quickly than expected at higher currents.

Jared

07-10-2014, 18:16

I guess I still don't fully understand why we wouldn't be able to easily calculate Eavailable assuming we account for the internal resistance of the battery. We should be able to integrate the power over time to get the energy. Something like Eavailable(t) = Emax-(time integral of (V(t')*I(t') + I(t')^2*Rinternal) from t'=0 through t'=t) where V(t) is the terminal voltage of the battery at time t, I(t) is the current supplied by the battery at time t, and Rinternal is the internal resistance of the battery.

This should be all we need to calculate Eavailable, since the initial energy of the battery either has to turn into electric energy that moves through the circuit or turn into heat due to the internal resistance of the battery. I don't see anywhere else that the energy of the battery can go. The only thing I might not be considering here would be that Rinternal might not be a constant, but a function of current and/or temperature. Does anyone know if this is the case? Because if so, that could explain why the battery loses charge more quickly than expected at higher currents.

Check out the datasheet. The capacity of the battery is much different when the current is different. The battery is rated for 18 amp hours, which it can achieve when used in low current situations, but when used in FRC situations, the capacity is likely closer to 7 amp hours.

I don't know exactly why this is true, but I'd be willing to bet that the chemical reaction isn't quite as effective/efficient when it happens really quickly.

Caleb Sykes

07-10-2014, 18:34

Check out the datasheet. The capacity of the battery is much different when the current is different. The battery is rated for 18 amp hours, which it can achieve when used in low current situations, but when used in FRC situations, the capacity is likely closer to 7 amp hours.

I don't know exactly why this is true, but I'd be willing to bet that the chemical reaction isn't quite as effective/efficient when it happens really quickly.

I have looked at the datasheet, and I can see that the capacity is different, but I can't think of a good reason for this besides internal resistance of the battery. A fully charged battery has some energy associated with it, and a discharged battery has some energy associated with it. No matter how you get from this charged state to the discharged state, the energy change must be the same, correct? As far as I can tell, this energy can only turn into either heat or electrical energy.

magnets

07-10-2014, 18:59

I have looked at the datasheet, and I can see that the capacity is different, but I can't think of a good reason for this besides internal resistance of the battery. A fully charged battery has some energy associated with it, and a discharged battery has some energy associated with it. No matter how you get from this charged state to the discharged state, the energy change must be the same, correct? As far as I can tell, this energy can only turn into either heat or electrical energy.

You are correct. When the battery goes from charged to discharged slowly, most of the energy is released as electricity, and a small part is released as heat. When the battery is discharged quickly, a much larger part is released as heat.

Ether

07-10-2014, 19:56

FrankJ

08-10-2014, 09:24

Remember that the battery resistance is a simplistic model of complex chemical reactions in the battery. It is a measure of the battery to pass current, not necessarily the number of electrons in the battery.

controls weenie

09-10-2014, 06:35

Gdeaver

09-10-2014, 07:24

Mr. Ross,
That spread sheet is exactly what our team wants to study and implement power management. Can you detail the programming set up to capture that data?

Greg McKaskle

09-10-2014, 07:50

I haven't seen Joe's code, but I suspect they are reading the power API at about 25ms and storing the results in their on file. This level of logging along with events where the PDP saw a breaker trip should soon be built in, though you are always welcome to write your own.

Greg McKaskle

Joe Ross

09-10-2014, 08:17

Mr. Ross,
That spread sheet is exactly what our team wants to study and implement power management. Can you detail the programming set up to capture that data?

Here is the code that read the data into a 2d array (for buffering) in telopPeriodic and disabledPeriodic (java). The code to handle the buffering and writing the file periodically and handling exceptions was more code then reading the data from the pdp.

for (int i=0; i<16; i++) {
pdpArray[pdpLine][i] = pdp.getCurrent(i);
}
pdpArray[pdpLine][16] = pdp.getVoltage();
pdpArray[pdpLine][17] = pdp.getTemperature();

Mark McLeod

09-10-2014, 09:56

Has anyone put the PWM signals on an oscope? I assume the PWM signal is still 5v max but will it change to 3.3v if the internal jumper is set to 3.3v. I also noticed that there is no jumper on the roborio to pass 6v to the center PWM conductor. The crio had this jumper. Can someone take a measurement and let me know these two voltages?

The 3.3v/5v internal jumper only affects the DIO power output.
The PWM signals are always 5v max.
The PWM power is always 6v. The motor controllers have this line disconnected, so power on it doesn't affect them.

Ether

09-10-2014, 10:04

It is a measure of the battery to pass current, not necessarily the number of electrons in the battery.

@Frank: You seem to be implying that the number of electrons in the battery changes as the battery supplies current. Was that your intent?

Ether

09-10-2014, 10:08

The PWM signals are always 5v max.

What about the output impedance of the PWM 5v? Has anyone measured that? Or, is it specified somewhere?

Also, has anyone collected millamps vs voltage drop data across the input of the new motor controllers?

Aren Siekmeier

09-10-2014, 10:50

The 3.3v/5v internal jumper only affects the DIO power output.
The PWM signals are always 5v max.
The PWM power is always 6v. The motor controllers have this line disconnected, so power on it doesn't affect them.

I was wondering today about how exactly all the signals are pulled up/down.

I've seen in the myRIO docs that all the DIO pins are pulled up to 3.3V with a 40k (or 2k for the shared I2C pins).

Are the main PWM pins pulled down to ground like they were 09-14? How strong/weak is the pull down?

And most importantly, if main PWMs are pulled down and all DIOs are pulled up, what is the roboRIO doing with the shared PWM pins on the MXP breakout?

FrankJ

09-10-2014, 11:06

@Frank: You seem to be implying that the number of electrons in the battery changes as the battery supplies current. Was that your intent?

I was being a little bit tongue & cheek since the number of electrons in the battery really doesn't change with the state charge or current. It mostly related to the number of protons in the battery. :]

My real point was internal resistance is really a measure of the batteries ability to supply current under particular set of conditions. It says nothing about the actual efficiency of the chemical reactions going on in the battery. Others, who know a lot more than I do about batteries, have posted in effect that the amount of useful energy in the battery changes with the current or power. That matches my experience.

controls weenie

09-10-2014, 11:10

It appears that the MXP interface on the new RoboRio is only redundant connections from the outer edge RoboRIO connectors. If they are redundant, then why would anyone use this interface?

Thanks

Mark McLeod

09-10-2014, 11:17

They are not redundant, they are additional.

Greg McKaskle

09-10-2014, 11:25

It appears that the MXP interface ...

What lead you to that conclusion?

The MXP adds to the outer-edge I/O. Internally, there are two MXP buses, one is exposed via the MXP connector and the other was used to construct the outer-edge connectors.

If some of the documentation is misleading, please point it out.

Greg McKaskle

Ether

09-10-2014, 12:06

Using a simple model of the battery as a fixed internal resistance of 0.011 ohms in series with a constant 12.7v voltage source...

I was hoping someone well-versed in lead-acid battery chemistry and thermodynamics would please comment on whether or not computing I2R losses with the above model is a useful (i.e. approximately correct) way to illustrate the observed phenomenon that energy delivery efficiency is substantially reduced at higher power levels.

Caleb Sykes

09-10-2014, 12:11

I was hoping someone well-versed in lead-acid battery chemistry and thermodynamics would please comment on whether or not computing I2R losses with the above model is a useful (i.e. approximately correct) way to illustrate the observed phenomenon that energy delivery efficiency is substantially reduced at higher power levels.

I'm hoping this as well.

controls weenie

09-10-2014, 13:38

Here is my justification for assuming the MXP pins are redundant. Maybe I should use a better explanation instead of the word redundant.

How many ways are there to access I2C SDA? We can use the MXP pin 34 and the outer area of the RoboRIO connector labeled I2C SDA. Are these the traces the same? Are there really two independent I2C interfaces?

Where is the signal DIO0-9 accessed? MXP contains DIO0-9. There are also DIO0-9 on the outer edge of the RoboRIO. Are there two separate DIO0 signals? A and B ?

Greg mentioned that these are different buses. Does that mean the processor/FPGA can really control two I2C interfaces at the same time? I am not sure what he means by different buses. I thought two separate buses means that the FPGA controls the I2C-A and I2C-B independently.

Maybe some pins are redundant (:D) and some are extra.

Sorry for the confusion.
Thanks

SteveGarward

09-10-2014, 13:47

As it says on the specs here (https://decibel.ni.com/content/servlet/JiveServlet/download/30419-54-79765/roboRIO+Overview.pdf):

I2C: 2 channels (1 dedicated, 1 shared)
<many other similar examples>

So 1 channel is available on the roboRIO, and is a dedicated I2C bus. There is also another on the MXP, which is a separate bus, but it's pins may be used as Digital I/O instead, if you want to. Not D I/O and I2C at the same time. But, there are two I2C channels.

The MXP is an expansion port, not just a move-all-the-onboard-IO-somewhere-else port.

controls weenie

09-10-2014, 14:05

>> It appears that the MXP interface ...

OK. I understand, now. The MXP is a powerful interface. Our team should be able to come up with many uses for this interface.

Thanks for clearing up my confusion.

Mark McLeod

09-10-2014, 14:17

Here's a photo of both SPI interfaces in use at the same time to duplicate devices that have identical SPI address. They worked fine without conflicts.

We did the same thing with the I2C ports, but I only have a photo of one port in use.

controls weenie

10-10-2014, 10:32

>> Has anyone put the PWM signals on an o'scope?

I had a buddy measure the PWM 6V line from the RoboRIO (Our team does not have RoboRIO and it was 5.7 volts with a fresh 12V battery. Does this concern anyone for driving several servo motors? What would happen to the 6V line if there are 6 servos running at the same time?

I measured 6.0V on the older cRio. Is there a current limit on the output of each of these RoboRIO PWM 6V (5.7V;) ) pins? I wanted to make sure I get all the power I need for driving several servos at the same time.

Thanks,

Ether

10-10-2014, 10:37

What about the output impedance of the PWM 5v? Has anyone measured that? Or, is it specified somewhere?

Also, has anyone collected millamps vs voltage drop data across the input of the new motor controllers?

Alternatively, have any of the beta testers experimented with driving multiple (two or even more) motor controllers with one PWM.

Mark McLeod

10-10-2014, 10:47

Alternatively, have any of the beta testers experimented with driving multiple (two or even more) motor controllers with one PWM.
We tested driving two Jaguars from a single PWM, but we haven't measured impedance or max current draw of the PWM outputs.

Alan Anderson

10-10-2014, 11:54

Alternatively, have any of the beta testers experimented with driving multiple (two or even more) motor controllers with one PWM.

We did a brain transplant of the 2015 control system into our Aerial Assist practice robot. The drivetrain motors are paired up with one PWM output driving two Talons for each side, and the four flinger motors are similarly controlled in pairs. It's been working great so far.

We have been working around a Driver Station issue introduced in the previous Beta release and haven't yet had a chance to do the brownout and stress testing that's next on our agenda. New Beta files were released this week, so we'll be updating the RoboRIO image on Monday and watching how the system responds to low voltage and high loads. Once we've gathered the information we want, I suppose we could wire up a slew of motor controllers and see how many we can reliably control with a single PWM output.

G_rupp

10-10-2014, 13:55

Alternatively, have any of the beta testers experimented with driving multiple (two or even more) motor controllers with one PWM.

We have been running the robot with 2 Talons and 2 New Victor SP motor controllers with one PWM to each pair. We have not had any issues with this configuration and the Autonomous still drives straight with different controllers on each side.

controls weenie

10-10-2014, 14:52

>> I had a buddy measure the PWM 6V line from the RoboRIO (Our team does not have RoboRIO and it was 5.7 volts with a fresh 12V battery. Does this concern anyone for driving several servo motors? What would happen to the 6V line if there are 6 servos running at the same time?

>> I measured 6.0V on the older cRio. Is there a current limit on the output of each of these RoboRIO PWM 6V (5.7V ) pins? I wanted to make sure I get all the power I need for driving several servos at the same time.
----------------------------------------------------------------------------------

I am more concerned with the servos, not the motors. The servos are going to use the middle conductor's 6V (5.7V). I would like to know the current limit imposed by the RoboRIO designers. The servo power is directly proportional to the current supplied by the RoboRIO. It looks like we are already getting voltages lower than the spec.

FrankJ

10-10-2014, 14:53

While it needs to be tested, you are not really driving any power over the signal line of the PWM to the motor controllers. It is just a signal. I know that is obvious to most of the commenters, maybe less so to others.

As Controls Weenies said, it is more of an issue with the power line of the PWM driving servos & Vex motors.

AdamHeard

10-10-2014, 14:56

Ether

10-10-2014, 15:04

While it needs to be tested, you are not really driving any power over the signal line of the PWM to the motor controllers. It is just a signal.

It's just a signal, but the motor controller inputs do not have infinite impedance. They do suck some power from the signal (to light the LED in the photocoupler).

Have any of the beta teams tried driving three of the new motor controllers with one PWM signal? (three CIM gearbox).

G_rupp

10-10-2014, 15:07

Have any of the beta teams tried driving three of the new motor controllers with one PWM signal? (three CIM gearbox).

Each Beta team only received 2 new motor controllers. We will be at a demo tomorrow with 2 other Beta teams and will see if we can test this.

Mark McLeod

10-10-2014, 15:40

Five Jags is the most we tried (briefly) off of one roboRIO PWM output and didn't have any trouble with that, but we weren't driving any other PWMs at the same time.

controls weenie

10-10-2014, 15:47

Unless it's a servo or Vex motor.

Right....I would like to see the 6V signal when the servos is trying to move a high inertia mass. I am guessing the 6V signal will drop from 5.7 to below 5.0 :( when there is a load on the servo. Can some of you RoboRIO owners try that ? We are designing a PWM extender (for servos and motors) that needs the 6V supply to stay above 5.3V.

Thanks,

Greg McKaskle

10-10-2014, 15:50

I used a DMM to test mine, driven by a weak transformer, and the one on our test machine which is on a 12.7V fresh battery. Both read between 5.93 and 5.97 V.

I believe the center pin is driven by a dedicated supply that limits current to 2.2A. There is not a limit for a given PWM, but for the rail.

The PWM signals from the MXP will need to provide their own power for a servo.

I'm curious to hear what others measure.

Greg McKaskle

jhersh

10-10-2014, 16:27

Right....I would like to see the 6V signal when the servos is trying to move a high inertia mass. I am guessing the 6V signal will drop from 5.7 to below 5.0 :( when there is a load on the servo. Can some of you RoboRIO owners try that ? We are designing a PWM extender (for servos and motors) that needs the 6V supply to stay above 5.3V.

Thanks,

Fear not. This is an artifact of the back-drive protection on this supply. The current path passes through a diode when the load is low. When the current is detected to be enough greater than 0, a FET is switched on and the diode is bypassed. This means that at no load the output looks low, but as soon as there is a load, the voltage climbs to 6V.

Please see the attached image. This is a graph created using the new Power palette in WPILib (that's right, you can monitor this directly in the controller without external connections). I plugged in a servo, enabled, and then twisted the output shaft with my hand, forcing it to fight me and increase load on the power supply. You can see that under load the voltage increases, not decreases.

Alan Anderson

10-10-2014, 16:33

Fear not. This is an artifact of the back-drive protection on this supply. The current path passes through a diode when the load is low. When the current is detected to be enough greater than 0, a FET is switched on and the diode is bypassed. This means that at no load the output looks low, but as soon as there is a load, the voltage climbs to 6V.

That's good information to have.

For teams that just want to use the system as a black box and care little about the details inside it, the engineering of this power supply is great. It's the teams that put a lot of effort into understanding and analyzing that could get tripped up without having a good low-level description of how it works.

FrankJ

10-10-2014, 16:34

Unless it's a servo or Vex motor.
Don't they pull power from the power line not the signal line? That is why you have to jumper the power on the digital sidecar for servo & not motor controllers.

jhersh

10-10-2014, 16:41

Don't they pull power from the power line not the signal line? That is why you have to jumper the power on the digital sidecar for servo & not motor controllers.

You are correct, Frank. The servos and VEX motors should not draw a significant amount of current from the PWM signal pins. I would actually expect them to be a bit lower than the other motor controllers since they are not isolated, but I have not measured them.

jhersh

10-10-2014, 16:43

That's good information to have.

For teams that just want to use the system as a black box and care little about the details inside it, the engineering of this power supply is great. It's the teams that put a lot of effort into understanding and analyzing that could get tripped up without having a good low-level description of how it works.

Are you suggesting this should be included in some documentation somewhere? If so, please file a tracker to Kevin.

SteveGarward

10-10-2014, 16:46

The PWM signals from the MXP will need to provide their own power for a servo.

Everyone needs to be careful on this one. According to the answer to my question here on the FIRST forums (http://forums.usfirst.org/showthread.php?23689-Active-or-passive-MXP-board), once you add (separate) power to PWM signals from the MXP, you have an ACTIVE DEVICE.

FrankJ

10-10-2014, 16:59

Everyone needs to be careful on this one. According to the answer to my question here on the FIRST forums (http://forums.usfirst.org/showthread.php?23689-Active-or-passive-MXP-board), once you add (separate) power to PWM signals from the MXP, you have an ACTIVE DEVICE.

That seems to be a poorly considered response. (Recognizing that if First stays with it, that will be the rule.) The control comes over the signal pin. So where the power comes from for the power line is immaterial from a control stand point. The MXP doesn't have a dedicated power pin for each PWM. The Vex motor pulls a lot of current at stall. One reason we stayed away from them in the past.

The motor controller are pulling their power straight from the PD board. Not much different conceptually than using a separate power supply for a servo

SteveGarward

10-10-2014, 17:36

That seems to be a poorly considered response. (Recognizing that if First stays with it, that will be the rule.) The control comes over the signal pin. So where the power comes from for the power line is immaterial from a control stand point. The MXP doesn't have a dedicated power pin for each PWM. The Vex motor pulls a lot of current at stall. One reason we stayed away from them in the past.

The motor controller are pulling their power straight from the PD board. Not much different conceptually than using a separate power supply for a servo

Agreed. The only difference I can see is that the PD is a known, tested, approved power source. My best guess is that an unknown (to FIRST), untested (by FIRST) power source powering servos (to make robot parts move) may be considered unsafe, or at least a risk. This would go for anything on a board - power, other circuitry. Thus the requirement for boards doing more than breaking out pins to be approved.

That's my best guess anyway. Either way, rules may change, but for now they are what they are.

My concern now is for boards that have 'prototyping' area on it - while the board may be passive, does adding components/circuits make it active? Burden of proof at inspection to show it's just sensors etc., or that PWM pins are not controlling anything? Not sure how that will play out yet.

billbo911

10-10-2014, 19:08

Until we hear otherwise on the power supply added to the PWM pins from the MXP port issue, would it be safe to say:

"A really good approach would be to use the MXP port PWM pins to drive motor controllers, and the MXP DIO pins for sensors, that do not get their power over the PWM cable. Use the PWM and DIO on the edge of the RoboRio for all sensors, servo, motors etc that do get their power from the PWM cable."?

Personally I believe FIRST will more than likely approve an expansion board that provides power to these connections that is sourced from the PDB. In the mean time, we need to work with what we have.

Joe Ross

10-10-2014, 21:40

Everyone needs to be careful on this one. According to the answer to my question here on the FIRST forums (http://forums.usfirst.org/showthread.php?23689-Active-or-passive-MXP-board), once you add (separate) power to PWM signals from the MXP, you have an ACTIVE DEVICE.

I think it would be more accurate to say say "once you add an active power supply to PWM signals from the MXP ..."

This does not keep you from supplying 3.3v or 5v from the MXP header or battery voltage from the PDP to the DIO pins, It only keeps you from adding a power supply to add a different voltage.

My concern now is for boards that have 'prototyping' area on it - while the board may be passive, does adding components/circuits make it active? Burden of proof at inspection to show it's just sensors etc., or that PWM pins are not controlling anything? Not sure how that will play out yet.

No matter what board you use, if you claim that it is passive, you'll have to prove it at inspection. Not sure how having a prototyping area changes that. An active circuit added to a prototyping area of an otherwise passive board makes it active.

controls weenie

10-10-2014, 23:47

I wanted to share with you the reason I am asking about the PWM voltages. A few of the kids and I are designing a "PWM Extender" which will attach to the robot and inline with the PWM cable. The "PWM Extender" will be 2.5" x 1.5" PCB with a row of 8 LEDS to indicate the servo (or motor) command. This will allow our team to monitor (or debug) the robot health from in the stands. The "PWM Extender" is parasitic in that it will steal from the 6V supply (middle conductor) to power a ATMEGA88 uController to drive the LEDs as a function of the signal command. There is a 5V voltage regulator.

Our team would like to place as many indicators on the robot so the driver and operator do not have to look down at the laptop. We have noticed that no one ever looks down during the competition.

Yes, it is active but only for the LEDs. We would be glad to share the design, gerber files, uController code, etc with anyone who wants it. But, I have a feeling that most will reject it.

Your thoughts?

SteveGarward

11-10-2014, 19:55

Not sure how having a prototyping area changes that. An active circuit added to a prototyping area of an otherwise passive board makes it active.

From the reply on the FIRST forums, I read that to mean that once any components at all (power or otherwise) are added to the board, and the board is no longer simply a breakout, it is an active board.

Joe Ross

11-10-2014, 20:32

I wanted to share with you the reason I am asking about the PWM voltages. A few of the kids and I are designing a "PWM Extender" which will attach to the robot and inline with the PWM cable. The "PWM Extender" will be 2.5" x 1.5" PCB with a row of 8 LEDS to indicate the servo (or motor) command. This will allow our team to monitor (or debug) the robot health from in the stands. The "PWM Extender" is parasitic in that it will steal from the 6V supply (middle conductor) to power a ATMEGA88 uController to drive the LEDs as a function of the signal command. There is a 5V voltage regulator.

This is definetly active. In addition this would be illegal in any previous year, as a motor controller is not allowed to connect to a custom circuit. It would be legal for you to make a seperate board and have the roboRIO communicate the values it's sending to the motor controllers to the seperate board over another communication method (I2C, SPI, CAN, serial, ethernet, etc).

Given how hard it is to see items on the robot during a match, a better option might be to have either the roboRIO log the data you want to it's internal flash or send the data to the dashboard. Both the LabVIEW dashboard and the SFX dashboard support logging by default.

Joe Ross

11-10-2014, 20:33

From the reply on the FIRST forums, I read that to mean that once any components at all (power or otherwise) are added to the board, and the board is no longer simply a breakout, it is an active board.

Are you interpreting the 4 examples of items that are ok for a passive device as the only 4 items allowed? The definition allows many more things.

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

controls weenie

12-10-2014, 09:34

This is definetly active. In addition this would be illegal in any previous year, as a motor controller is not allowed to connect to a custom circuit. It would be legal for you to make a seperate board and have the roboRIO communicate the values it's sending to the motor controllers to the seperate board over another communication method (I2C, SPI, CAN, serial, ethernet, etc).

Given how hard it is to see items on the robot during a match, a better option might be to have either the roboRIO log the data you want to it's internal flash or send the data to the dashboard. Both the LabVIEW dashboard and the SFX dashboard support logging by default.

Joe, I like your first suggestion to use a serial message to another device (maybe a PCDuino) to display our commands on the robot. We can set a message buffer equal to the motor (and servo) commands then send it to the PCDuino maybe somewhere high for best 'line of sight'. This would also help us debug in the pit.

We do want to try placing the commands on the robot this year with indicators such as colored LEDs. In previous years, we have spent many hours reconfiguring the dashboard but we NEVER look down at it during competition. Even the coach is too busy to look down. This way the entire pit crew in the stands can follow the driver and operator commands to educate them on component failures. This might expedite getting the robot ready for the next match.

controls weenie

14-10-2014, 21:16

Joe Ross

14-10-2014, 21:34

Has anyone seen the specs on the roborio accelerometer? I searched but could not find any information.

It's a 3 axis, selectable +/- 2g, 4g, or 8g. MMA8452Q

Joe Ross

15-10-2014, 20:47

From the reply on the FIRST forums, I read that to mean that once any components at all (power or otherwise) are added to the board, and the board is no longer simply a breakout, it is an active board.

With today's clarification that plugging in an active component to a passive MXP makes the MXP active, I agree with you. But it sounds like they're trying to figure out a workaround.

SteveGarward

15-10-2014, 21:24

With today's clarification that plugging in an active component to a passive MXP makes the MXP active, I agree with you. But it sounds like they're trying to figure out a workaround.

I certainly hope they do - for everyone. That clarification makes the current preliminary rules much more broad that I had anticipated or understood them to be.

controls weenie

15-10-2014, 21:40

I certainly hope they do - for everyone. That clarification makes the current preliminary rules much more broad that I had anticipated or understood them to be.
I have been reading many of these post and I have not understood the benefit of the mxp pcb. All I can see is that it is an exercise in relocating the connector from deep inside the 2x17 male connector. I have several expansion ideas but my thoughts are to connect directly to the 2x17 male connector. I am not seeing the benefit of the expansion board. Moreover, there are no active or passive issues. What am I missing?

RufflesRidge

15-10-2014, 22:18

What am I missing?

That wiring the signal and ground of a 3 pin connector to the signal and ground mixed into the 34 pin connector is a pain. A huge pain if you want to use more than the number of ground pins available.

SteveGarward

15-10-2014, 22:27

I have been reading many of these post and I have not understood the benefit of the mxp pcb. All I can see is that it is an exercise in relocating the connector from deep inside the 2x17 male connector.
Yes and no. It allows you to have easy access to the pins in the MXP, and lay them out in a manner that is easy to use - such as providing ground pins and in a 3-pin arrangement so you can plug in a regular PWM cable. To relocate the connector we just need a cable. You then still have the issue of what you connect to it and how.

I have several expansion ideas but my thoughts are to connect directly to the 2x17 male connector.
You could use a connector with a cable and solder the wires directly to things, for sure. It's just often more inconvenient to do so, depending on what exactly you're trying to do.

I am not seeing the benefit of the expansion board. Moreover, there are no active or passive issues.
The benefit is 'ease of handling'. Given the current preliminary rules/rulings/statements (especially today's response on the forums), I'm not sure where just plugging something straight in (say, an encoder) through wire on a cable/connector would sit on the active/passive fence. But, they are working on it.

GeeTwo

19-01-2015, 16:42

Using a simple model of the battery as a fixed internal resistance of 0.011 ohms in series with a constant 12.7v voltage source, it's straightforward to compare the energy wasted across the internal resistance for the same ampere-hours at different currents.

But it's even worse than that. A close look at the battery discharge curves suggests that the internal resistance is not constant, but rather increases substantially with current.

This is not at all surprising. Most resistors increase in resistance as the temperature goes up, like when they have a lot of current running through them. In addition to the reduction in the battery's reduced capability as reflected on the discharge curves, you are also losing more energy to heat in the wiring and the motors at high draw.

jhersh

20-05-2015, 17:30

Sample rate is 40hz, resolution is 1/8 amp. Latency seems to be less then then the sample rate, we compared it to an analog current sensor we used last year and didn't see any unexpected latency. I haven't seen any specs on max current, but it measured 60+ amps per channel on our drivetrain.

I've attached data we collected from the PDP during a match at the SCRRF Fall Classic. Note that each channel has a small steady state error, which will be calibrated out in a later firmware update.

Hi Joe,

Do you think you have the DS log for this match that you could attach or send to me?

Thanks,
-Joe