View Single Post
  #12   Spotlight this post!  
Unread 03-03-2012, 01:52
techhelpbb's Avatar
techhelpbb techhelpbb is offline
Registered User
FRC #0011 (MORT - Team 11)
Team Role: Mentor
 
Join Date: Nov 2010
Rookie Year: 1997
Location: New Jersey
Posts: 1,620
techhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond reputetechhelpbb has a reputation beyond repute
Re: Control System Design Contest Proposal

Quote:
Originally Posted by Matt Krass View Post
Aha, I see, it makes sense, but I'm not sure it is really weight feasible to add a secondary power source like that, and I'm not sure what advantage it would really get you?
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).

Quote:
I think the current FMS software tracks that data, you might be able to get your hands on it if you ask the right person, perhaps Mark McLeod? He seems to have a lot of background info on what's going on there.
Thanks, I'll follow up on that after some sleep.

Quote:
An RTC is a nice feature, but for the 3 minute bursts of activity is it really necessary?
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).

Quote:
Since the over-current protection in Jaguars is software based, it would easy enough to save the value when the shutdown activates. For the breakers, it would have to be another solution obviously.

Matt
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.
Reply With Quote