|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#1
|
||||
|
||||
|
Control System Design Contest Proposal
Background: In this thread about Jaguars vs Victors I suggested a design competition for FRC teams to design a new integrated control system to replace the current one, which many feel is too disjointed and complicated. That discussion started to dominate the thread and I decided to form one here to hold that discussion, the relevant part of my original post is below:
Personally, I'd really like to see FIRST open up the control system with a design competition. Let teams design and submit control system ideas, designed around what teams want/need and their resources and let the FIRST community and it's thousands of brilliant minds weigh in. We already have a competition to design robots in the winter and spring, why not control system summer and fall? While the guys at NI and TI have done an admirable job, I do agree the current system is an amalgam of several good ideas with bits hacked together to work in a manner that's.... well let's go with frustrating. But those guys were small in numbers, and probably did not have all that much to work with. I sincerely think the mentors and students of FIRST stand a good chance of coming up with an effective, workable solution to our somewhat oddball use case. Even if only because of the sheer amounts of brainpower we have at our disposal. So, what have you guys got? Maybe we should start with a list of basic requirements for the system, I've quoted part of Al's suggested requirement from the original thread: Quote:
Quote:
Matt |
|
#2
|
||||
|
||||
|
Re: Control System Design Contest Proposal
(Moved from old topic...)
I think I'd like to see: 1. A good alarm on the robot that traps any voltage drops below a specific threshold and reports it when something bothers to check (I built one so I know this can be done and how handy it is). Mind you, not merely an analog to digital converter, a latched alarm that doesn't depend on being checked. 2. The ability to separate the power for the control logic from the power for the motors (at least for troubleshooting, I can power all the Propellers on my test frame with a pair of D cell batteries if I wanted). 3. The ability to store data on the robot that will survive a complete power down (already built that with flash). Why? Cause when things go nuts you can read that memory and unlike with the WiFi you don't have the overhead of reliable TCP/IP and buffering up. 4. The ability to check the quality of the link from the field control (that's a ghost that's caused enough headaches). Again, probably gonna need the memory for that....cause right now I can't tell you after the robot powers down if you lost the field. 5. I2C, SPI or serial (emulated is fine, but with completely functional examples for the software). 6A. Circuit protection that is consistent. So a 40A breaker that actually trips at 40A and does so over and over...not once at 40A, once at 30A, once at 20A and then maybe will be like that for a while. or 6B. A latching current monitoring system that can tell you if you trip the breaker from over current. (I've already built 6B and frankly so can anyone...look at the TI appnote for the current monitor in the black Jaguar.) 7. This is pure programming and controller design: It must be able to do more than one thing at a time...and not because your a wizard that can hand punch player piano roles (though if you can get your robot to run on player piano roles post it LOL). It is surprising difficult to thread with the cRIO as configured for FIRST...it does work...it took a while to figure it out. Course the Parallax Propellers eliminate this concern a whole different way...you just keep adding chips and cogs until you have enough and they can all run at the same time (communication between them is a bit more tricky because of it). 8. The connectors have to latch. There's nothing quite like a great robot failing because a poor connector slipped off. 9. Documentation. I know that the reason no one will find the blue prints for human kind's greatest creations is because someone drew them on napkins during lunch and then left the used napkins in the garbage, but we need people to learn this stuff and guidance from the people with the most experience with it is always welcome. Leverage technology and use a Wiki if you must. Also, JavaDocs with notes like "does not work" is not what I mean. 10. It has to be cheap enough to ship to all the teams quickly and safely, and it has to be economical enough to send teams a baseline system within the existing funding constraints (the new cRIO has lowered the bar on the total package price by a fair bit, thanks NI). 11. >NO< undocumented connectors. You too can keep the smoke in my ears and in your electronics. Just make sure people understand what connects to what clearly. Oh and send at least test cables for something like the Jaguar with a bill of materials. |
|
#3
|
||||
|
||||
|
Re: Control System Design Contest Proposal
(Partially moved the contextually relevant parts from old topic...)
I think that video capability should be optional (that's why it didn't bother me when I built my Parallax Propeller based test platform I have that the Parallax Propeller's USB host capability is sort of slow for webcam use...I figured a laptop would do it if it was needed...sort of like you add a compressor and tank for pneumatics if you want them). I think if you can remove features you don't want...and are resource expensive like this...the more variance you can have in what you use that weight savings for elsewhere. Some teams might not want to tackle the challenge of video processing (even though libraries like PyGames are making that easy as Py )So I would think flexibility....but not at the expense of reliability or practicality should be a priority of some sort. Last edited by techhelpbb : 02-03-2012 at 20:06. |
|
#4
|
||||
|
||||
|
Re: Control System Design Contest Proposal
I see no mention of a system that is quick to boot and establish communications. For whatever the reasons may be (there a few threads discussing it), the current 802.11 scheme takes a while and has plenty of issues besides. So if that means scrapping 802.11 for a proprietary radio link IFI-style or modifying the wifi setup to streamline things, whatever. The general requirement is quick boots and quick and rock solid connections.
Also it'd be nice if the controller booted faster... |
|
#5
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Code needs to download into the system *quickly* and 2 minutes is not quick enough. It might also be nice if you can download code back from the robot. Last edited by techhelpbb : 02-03-2012 at 20:48. |
|
#6
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
![]() I agree, Wi-Fi has too much overhead in general for this setup, including the time for the router and everything to start up, connect together... etc. I'd really actually like to see an 802.15.4 based system, but I'm not sure it has the bandwidth for the full video streaming everyone is spoiled by now (In my day we didn't have streaming video, we drove our robots with our eyes! ) but something could almost certainly be worked out. Maybe there are Wi-Fi based solutions that are simply faster and more streamlined?I do think the system shouldn't take so long to start up, but I'm spoiled by the IFI system that just started running, so perhaps the boot up time isn't as long as it feels to me. I've transplanted my comments from the other thread here as well: Quote:
If you meant just to have them connected to separate power so you can turn off one without the other, then just use a separate battery and PD board to run the controls and tie the negatives together. Quote:
Quote:
Matt |
|
#7
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Just put down the cantenna. You won't be needing that: http://www.instructables.com/id/WiFi...thout-pigtail/ Last edited by techhelpbb : 02-03-2012 at 20:59. |
|
#8
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
I suppose, Wi-Fi itself isn't really the problem, but more the actual radio hardware setup we have now, so that could probably be improved on without being replaced entirely. Matt |
|
#9
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Quote:
Speaking of which I'd like a real time clock in the control system please, regardless of the presence of the laptop (epoch time is fine and it doesn't need to be from 1970 like in Unix). Quote:
In point of fact someone will point out that a DMM can do this (but slower) or an oscilloscope with a current probe can do this, faster but much heavier. I'm looking for the compromise. Something light enough for competition, approved for competition, but removable for those that don't want it. Like the suggestion I gave for reverse voltage protection on the Jaguars. Last edited by techhelpbb : 02-03-2012 at 21:11. |
|
#10
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Here's a fun idea (but this isn't really a must have by any means):
Take a smartphone with a USB port and WiFi and use that as the robot controller, most have at least one camera, some 2. Use the USB port to hook up to the I/O devices through a custom module. Don't bother with a router, don't bother with a PC. Now the whole robot controller core is feather weight, has it's own power supply with battery, and is well the size of your phone. All the radio bands you could want, when you don't want it, sell it off...people buy these things. Hmm, is there an app for that ? |
|
#11
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Quote:
Quote:
Matt |
|
#12
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Quote:
Quote:
Quote:
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. |
|
#13
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
Quote:
Quote:
Matt |
|
#14
|
||||
|
||||
|
Re: Control System Design Contest Proposal
Quote:
The way I look at it, I can do this right now (and on two I did)....but I probably have to ruin the speed control for competition and I see no reason for that. There's no reason you couldn't use the main battery for everything if you really want to and don't mind the issues from the motor. In point of fact, if you separate the control supplies and the motor supplies you could just use a big capacitor on the existing battery. The control logic doesn't require much (a couple of C or D cells is enough for what I have). A capacitor could probably provide just enough 'ride-through' for a short time. Actually, if you wanted you could get a little exotic and use a LiPo battery back for that if a suitable charger was available cheap. Then it would be cell phone weight. Actually for fun my existing test frame has a Boss Audio 3.5 Farad (you didn't read that wrong) capacitor on the frame with the voltage meter 'cap'. The whole reason it was there was to try providing a lower internal resistance to hold up the battery if the speed controls get too much and cause a brown out. Just something I was playing with and it was less than $100. (Yes now besides stick welding with the robot's battery you have a capacitor to insure you can lightly weld with your robot as well....lol) Quote:
Yes I agree, there are going to be times when under or over is not enough. Right now my current monitor uses a window comparator set with fixed resistors so you can actually tell if you have too much or too little (if you want...otherwise ignore one side). The same with my voltage monitor. I thought about using 'digital potentiometers' and I tried it...but I'm not sure the extra cost is all that necessary when you can get cheap good enough resistors at RadioShack. Besides the worst that happens is someone uses the wrong resistor and it trips at 60A instead of 30A...it's not the circuit protection you'll live. People just need to learn Ohm's law or use a look up table and learn how to read color code (actually right now the resistors can be fixed into a connector so you don't even need that, could just get the connector with resistors in it for that setting). Course I used rail-rail JFET opamps so there's the whole slew rate business, but still that's much faster than a DMM and much more practical in this application than an oscilloscope. I actually previously discussed basically what I'm talking about here in these forums. I could have done this with discrete transistors but even with surface mount I'm not sure that saves me anything over the integrated package...besides then there's that whole SWARF! thing and more possible points of contact. I think in order for this to useful you need the reset (set reset flip-flop (or one made of gates) or JK flip-flop). Otherwise basically all that the thing is good for is the first over/under limit. Hopefully this is set below the circuit protection threshold and it actually doesn't matter if it's above the battery negative...it's easy enough to clamp the high impedance input if it's put in backwards. Though back to my previous point I'd prefer that putting things in backwards requires at least as much effort as a square peg in a round hole to achieve. Last edited by techhelpbb : 03-03-2012 at 11:08. |
|
#15
|
|||
|
|||
|
Re: Control System Design Contest Proposal
I'm doing my best to follow this thread, and I may ask clarifying questions or point things out from time to time.
Logging was mentioned. The DS now has a Charts tab that displays the packet loss and trip time for communications -- same as the field has. It displays CPU usage, RAM, flash, and system voltage. It doesn't have any current data available to log. The robot flash is capable of logging info, but I'm not sure how much data or what data should be logged by default. The DS also logs the mode that the field or DS asked to be run and if the robot code is instrumented, it logs what code actually ran on the robot. The DS data is saved on the DS and a log viewer is in the Program Files/FRC Driver Station folder. Greg McKaskle |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|