Go to Post Ice cream is an iterative process. - JVN [more]
Home
Go Back   Chief Delphi > Technical > Control System > FRC Control System
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
 
 
Thread Tools Rating: Thread Rating: 2 votes, 5.00 average. Display Modes
Prev Previous Post   Next Post Next
  #8   Spotlight this post!  
Unread 14-05-2015, 18:40
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,748
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Brownout behavior - alternative design goals

Quote:
Brain dead, close to criminal, and really dumb?
Well now that we have the emotional venting out of the way, let's see if we can look at this in a more productive way.

1. Why was this feature included?
2. Does it address the targeted issue(s)?
3. Does it introduce new issues?
4. Can it be improved?

---------

1. Why was this feature included?
The brownout feature is intended to cut power to some circuits in order to maintain power to others deemed more critical. There is a limited supply of current, and without this feature you don't have brownouts but instead have blackouts/reboots of devices based on their power supply details.

The critical components were deemed to be the roboRIO processor and the radio. High current consumers are motor controllers and compressor. The roboRIO's integrated 6V, 5.5V, and 3.3V were incorporated as well.

This is a new feature that wasn't present with the previous PD or cRIO. The cRIO voltage limits were listed above, and as described, the PD board boosted several supplies. Yet teams with a high current draw and a weak battery could still reboot the cRIO and/or radio. This primary goal of this feature was to avoid reboots of the roboRIO cpu and radio.

2. Does it address the targeted issue(s)?
The roboRIO alpha and beta testing included "push" tests where the robots were intentionally run with the same battery and encouraged to push walls. They were browned out repeatedly in order to observe and test this feature. Tom Line's observations were made and investigated during these test. In general, the results were positive, but there are side-effects, and there were discussions about how to improve the feature to minimize those.

During the 2015 season, I was CSA at three events and helped some at champs. I saw teams with dozens of brownout events and I remember seeing one with over 250 brownouts in a single match. The team had a weak battery, long robot, sticky wheels, and would have rebooted easily and repeatedly with the previous system. With it, they survived the match and contributed -- some -- to their alliance. They knew the battery was weak and new what to do to avoid that portion of the problem. So yeah, it seems to work for the intended problem.

But roboRIO and radio reboots still happen, and more than I'd like to see. I was able to investigate a few dozen of these at each regional and in 70% of the cases it was due to a loose connection at either the main breaker or the battery leads. A few were clearly due to cable insertion at the roboRIO or PD. Others were harder to pin down but could be due to fuse insertion on the PD. It may be possible for the brownout to go black before the motor controllers and compressor comply, but we need more usage to know how common this is.

3. Does it introduce new issues?
Yes.
To generalize, if teams implement more sophisticated feedback control and do not take brownouts into account, they will see new issues caused by the brownout feature. For example, if a PID is commanding a motor controller to 40%, but the motor output is actually at 0% due to brownout, integral error can accumulate and cause a bump when the motor operation is enabled again. If the sensor value droops, due to input voltage supply, this can compound the issue. If the sensor power supplied by the roboRIO goes into protection mode, then the sensor value isn't valid and this gibberish can cause even more severe control issues. Tom Line's comments above were caused by a combination of these effects. And as other beta teams pointed out, incremental sensors used for absolute measurement will now have a bias and/or need to be recalibrated.

There is another issue, and that is that the system now effectively limits the current usage in an additional way. The main breaker, individual breakers, and brownout features are all imposing limits on the available current. Teams familiar with the first two may feel like a third wasn't needed, and will once again have to discover the edge of the new envelope and how to push the system. Published specs and time with the system will address this.

4. Can it be improved?
Yes.
This is still underway. During beta, the FPGA stopped disabling the 5V and 3.3V sensor rail intentionally. It disables the 6V used by servos, the PWM values are set to zero or neutral, and the CAN devices are notified and should stop using large amounts of current. There are small tweaks that will attempt to shorten the brownout response of the high current devices but maintain solenoid states, etc. The PID functions and tutorials will include brownout awareness and can even incorporate sensor power loss awareness. Using incremental sensors for absolute measurements was already tricky, and some teams have chosen to supply their own sensor power via the VDM. All of these should improve the gap between brownout and sensor rail dropout and the side-effects of it if/when it happens.

As for pushing the envelope, the power API and PD features should make this much easier and more adaptive than it used to be.

The feedback that a robot is browning out also needs to be improved. The DS counts them, adds them to the log, puts a big red indicator behind the battery readout, and sends the into the field monitor. The indication on the field monitor is a momentary red blink on the voltage box. IMO there are many improvements to be made there.

Conclusion?
The team with 250 brownouts, the team with just one or two, they are able to finish the match instead of rebooting three or four times. They will have a better experience. The 1000's of teams who could use better mentoring still need to tighten the nuts on their main breaker, attach battery leads more robustly, and insert the fuses into the PD, but this feature seems to help them far more than it hurts. It has already been improved from the alpha/beta period, additional tweaks are underway, and we are open to questions and feedback. Insults ... I've been called worse, but they aren't so productive.

I like the OP's tone of this thread. So what are the specifics?
Greg McKaskle
Reply With Quote
 


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 12:39.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi