We spent the day yesterday trying to figure why when tethered out autonomous chooser worked but wirelessly on the field the bot sat dead in autonomous. We worked with a few techs and found that turning off the windows fire wall worked. We had 7 qualifying rounds today and the last one we had no autonomous again. Brought it back to the pits, tethered and worked. ANY ideas? We have one more qualifying match tomorrow before finnals. We are currently sitting in 19th with strong possibility of making to a final alience.
Do you have a connection indicator on the dashboard? What did it say? Are you using the LabView dashboard or the Java/C++/Python etc one?
What I would do in your position is add a connection indicator on the dashboard. This will tell you whether the dashboard can connect to the NetworkTables server. If the SD isn’t connecting very soon after the robot is connected, reboot the roboRIO.
We had this same problem occur in a practice match, but not since. No guarantee of this working, but I’ve had trouble with the roboRIO not fully booting up a few times today.
If I have a chance, I’ll come over tomorrow morning to try and help some more.
It’s almost certainly not connecting to the robot… you can see this by adding a connection widget to the SmartDashboard. You should set your computer and roborio up with static IPs.
If you do have a connection indicator and it was green and your selected autonomous still did not run, select a different autonomous mode and then re-select your desired autonomous. You may have a race condition where your selected autonomous doesn’t get sent over to the robot initially.
We do have a connection indicator but will have to ask the drive coach and team if they noticed the status. Most likely they did not . The select / reselect was a rouble shooting step attempted yesterday but since today the entire day it was running flawlessly the drivers hadn’t been doing this. We also started yesterday with static IP’s but after our radio flash that didn’t work. The IP was 10.32.44.5 that I believe now was wrong. Should been like 10.32.44.20. Our ip camera is static with an ip of 10.32.44.11 and is lagging but displayed on the SD.
nickbrickmaster love to pick your brain for my own knowledge. You must be here at 10,000 lakes. We have a slow start in the morning. Our first and final quality is at 11:30 ish. Our plan is to re-weigh since we beefed-up a part of our bot with about 12oz and with a 119 lbs bot yep it must be done.
Sorry forgot to answer we Java command based.
Thinking about adding the line
public void autonomousIntit () {
autonomousCommand = (Command) autonomousChooser.getSelected ();
// *******Add this******
if (autonomousCommand == null) {
autonomousCommand = new Auto_00_ReachEdgeOfObstical();
// now the normal
if (autonomousCommand != null) autonomousCommand.start ();
}
If selections aren’t showing up on your dashboard, restart the robot program. The dashboard relies on the initial sending of selections on program start to know what they are.
Also, as other people have said, sometimes selectors are picky. What we did was print out what the robot thought was selected in disabledInit() so we could check if we needed to reselect something.
I would recommend doing this slightly differently. Adding that command to the SendableChooser using addDefault will do basically the same thing, but IMO is more clear as the default is defined right where you are specifying the whole list.
Having said that, I believe your way would work as well.
We also had this happen to us. It turns our that Windows 10 had re-enable the firewall. Very annoying but at least we know to look for that now. Also we ended up setting it to use static ip addresses as suggested by the FTAA. One of our eliminations alliance partners also saw the same problem… they had no firewall issue but fixed it by restarting their robot and driverstation to force a cleanup of the network tables.
We’ve had issues with GetSelected() returning null intermittently in AutonomousInit() (in C++, but it’s possible that similar ones could pop up when using Java). Calling GetSelected() in DisabledPeriodic() instead and storing its return value has been somewhat more reliable.
We endd up with this
public void autonomousIntit () {
// autonomousCommand = (Command) autonomousChooser.getSelected ();
// *******Add this******
autonomousCommand = new Auto_02_underLowbarScoreLowGoal();
// now the normal
if (autonomousCommand != null) autonomousCommand.start ();
}
Just force this code. All day (1 qual and 3 finals) we had no trouble other than the last final tiebreaker NOTHING. Frustrating! We have a addDefault but each time we had trouble we didn’t get that one either. I thought about disabledInit or periodic only couldn’t recall how even though I posted this months ago
Code:
System.out.println(“Hello From the Rio”); //Print to RioLog
Just a tool this team has not ever used and I need to get and get them used to using. I’m learning and introducing the team to command based programming and more advanced controls. Thanks for you help and suggestions. With a 15 place qualify and a 7th alliance second pick we help the quarterfinals go three rounds with a close game #2 and #3. If our auto worked could had change the game
Sorry to hear you were having so much trouble, hope that it is resolved for tomorrow.
This won’t help you for this year, and I may sound like I am harping on this, but my team chose to use a hardware selector switch instead of relying on SmartDashboard or other software solutions, for precisely this reason. The drive team appreciated having physical feedback to know exactly what the robot would do. An option to consider for the future.
There is no tomorrow. We will most definitely implement a Dashboard feed back to tell us if autonomousCommand != null before completing the field connected. Weather with a senableChooser or hardware. An issue I will have is trying to test the conditions at home. We had never experience the issue when at home wifi or tethered. The biggest issue I have now with our last autonomous command code there was no selector. In code it was what it was
autonomousCommand = new Auto_02_underLowbarScoreLowGoal();
We code in Java on the robot, and Java on the driver’s station.
We’ve had a LOT of problems using custom network code in the last 2 years. This year we did something way different than last year - we setup a web server on port 443 of the driver’s station. We could never get it working. This weekend we let the FTA’s have complete logs of our stuff in the hope that someone who understands the network architecture can figure out what was going on. The firewall was disabled in every way Windows can disable the firewall.
In the end, we swapped to NetworkTables. Sure, it requires a Labview runtime library just to develop with, we can’t figure out how to get it above 4hz, and it means that without layers of interpreters we’ll only ever develop displays in Java - but it works. We run a separate process from the driver’s station, so it isn’t Smart Dashboard stuff - just read and write to a HashMap by using the NetworkTables framework in your own code.
The knightkrawlers fixed our auto chooser problems and 5996’s by switching us to static. You seem to have done that part right though, did you also uncheck the box under file–>preferences on the smartdashboard that says use mDNS?
Here’s the link they were using but I think you did the static steps right
https://wpilib.screenstepslive.com/s/4485/m/24193/l/319135-ip-networking-at-the-event
I had this happen once. Windows 10 displays a message in the corner “your firewall is disabled”, and if you click it then it seems that it will automatically re-enable it.
On the driver station, or on the robot? If it’s on the driver station… what address are you listening on? If you’re listening on 127.0.0.1, the field setup couldn’t interfere. We use localhost:8888 with no issues.
In the end, we swapped to NetworkTables. Sure, it requires a Labview runtime library just to develop with
No it doesn’t. There are ntcore bindings in C++, Java, and C unofficial python bindings (pynetworktables) and C#.
we can’t figure out how to get it above 4hz
This is by design and internal to the way that NetworkTables does buffering to prevent users from sending too much data. The python bindings have a setting that you can tweak if you really need to. I’m not sure if there was something exposed in ntcore.
and it means that without layers of interpreters we’ll only ever develop displays in Java - but it works. We run a separate process from the driver’s station, so it isn’t Smart Dashboard stuff - just read and write to a HashMap by using the NetworkTables framework in your own code.
You should checkout pynetworktables2js. Both of my teams (1418 and 2423) use it to develop dashboards in HTML/JS, communicating back to the robot over networktables.
Both teams had issues with connecting to the robot during their first events, but after switching all devices to static IPs (robot: 10.xx.xx.2, ds: 10.xx.xx.5), we had zero connection issues.
Following 254’s code from last year (https://github.com/Team254/FRC-2015), we implemented a web dashboard. The FMS whitepaper (https://wpilib.screenstepslive.com/s/4485/m/24193/l/291972-fms-whitepaper) recommends you use 5800-5810 (web traffic leverages TCP).
The dropdowns in the stock dashboards have caused all sorts of headaches this year.
We wanted the Robot code to run REST calls with attached JSON data to the webserver on the Driver’s Station. We tried DNS names and static IP’s. It’s for telemetry, not robot control. We followed as much of 1418’s setup as we could in getting as far as we did, but Network Tables was the implementation for CHSChamps.
No one on my team uses Python, for better or worse. We have plenty of kids who eventually use it during Cyber stuff, but for FRC stuff we stick to either Java or (eventually) Web. I don’t want to get into a language debate - it’s just what our team knows and does. I’ll check out the links you provided though.
Thanks for the correction on ntcore - some of my info is 2nd-hand since I’m not on the programming team. I took a look at a few things, but it’ll take a bit more analysis to figure out where it puts the rate limitation in. If not, maybe next year we’ll do something like Pete Lawrey’s OpenHFT and then dump the results to the web server.