2015 Beta Testing - The Components are Here.

[AdamHeard]

Originally Posted by Jon Stratis

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]

Originally Posted by Jon Stratis

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]

Originally Posted by Jon Stratis

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]

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]

Originally Posted by AustinSchuh

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]

Originally Posted by Tom Line

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]

Originally Posted by Jared Russell

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]

Originally Posted by AustinSchuh

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]

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]

Originally Posted by Gdeaver

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.

Originally Posted by Gdeaver

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]

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]

Originally Posted by Gdeaver

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]

Originally Posted by AustinSchuh

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]

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]

Originally Posted by AustinSchuh

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.