|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#1
|
|||
|
|||
|
FIRST: take advantage of your mentors expertise
We all know we had a huge problem at Einstein on Sunday. But when the going gets tough, the tough gets going and its time to get going. I want to point out there is a huge pool of mentor expertise that happen to have no robots to build for a while. FIRST is highly resource bound and they should take advantage of the pool to build a much more rich set of across the board field and robot diagnostic tools over the next nine months.
My experience is a rugged design can never have too much of the following - redundancy, - significant spare performance headroom (bandwidth, network, cpu cycles etc) - custom highly focused tool sets, - maximum real-time fault detection with clear messaging and logging - super smart fault recovery code I think the mentors could put together a nice inexpensive realtime datalogger that records any abnormality/exceptions during say the last 15 seconds on a flash card and has a really smart diagnostic messaging interface to monitor key system events such as high and low power exceptions to the Crio and bridge, monitor in and outbound network traffic rates and key parameters, events. The Crio could communicate with it via the network or I/O card capturing exception key events especially those that lead to the Crio doing a reboot. A $20 Arduino + a little extra hardware should be able to do it. I think Dlink could give FIRST access (via special firmware if necessary) to key radio performance parameters: Signal quality, error/retry rates, throughput rates, capacity loading etc. I would also like to throw the ball in National Instruments court to 1) speed up the rebooting of the Crio. It takes forever in a 150 second match. A high value real-time system I worked on could reboot and have the control program in control in a fraction of a second while still saving the complete pre reboot memory image reboot for later crash dump analysis. Imagine if a robot would reboot in a few seconds. 2) optimize the “critical error forcing a reboot” code to store a simple human readable reason in a location that can be easily accessed after the reboot (or perhaps force it out a the serial port or I/O card for the datalogger) before rebooting. No more guessing did it reboot and why. My goal here is not do a design in a forum but get FIRST to take advantage of its user expertise over the next 9 months to build the most rugged survivable diagnostic enriched robot and field system design FIRST has ever had. FIRST are you listening ? Last edited by de_ : 01-05-2012 at 15:06. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|