|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||||
|
||||||
|
[DFTF] Operator Interface...
This is part of a series of posts called Drinking From The Firehose on getting Dr Joe back up to speed on All Things FIRST.
![]() Today's topic: Operator Interface... Whoa... ...that jet of water his hitting full in the face now! I almost titled this "Is FIRST trying to kill rookies with this mess they call a Control System?" cause, boy howdy, the FRC Control System is a lot of things, but Rookie Friendly ain't one of 'em!!! Let's leave that because I am in a good mode after a great day in The Box* Here is the thing. I have never had to build an operator interface since the switch to the cRio/Classmate Combo. I know from the help I gave to Ursa Major #2849 2 years ago (funny video of them balancing a robot using the Kinect as an input here), I am planning to include a FIRST Battery & AC Power Converter to keep the Classmate from having a low power shut down while waiting for a match -- no 120VAC outlets available (this really happened -- ouch). Has FIRST fixed this, do I need to do this any more? What else should I know? One thing that surprises me is the pretty open rules: fit on the shelf, run the right code, display diagnostics, interface via the Ethernet, and nothing but approved wireless. Seem like you can drive a truck through those rules. What do people do with this openness? I have a strong bias toward using gamepads rather than the joysticks from the kit. Have others used them? What about this FIRST Touch IO thing. I have tried to look to discover what it does and I am not really getting it. It is a SOIC and we are allowed to modify it's firmware (per rule [R58] section L) or maybe I can't (per the blue box in under [R58]) but what do folks do with it? I suppose that folks drive lights and read switches and such. But can you do other things as well. It is suppose to work with the driver's station but in what way? Is this the only way to do IO on the Operator Interface? Anyway, tell me what I need to know. Thanks in advance. Joe J. *our team's nick name for meeting room in the basement of the school -- our team is called Schrodinger's Cat. Get it? |
|
#2
|
|||||
|
|||||
|
Re: [DFTF] Operator Interface...
Dr. Joe, FIRST is providing classmate power on the field these days. They have an adapter for the Classmate only at each station. In the queue line, that's another story--but the Classmate has a decent battery, at least initially.
You can also use your own laptop/computing device, but then you're on your own for power. |
|
#3
|
|||||
|
|||||
|
Re: [DFTF] Operator Interface...
Quote:
Anyhow, the firehose is at full pressure now. !, We use a marine battery on our cart with an AC inverter for power, even though FIRST provides power (as EricH notes) 2. We use openness for creativity. It also provides for some teachable moments, since we strive to be GP with that openness. You know what is right and wrong, FIRST trusts you. 3. Our kids play video games, and they use game pads. That's the MMI they know, so that's what we use. Been that way for a few years now. Joysticks remain an option, but none of our drivers has ever asked for them. 4. First touch I/O replaces the I/O ports on the IFI box. You get digital Is and Os, and analog inputs too. If you control everything using the classmate/computer, you don't need it. But if you just can't get away from an old-fashioned button board, or you insist on analog CF Flightsticks, they are possible because of this board. It is the only easy way to do OI I/O, but of course there are other possibilities - just not so easy. |
|
#4
|
||||||
|
||||||
|
Re: [DFTF] Operator Interface...
Quote:
There were some firmware issues early last season, but I didn't hear of any trouble after those were resolved. |
|
#5
|
||||||
|
||||||
|
Re: [DFTF] Operator Interface...
What about the O part of IO?
Of course there is the Classmate screen but what if you want to light up a light or in some other way give feedback to your drivers*? Picking another random example. What if you wanted your robot to be able to press the e-stop button? It is a silly example of course but seriously, could you use this robot to sit on your operator interface? It would take some doing. You'd have to power it. AND you'd have to write some code (maybe in Java using the SmartDashboard API) to write an API for the cRio to access. But would it be legal? My reading of the rules says yes. This hand would probably legal too I guess -- well... ...except for the Gracious Professionalism violation (careful if you are easily offended... ...the robotic hand makes a gesture that in many cultures is not a term of endearment). Joe J. *picking a random example suppose you want to have a mechanical hand come out of a box and slap your driver silly ;-) |
|
#6
|
|||
|
|||
|
Re: [DFTF] Operator Interface...
I think the general philosophy is to make things safe and avoid delaying matches. Beyond that, it can be pretty open and allows for the teams to experiment with all sorts of technology.
Personally, I'd mount the maplin robot you linked to directly on the driver, like Inspector Gadget. Then modify the dashboard to control the arm to "help". Greg McKaskle |
|
#7
|
||||
|
||||
|
Re: [DFTF] Operator Interface...
While we have tested both the gamepad and the joystick interfaces, we have normally stayed with the joysticks. We use tank mode driving which seems more natural with two joysticks. When we have tried using a gamepad we found the lack of range of stick motion vs game pad stick motion to be disturbing (there is more room for the driver to move the sticks), this might be different with omnidirectional type of drives. You will probably need to check which is easier for your drivers.
As per the First Touch IO module, we used this last year. While you can update and reprogram the device (more like a FPGA than anything) this is difficult since in order for the IO module to be recognized by the driver's station it must be built on the FIRST provided framework and at this point is difficult. It provides Analog (which we used last year as inputs from Potentiometers) and digital inputs, as well as digital outputs. There are supposedly other modes (like encoder input) available, but switches are the most used. One thing not noted. Be very careful with your wireless signals. The best we have seen is to try and maintain wireless N across the drivers station link in order to eliminate the interference with WiFi signals/Access points. You do not want to see the dreaded 'No Robot Communication"! |
|
#8
|
||||||
|
||||||
|
Re: [DFTF] Operator Interface...
Quote:
Joe J. |
|
#9
|
|||
|
|||
|
Re: [DFTF] Operator Interface...
I think the phrase about wifi was advising to use an N-speed or an 802.11N network where possible -- specifically 5GHz N or dual band N. G will work in a pinch, but is lower bandwidth, tends to be busier and the band used 2.4GHz is congested. N also has better range.
Using N means having a laptop, router, bridge, and other elements that support it. If one of the elements is g, the communication path will revert to g speeds. Greg McKaskle |
|
#10
|
|||||
|
|||||
|
Re: [DFTF] Operator Interface...
There are a bunch of digital outputs available. No analog outputs. These sink enough current to drive small LEDs, and can certainly drive a transistor or other switch to manage larger loads.
I see no rules prohibiting either of those items from being used with the Operator Interface. And that would surely win the "cool as beans" award in my book. Wireless N: Greg covered it well. WiFi wireless networking comes in several flavors, they are all called 802.11 after the IEEE section where they are defined, with the first being 802.11a, the next 802.11b, and so on. Current latest and greatest commercially is 802.11n. |
|
#11
|
||||||
|
||||||
|
Re: [DFTF] Operator Interface...
Quote:
I actually think we'll be making a lot of use of the Cypress board this year. |
|
#12
|
|||
|
|||
|
Re: [DFTF] Operator Interface...
We used the eStop CCI last year. Very easy to wire and program, but no O, only I.
|
|
#13
|
||||
|
||||
|
Re: [DFTF] Operator Interface...
Quote:
With the extensive dashboard capabilities of the current Operator Interface what O would you like to see in an interface like the CCI? |
|
#14
|
|||||
|
|||||
|
Re: [DFTF] Operator Interface...
The eStop CCI is a very well designed product in my experience.
One thing you should know about, Dr. Joe, is the evolution of the dashboard software over the past few seasons. Not only is there a good default LabView dashboard, but for C++ or Java users there is also the SmartDashboard, which is highly configurable and supports things like bidirectional data exchanges (so you can pick your autonomous mode right in the GUI) and integration with JavaCV/OpenCV (in case you prefer doing any image processing remotely). In addition, there have been a few team-created open source dashboards released, with the most popular probably being ZomB. Links: SmartDashboard (http://firstforge.wpi.edu/sf/projects/smartdashboard) ZomB Dashboard (http://firstforge.wpi.edu/sf/projects/zombdashboard) |
|
#15
|
|||
|
|||
|
Re: [DFTF] Operator Interface...
We Used the eStop CCI last year, it was simple to use.
We have also dissected a std joystick, and made a custom control panel by wiring the (arcade)switches to the corresponding connections on the joystick. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|