So this has been really strange and Ive run out of reasons this could be.
In the Spring, at one of the events I helped run technology for my former VRC team was there and playing their matches, doing skills runs, having the normal panic of competition. Then towards the end I get called over about a series of odd Field Control/Radio disconnects. Not quite sure what it is but ill lay out everything I got to include their code.
Problem: Around 45s-1minute into nearly every match the robot would disconnect. Boom. No movement at all. Only in rare circumstances did the robot ever get moving again and not consistently(think 3 out of 12 matches across 2 similar sets of FC. Either way never consistently reconnecting and going brr again). I of course being the tech guy that I am recommended them to go plug their robot up to the v5 Firmware tool and flash a firmware update. This failed to solve the problem. Bringing us into the next section
Solutions attempted.
At first my former team did what any team would normally do and swap out every component known to man. Wires, radios, controllers, brains. Nothing. Same error. The night before their state comp I even loaded up the firmware tool myself and forced an update of their firmware and found maybe 1 battery with an out of date firmware(definitely not the problem). Prior to that I had been going through all of the Field Control modules and checking cable crimps, Field Brain Firmwares, looking for dead ports you name it I think I tried it.
State rolls around, I am off reffing the MS side and get approached during lunch. Same error, still going on. At this point I am stumped, everyone I know to ask is out of solutions and this cost my former team significantly in the rankings and selection. State ends, they don’t make worlds unfortunately and I am stumped still by the error. So i do what any Alum would do for their team and gather data and troubleshoot while they gear up for other competitions(TSA,SkillsUSA ect)
What I know:
During one competition I ran tech on in the fall at that Teams home school TM on the new v5 brains worked perfectly. It was a bit of a bootlegged setup with old beater laptops as field monitors and lots of cables everywhere but it worked and worked well.
Spring event: Where the error hit. This was again on the new V5 Brains as Field Control the only notable difference being a few network switches(all on the competition network) and RPI2B+'s to control the FC Brain and the display. Nothing abnormal with this setup except for the fact that they kept encountering this error. Strange
At their next competition a last chance qualifier they were on a similar setup. New V5 Field Control, with brand new V5 brains(This EP had some modules made as they were hosting states too) and the only difference being RPI 3A+'s on the backs of these monitors.
Same error, more frustration but they made it to states. YAY!
States hits and the error is still there. even swapping with other teams radios and controllers.
Important things to note here
After states I had them load up TM and run that through a V5 Brain + spare laptop with field control loaded on it and they ran several practice matches with no problems.
I dont remember seeing radio drops on the V5 display, however I cant say this for sure
As far as I can tell their code is fine, however code isn’t my strong suit so I cannot say for sure
All I know is that resetting the brain, controller, and swapping out parts didn’t work.
So for the sake of curiosity and in case this happens to another team does anyone have any ideas?
linking the code here as well.
Thanks! 2022-2023_916A_Flywheel.zip (6.9 MB)
There were other threads following the random disconnects that never end up reconnecting dating back to March of '22 and 2019. This is not just random, it is practically every time this team goes to plug into fields and run a match. This same forementioned team ended up losing in quarter-finals to this same disconnect issue with 1:15 left in the driver portion of the match.
Stuff that was attempted in addition to SaltyCB’s list:
Antistatic guard sprayed on wheels and surfaces
All firmware up to date
Switched radio out for a separate team’s
All I can think of being an issue:
EZ template
Telling the controller to consistently rumble when optimal flywheel speed is reached
FC units not liking the 4 character team 916A
FC unit at State competition being the one bridging other fields together
Interesting enough, after their disconnect in finals I went over to see the FC brain’s log on the team’s data. The team number was not showing up (showed up as 000000) and was not showing any radio drops or cable drops. No other information was provided useful by this.
I would really like to see this issue fixed at some point because as SaltyBC stated, this has plagued this team’s chance of getting to worlds or even getting close to qualifying for worlds.
For V5 Brain - were they using the new V5 Field Control (vs using a V5 Brain lying around running FCA)? How was the V5 Brain powered, directly or with V5 Battery in the loop? How was the FCA setup for the V5 Brain configured, was it running power to the alliance controllers or was that disabled?
I think for testing having the operating environment known is important.
Controller was reset a few times which helped once or twice but then didn’t help. They had the disconnect issue in skills as well. As far as I know they ran all matches with the rumble function.
We were running an event this weekend and found some teams that seemed to be having some issues similar to this. It appeared to be their remote control and the pins that are inside where they plug into the field. Remote works fine otherwise but when plugged in disconnects happened. We could see it happen when they wiggled the cord which showed it was that connection. Switching the remote fixed it every time. Not sure if this is the same, but maybe.
Was this using the legacy RJ45 competition connector ? If so, that sounds like the controller possibly being confused as to whether to be on a competition or pit radio channel.
Yes, We were not using the V5 system. It was about 3 teams that experienced it both on the competition fields and at skills. Interestingly, it was only the middle school teams. The day before, none of the high school teams had the problem.
I ran the code a bit (only drive and flywheel motors), no issues as far as I can tell. It responded to V5/TM field control as I would expect, no disconnects after running continuous for an hour.
so idk…
Did you do field control via a computer or with the RPI’s?
I’m confused since they are testing with a computer hooked to the brain for field control and having no issues
I was just using TM running on Windows and connecting the field brain directly (yea, I was being lazy as primary purpose of the test was to look for code anomalies). However, I would not expect to see any difference if the FC brain was hooked up to the RasPi.
Sorry to burst bubble … but V5 Field Control vs Manual Match Control does impact program skills run. This was a problem at HS event with one team at two championship event this past weekend.
V5 Field Control has been overly positive, but gremlins persist.
Shoot me an email for details to contact impacted team.
Sadly it seems that the only time it threw a problem was with the FC on an RPI. If you want to can go pull the specs and everything for pis I know caused issues.
I setup a RasPi running current TM software with the field control brain. TM server on windows, networked to the Pi. I ran several matches on and off over a couple of hours, no issues, no disconnects.
For what ever its worth, we spent about an hour with a team that had “field problems” at the last event. Their auto worked fine on the competition switch but failed when connected to the towers.
We set up the same towers, Pi, cables, router, cables, etc as the event.
We ran 6 matches tonight and there was not a glitch the entire time. In probing more I found out that
they were using a different controller from the event, they lost theirs across the weekend.
they made a change in their code just before their last two matches and things started to work.
So I’m writing this off to code issues, not to tower issues. @SaltyCB , not sure of what your issues are.
The situation I am describing (and at this point not sure related to original concerns) is team who tests their robot programming skills with manual VEXnet Competition Switch 276-2335 and then when trying skills runs or on the field with the new V5 Smart Field Controller 276-7577 the program behaves differently. Since it was in middle of event and I had to get matches started, I loaned him our Smart Field Controller to tune his program and then it was consistent. This is the third time I have encountered this - not sure what the root cause is, but field signaling with VEXnet manual switch and using V5 Smart Field Controller yields different results.
Second issues with field disconnects, we run skills in two different areas with V5 Smart Field Controller - in one area never and issue using VEXnet radio, but second location lots of disconnects for different teams. We switched over to Bluetooth and that resulted in more stable situation.
Don’t get me wrong, hands down V5 Smart Field Controllers (production) is the direction to go. Just need to know about the gremlins.
So i’ve been doing this for a while now, not as long as @Foster, but long enough to see exactly the same complaints being made over and over as we have been through different robot control systems. It’s always hard to debug these issues, many times it’s code, sometimes environmental (yea, the popcorn station), sometimes physical (bad cable, connector etc.) sometimes TM operator error and very seldom an issue with TM or field control.
I find no issues with @SaltyCB 's code, although I cannot run it on their robot so that is a difference.
Worlds teams, read this old topic yet again, look after your controllers and don’t abuse connectors and just realize that sometimes stuff happens.
