[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?

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.

Yes, But since we know you’re alive, doesn’t that spoil it?

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)

  1. 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.

  2. 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.

  3. 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.

Another option, is the EStop Robotics CCI, which emulates a joystick with digital and analog IO. http://www.estoprobotics.com/estore/index.php?_a=viewProd&productId=33

There were some firmware issues early last season, but I didn’t hear of any trouble after those were resolved.

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 :wink:

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

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"!

Thanks for the input. But that last bit about “maintain wireless N…” is totally outside my understanding. I understand each word but I have no idea what is says.

Joe J.

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

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.

Joe, thanks for plug! :smiley:

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.

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.

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.

I think those problems have been fixed. We used the Cypress board last year and had no problems at all.

We used the eStop CCI last year. Very easy to wire and program, but no O, only I.

We’ve done a lot with LEDs with the old IFI system (2008 and prior). We haven’t done anything since then, but we’re planning to this year. We haven’t implemented it yet, but I can let everyone know how it goes.

I actually think we’ll be making a lot of use of the Cypress board this year.

Glad to hear that you found the CCI easy to use…that was our primary goal in designing the product.

With the extensive dashboard capabilities of the current Operator Interface what O would you like to see in an interface like the CCI?

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.

SmartDashboard (http://firstforge.wpi.edu/sf/projects/smartdashboard)
ZomB Dashboard (http://firstforge.wpi.edu/sf/projects/zombdashboard)

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.

We have used the Cypress for the past 2 years, and have had no problems with it. Instead of the breadboard that came in the KOP, we also order one of these every year, so we can just pull off the Cypress and reuse it the next year while leaving the button box intact, just in case we need to use it again.

I guess I am a bit biased, however, as i have never tried the new CCI. I do, however, give props to the enclosure that eStop made. It makes it so much easier to wire up the Cypress.