Quote:
Originally Posted by techhelpbb
Testing mostly and perhaps the elimination of replicated parts (instead of 10 speed controls trying to regulate their control logic power, you have 1 cleanly regulated power source that does the whole step up and down once). If you put a COTS computing device on the robot now you add a second power source (the battery in it).
|
I see, but I'm still not convinced it would help enough to warrant the extra power source. And a COTS computing device doesn't necessarily have a power source, especially if you use a small embedded mini-ITX board or something.
Quote:
Originally Posted by techhelpbb
For logging, especially if there's a place to store the logs, it could help. I mean you can do it in software now...it's not incredibly accurate but it works and it works well enough for competition purposes. I just figure if you have a decent time source it's one less thing someone new had to figure out (besides my little flash logging module already has an RTC for this whole reason...I didn't want to have to rely on more code in the system you were logging if I could avoid it).
|
I am convinced, being able to log and time data offboard would be useful, actually there were a couple times we were debugging an intermittent task crash this season that would have been useful. Once the system dies, there was no way to get the information we needed. It was a lot of blind guessing, and a
lot of ibuprofen.
Quote:
Originally Posted by techhelpbb
Yeap, the Jaguars can collect the data, but where on the robot can you put it so that it survives once you turn off the power? You can send it back to the driver's station if the communications is cooperating. Also this requires checking that current sensor which I'm sort of trying to avoid as it adds to the traffic on the CAN. Really it doesn't need to be something you have to poll. It's easy enough to make a circuit that simply latches if the current exceeds the threshold (so it can respond quickly without interrupting what you are doing...and much faster than the circuit protection). I'm proposing something not so clever as a digital to analog converter...more a circuit that produces a simple on or off with a reset (flip-flop). So off is under current limit, and on is exceeded the limit...feel free to reset and try again.
The nice part is, even a novice programmer could monitor that and know if they went over the current limits...and more importantly then they can decide what to do with that event before they end up tripping the circuit protection. However, and more importantly, it can be on the robot while it moves and it just immediately removes the doubt if you are over those current limits and how often it happens. It's doesn't even really matter if it's a Jaguar. Heck hang an LED off it...you see the light start wondering why.
|
I see, I guess I was thinking too high level (monitoring the current and logging spikes and dips and breaker pops), you just mean detecting and recording a transient over-current system. It might be worth considering, in addition to a digital signal indicating the spike, perhaps one that indicates voltage present at the node with a comparator (to determine if the breaker is currently open or closed, maybe a moot point with self resetting breakers?) and a reset line to clear the latched fault?
Matt