Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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.

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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/program...stem2015-2019/

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

Search is your friend.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

You can wire tie the pwm cable to the chassis close to the plug. You can make a bracket like this. I am not sure which team to credit for this.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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 fault

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

Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

What easy function did you have in mind?

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

Have you been happy with the cables from deal extreme?

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

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. We are still iterating over the design. But, you'll get the idea of where we're headed.

Re: 2015 Beta Testing - The Components are Here.
 

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, 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)?

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - PWM voltage levels
 

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?

Thanks

Re: 2015 Beta Testing - The Components are Here.
 

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?

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - PWM voltage levels
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - PWM voltage levels
 

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?

Re: 2015 Beta Testing - PWM voltage levels
 

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 I²C 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?

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

They are not redundant, they are additional.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

I was hoping someone well-versed in lead-acid battery chemistry and thermodynamics would please comment on whether or not computing I²R 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.

Re: 2015 Beta Testing - The Components are Here.
 

I'm hoping this as well.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

As it says on the specs here:

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - PWM voltage levels
 

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

Re: 2015 Beta Testing - PWM voltage levels
 

We tested driving two Jaguars from a single PWM, but we haven't measured impedance or max current draw of the PWM outputs.

Re: 2015 Beta Testing - PWM voltage levels
 

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.

Re: 2015 Beta Testing - PWM voltage levels
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

Unless it's a servo or Vex motor.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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,

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

Everyone needs to be careful on this one. According to the answer to my question here on the FIRST forums, once you add (separate) power to PWM signals from the MXP, you have an ACTIVE DEVICE.

Re: 2015 Beta Testing - The Components are Here.
 

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

Re: 2015 Beta Testing - The Components are Here.
 

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.

Re: 2015 Beta Testing - The Components are Here.
 

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.