Quote:
Originally Posted by crake
I'm putting on my moderator hat for a second.
This is be to a productive forum with constructive dialog. Please do not deviate from that.
Ok... now for my control system hat...
I'd like to say a few things. First off I wrote the brown out spec. It was reviewed by control system members and it was tested against real-world data before it was accepted and implemented. Is it perfect? No - there are things that could have been better. For instance, user rails probably don't need to be shut down as aggressively as they are. Also even though teams enter/exit brownout without even knowing (see Greg's post on this - the system does actually work), the interactions with the FMS can sometimes make it worse. Some of these things (FMS) can be adjusted, while others (user rail behavior) can not.
Greg, Joe, myself, and others are heavily committed to providing a reliable control system that enables team success. We are continuously looking at field and robot performance as well as community feedback to determine ways to make improvements.
|
Thanks, Chris. As the founder of Kauai Labs, I have perhaps a unique perspective on this, as a result of developing/supporting the navX MXP IMU. Key goals included an easy-to-use, plug-n-play product useful to both upper-tier teams as well as beginning teams. Our focus is to keep improving things til we reach those goals.
The MXP connector was a great idea that really helped enable plug-n-play; however, this particular brownout issue negatively impacts these goals.
The primary reason is that the navX MXP (and certain other sensors, for sure) needs to manage state; in the case of the navX MXP there's some non-trivial run-time calibration state that's key. As noted by others, MXP products (Revduino) and other non-MXP products (e.g, the Beaglebone) are going to encounter similar issues.
In this case the specific issue is the 5 and 3.3V user rail supply rails on the MXP connector; voltage on these is not maintained in the case of a stage 2 brownout. The navX MXP has an onboard LDO that regulates the 5V MXP rail down to 3.3V to power a 32-bit ARM microcontroller; the board consumes a max of 250 mA.
Thanks to Joe H., who I met at CVR and pointed out the boost/buck reg attached to the USB port. Fortunately the navX MXP has a separate USB-based power supply on the navX MXP and the logic to cleanly switch between supplies w/out glitch. That's documented in our
best practices now.
But that really isn't plug-n-play, to have this extra USB cable connecting the RoboRio to the navX MXP secondary power supply - just to avoid the brownout.
So the recommendation (OK, plea) is to maintain the power to the 5 and 3.3V MXP user rail during stage 2 brownout.
If that is not possible, we (MXP developers) need recommendations on how to best deal with this issue. Additionally, I think continuing the status quo on this will have the effect of diminishing the potential of the MXP interface. We are seeing tremendous growth in digital "smart" sensors/ICs w/onboard processing and state, and would like to help make them available to the FIRST community. I can confidently say that the robot of 3 years from now will have an even greater need than today.