![]() |
[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? |
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. |
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. |
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. |
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 ;-) |
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 |
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"! |
Re: [DFTF] Operator Interface...
Quote:
Joe J. |
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 |
Re: [DFTF] Operator Interface...
Quote:
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. |
Re: [DFTF] Operator Interface...
Quote:
We believe the CCI is the easiest way to add custom controls to the FRC Operator Interface. Creating an opportunity for students to gain the experience of creating a unique user interface for their FRC robot. The CCI supports Windows XP and Windows 7. The documentation for the Custom Control Interface, Basic Layout & Connection Guide is available on our site. The current version of the documentation is 1.2 and includes tips and directions for connecting switches and potentiometers. Ordering information for the CCI is available here. |
Re: [DFTF] Operator Interface...
We purchased QTY (2) of these interfaces, and our programmers said they where easy to use. We used Automation Direct buttons to create an 3 x 3 array of buttons which resembled the pegs on the 2011 game. Each button loaded a preset PID target for the elevator and arm angle on our 2011 robot. Couldn't be happier with the modules. They work great. We put some hot glue on the mini-USB connector to make sure the USB never came out, wiring was easy with screw terminals. Love the CCI interfaces from e-stop robotics.
|
Re: [DFTF] Operator Interface...
I'd stay away from the Cypress (FIRSTtouch) board if possible.
We used it in 2010 with nothing but problems - Back then, the Classmate was totally locked down so when in Driver mode you couldn't open Task Manager. The Cypress driver seemed to randomly crash when exiting sleep, and you would have to reboot the laptop, sometimes twice, for it to find the board again. Our only solution was to never shut down the laptop ever, which was very hard with the lack of power at the driver station that year. I don't know if they fixed it, but I've still found that the Cypress drivers aren't always installed and many of our driver station laptops don't have them. In 2011, we used the Classmate with two gamepads (a Logitech DualAction and a 360 gamepad), plus an IO box with an autonomous and other less-used switches which we made out of a Logitech Precision gamepad, which lacks analog sticks. We took the PCB out, and soldered to all of the pads where the switches were, and it worked well. As for laptops, we are currently planning on using a Dell Latitude D630, which has two batteries. |
Re: [DFTF] Operator Interface...
Quote:
|
Re: [DFTF] Operator Interface...
Quote:
|
| All times are GMT -5. The time now is 23:06. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi