Gizmo Season Thoughts

[plurt97]

Our hub finished our practice day last week and our tournament this weekend and I want to share my final thoughts with the Gizmo and Driver Station (DS), including newfound issues and results.

Students started both days by bringing in their gizmos that had burnt out student processors some assuring us that they did not miswire the gizmo or use the fourth pin. We’re wondering if long-term non stop usage (which causes the gizmo to heat up) caused an overheating of the connection to the student processor. The hub had only a couple of student processors left the morning of the competition.

Unfortunately, some of the issues from last year are still around. My testing earlier in the season did not seem to show those issues so I thought they were solved. These issues (which occurred several times during the hub competition) included the following. N. B. There was no FMS during practice day or the competition.(which may have been a good thing as that would’ve introduced another layer of connectivity).

Issues:
Command response lag
Runaways
Uncommanded high speed Movement of All Motors
Gizmo/DS non-connectivity
Dropped Comm during match

Command Response Lag
Every team I talked with during the competition, said that there was lag or delays between commanding the robot and the robot moving, around 1/2 to 1 second. This continued throughout the day. This was last seen last year when connected via the Ethernet cable. I do not know if the lag occurred while connected via the Ethernet cable, but no one mentioned it to me, so I'm assuming it only occurred wirelessly.

Runaways
This was a major problem last year when the gizmo used TCP/IP connections. With the changeover to UDP in December, this issue went away. The problem with this is that there's a disconnect between the gizmo and the DS and the gizmo keeps the last command it receives and continues to execute it. In several cases (last year having a robot almost drive off a platform), this was a drive command. This occurred with 3 teams during practice day and at least 2 teams during the hub competition.

Uncommanded High Speed Movement of All Motors
This has occurred several times during the season and a few times during the competition, nearly breaking the robot, the robot running into me twice (which is fine) and running into a student once (she was fine, but it is disconcerting). The best guess we have is that the Gizmo loses communications with the driver station, gets a "missing" value somewhere in the code which returns 0. Unfortunately, 0 for a joystick analog/axis command is full speed backwards. The only solution we have for this is quickly powering off the gizmo.

Gizmo/DS non-connectivity
The amount of time spent during the competition to get Gizmos to connect to driver stations while in the queue was huge. We followed several steps of looking at the DS light to wait until it was solid green, then trying to turn on the gizmo. Honestly, the only consistent thing that seemed to work was having myself and the students wiggle our fingers at it to help the bytes flow - we were 6 for 6 for a while, but sadly it got worse. The saddest part is looking at a student and they can't drive their robot in a match that has started because their gizmo will not connect. I've not tried to debug this, but it's confusing as (I'm assuming there has to be) static IP connections should be straightforward.

Dropped Comm During Match
Several times during the competition (maybe once every 3 matches) a robot or two would go into "rainbow mode" in the middle of the match and lose communications and not reconnect. We worked hard to ensure cell phones were not around or off and all robots in the pits were on Ethernet cables. Students would try and raise the DS higher and even went so far as to duct tape the driver station to their wrist or shoulder to try and alleviate comm drops.

I’d like to reiterate that the theory behind the FMS is a good thing. It's future use for BEST would be great with field/robot communications. Unfortunately I still believe this set up is not ready for prime time and we are going forth with Vex V5. Again offer any assistance in testing and discussions. I hope you take me (and others who have offered) up on this offer.

I truly wish everyone the best of luck in this gizmo endeavor and, again, let us know if/how we can help.

[the-maldridge]

None of the software issues you have reported are present in the current qualified builds that are approved for hub use. Given that your hub did not deploy a supported field configuration for the game day, there's not much we can look at or review here. Please direct further concerns or comments to your hub leadership.

[plurt97]

Well that's good to hear, but I'm curious. How many hubs have actually run with a fully functional FMS? We didn't deploy an FMS because it's my understanding it wasn't ready. (So it begs the question, if there hasn't been hubs running with FMS, how would any errors be reported?) We had only a few of these errors running solo - it was only when we got together that things got messy.

But again, love the whole gizmo idea - would love to know how it's all working together and how many hubs ran FMS.

[barulicm]

Georgia ran with the full FMS setup and did not notice any issues during our Game Day event. Our practice day was run without the FMS (for reasons) and students saw a lot of dropped connections as expected there. The FMS really does make a big difference.

We did have a few dead student processors, but all were confirmed to be students plugging in motors incorrectly. Namely, plugging the 2-pin interface cable directly into the 3-pin motor port. (Our case covers the fourth unused pin). After correcting the confused students, we had no more dead student processors.

[the-maldridge]

I suspect that NHB may be the only hub that did not run the FMS, as both CowTown and SA BEST ran full FMS, and did not see the wireless issues you report. I'm not really sure where the concept of "readiness" is coming from above, as the FMS was released to hubs in late July with full documentation and opportunities to receive further information and assistance.

As to how data is reported, at a rate of ~10-20Hz every gizmo in every field reports significant status information back, which can be used to support a protest for a replay of a match.

[plurt97]

Well that is, indeed, good news, @barulicm - yeah, not sure how to stop the student processor self-destruct without more FAQ/QRG/Warning labels. Look forward to hearing more from Georgia, Cowtown, and SA and their successes!