Autonomous chooser not working when connected to the field

[cpapplefamily]

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.

[nickbrickmaster]

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.

[virtuald]

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.

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.

[Deetman]

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.

[cpapplefamily]

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.

[cpapplefamily]

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.

Sorry forgot to answer we Java command based.

[cpapplefamily]

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 ();
}

[euhlmann]

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.

[RufflesRidge]

Thinking about adding the line


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.

[MamaSpoldi]

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.

[alst]

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.

[cpapplefamily]

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
http://www.chiefdelphi.com/forums/showthread.php?t=141684
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

[GreyingJay]

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.

[cpapplefamily]

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();

[JesseK]

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.

[minutebot]

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.

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

[virtuald]

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.

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.

[virtuald]

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.

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++ (https://github.com/PeterJohnson/ntcore), Java, and C unofficial python bindings (pynetworktables (https://github.com/robotpy/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 (http://pynetworktables2js.readthedocs.org/en/latest/). 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.

[mwtidd]

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.

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.

[JesseK]

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.

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 (https://github.com/peter-lawrey) and then dump the results to the web server.

[virtuald]

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.

Oh that's interesting, I've not ever tried connecting to the DS from the Robot. I realize that FIRST states that various ports are bidirectional, but I would imagine that TCP connections from the robot to DS aren't done very often... I'll ping Kevin and ask him if that should work or not.

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.

No language debate intended. :)

The nice thing about pynetworktables2js is that although underneath the hood it uses python, to use it to create a dashboard you really only need to know HTML/JS and how to run a python script. However, it sounds like it isn't really what you're looking for either, as you wouldn't be able to write anything to disk without writing some python code.

[Thad House]

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 (https://github.com/peter-lawrey) and then dump the results to the web server.

The limitation is pretty easy to find and remove from ntcore. However, in its current state you need to be careful. If you remove the rate limitation, (which is currently sending every 100ms minimum), you run the risk of overusing the network bandwidth and running into the 7mbps bandswidth limit. This is especially the case if you use many NetworkTables variables and update them often. But this would be the case if you ran your own networking code as well and send data too fast.

[JesseK]

Very cool if you can help us solve this. It was a common way to execute a few different things, and write all of the data to disk on the driver's station.

Here are the streams of data through the architecture. Note - Node.js also splits off a MongoDB write of the data it receives:
Robot Data: RoboRIO -> FMS Network -> Node.js on D/S -> Java or Web GUI
Vision: Camera Image -> FMS Network -> Vision Process on D/S (Java) -> Node.js on D/S -> FMS Network -> RoboRIO
Autonomous selection: Java or Web GUI -> Node.js on D/S -> FMS Network -> RoboRIO

I'm not sure if everything is pub/sub, or if some things just poll the node server for the 'latest' data when it is needed. I do know that they had all three of these working at the school and in the pits, but not on the field since the RoboRIO could never get to the Node server on the laptop.

We had re-try logic in the RoboRIO, Node.js hardening for sudden stop/starts of connections, CORS, etc. We took the system through the flow of Power the untethered robot on Ensure official FRC Driver's Station application is running already Ensure Node webserver had no errors THEN connect tether from robot to D/S Wait for official D/S application to get comms Launch our Java process (contains Vision, Auton Selection & Telemetry stuff) Select autonomous after camera connects and hit 'Push to Robot'

I don't remember for sure if the exception on the RoboRIO side was "Connection Refused" or one of the other socket/network-related errors. I can ask though. FWIW, total network bandwidth using a 15hz update rate on telemetry and a 30fps rate on the camera (320x240) was about 3.5Mbps.

[virtuald]

That sounds like a reasonable flow of operations... If everything was a static IP, that should work... I bet they're blocking outbound connections on 443. Did you try different ports instead of 443?

Also, I misread what you said earlier, I read "4k hz" instead of "4hz". You should be able to get at least 10hz out of ntcore, and 20hz out of pynetworktables. I haven't really benchmarked either of them recently, sounds like something someone could do.

[ShinyShips]

We also had issues with SmartDashboard during our time at the MAR Bridgewater-Raritan event. Our SmartDashboard just would not connect to the field and the match had to be played without our autonomous. From what I remember it wasn't just us either.

We decided that we didn't want to rely on SmartDashboard, so we switched to a wheel selector (Don't actually know what is called, will find out tomorrow). We wired it to three DIO ports and using binary we select our auto. That way when we set up the robot we just move the wheel to the right number and don't have to worry about it.

[virtuald]

I haven't really benchmarked either of them recently, sounds like something someone could do.

Of course I was curious, so I had to write something. :)

I added a benchmark script (https://github.com/robotpy/pynetworktables/blob/master/samples/benchmark.py) to the pynetworktables samples, it should be pretty trivial for someone to port it over to Java/C++ et al.

In it's default configuration, I got around ~19hz running on localhost. I expect that my methodology isn't perfect, but that number is around what I would expect, and varying the write flush period also varied the latency.

I would expect a similar test of ntcore in its default configuration to be around 9-10hz. This doesn't reflect an 'actual' performance difference between pynetworktables and ntcore, but rather just a different default value for the update rate (I chose 50ms, they use 100ms).

[JesseK]

That sounds like a reasonable flow of operations... If everything was a static IP, that should work... I bet they're blocking outbound connections on 443. Did you try different ports instead of 443?

Also, I misread what you said earlier, I read "4k hz" instead of "4hz". You should be able to get at least 10hz out of ntcore, and 20hz out of pynetworktables. I haven't really benchmarked either of them recently, sounds like something someone could do.

Initially the port was 5800 (http://www.chiefdelphi.com/forums/showthread.php?t=145940), but since it was a web server someone thought it would make a difference to put it on 443. Not sure why 443 over 80, but I wasn't around for that decision so there may be more to it.

Around this time last week someone on the programming team said they clocked Network Tables at 4hz - it matters at the moment since that's how vision sends parameters back to the robot. I'll examine how they benchmarked in more detail then. 10Hz is more palatable for post-match analysis, but in the shop I'd like to bump it higher so we can track some of the sensor outputs better.

Thad, I'll look for the rate to remove it. Thanks for the tip!

[Greg McKaskle]

Does the ntcore implementation have a flush command? This is a good way to keep a relatively low rate of transmission, but ensure that when you want lower latency, you can do so.

And just to confirm what was said earlier, there have always been different, but compatible network table implementations. Unless you are using the LV implementation, you do not need the LV runtime engine. The Java and C++ ones are now a common implementation.

Greg McKaskle

[Thad House]

Does the ntcore implementation have a flush command? This is a good way to keep a relatively low rate of transmission, but ensure that when you want lower latency, you can do so.

And just to confirm what was said earlier, there have always been different, but compatible network table implementations. Unless you are using the LV implementation, you do not need the LV runtime engine. The Java and C++ ones are now a common implementation.

Greg McKaskle

There is a flush command, but it is also limited to a update rate of 100ms. The issue with making data transmit faster is that most robot code updates dashboard variables every 20ms or faster in the main robot loop, and if you were to run a flush it would send all that data even if you only expected to send a few variables. There is no current way to only send specified keys faster.

[tr6scott]

We are a labview team, and years ago we had issues with making selections on the dashboard, make it to the bot, for auto selections. The fix we implemented back then, and still use today, is that we use joysticks to make the selections, and the dashboard only displays the value. We put the code for the auto select in the disabled state. This forces communication path to the bot be working, for the selection to work.

Like I said we are Labview, but thought that this maybe a simple workaround to make sure the robot is going to run the right code.

[scca229]

One thing to remember when setting static IPs that I didn't see in the thread is that the subnet mask is 255.0.0.0 and not 255.255.255.0 that you may be used to using elsewhere. This is classful addressing where the 10.0.0.0/8 RFC1918 network is being used.

[gerthworm]

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

[Tom Bottiglieri]

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 ended up ditching the HTTP-over-field-wifi solution in favor of Network Tables as last year we had a bunch of connectivity issues on the field, especially when it came to Web sockets.

We now use a python->js gateway and our web app talks to a local server running on the laptop, which in turn talks networktables to the robot. It seems reliable. We also do some of the things mentioned in this thread like echoing the selected auto mode to another control and showing a robot generated timestamp to validate connectivity.

[mwtidd]

We ended up ditching the HTTP-over-field-wifi solution in favor of Network Tables as last year we had a bunch of connectivity issues on the field, especially when it came to Web sockets.

We now use a python->js gateway and our web app talks to a local server running on the laptop, which in turn talks networktables to the robot. It seems reliable. We also do some of the things mentioned in this thread like echoing the selected auto mode to another control and showing a robot generated timestamp to validate connectivity.

I had heard through the grapevine that you had changed your approach to use the networktables.

I really wanted to be able to leverage object serialization so I continued on the road you guys started down.

We were able to side step a lot of the FMS network issues by taking slightly different approach on the general network architecture. We have an onboard laptop that actually runs the server and acts as the middle man. That way the FMS doesn't interfere with communications between the Rio and the Auto Manager. Basically when a socket is opened we send the latest selected auto, so just declare the auto while you're in queue and you're should be good to go.

If the drive team needs to, they can change the auto from the DS via a web dashboard, and the server can broker the change to the Rio. As you suggested though, this can often be a headache because of the FMS wifi setup.

We actually leverage this same general architecture for generating trajectories on the fly and for vision processing as well. Being able to use Jackson or Gson for object serialization makes life sweet when programming in Java. It made re purposing the general idea for multiple purposes fairly straightforward.

[MamaSpoldi]

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

We use this same procedure as well (basically) and I agree that the feedback is essential to providing assurance to the drive team that it is functioning. However, when it was not working (due to the previously mentioned firewall issue and possibly fixed also by using static IP addressing) although they knew it was not working they could not really do anything to fix it. :(

[Greg McKaskle]

Regarding Flush:
I put flush in the LV implementation from the beginning so that camera code results or other potentially time sensitive values could have minimal latency. Rather than a write through where you are more likely to have inconsistent values, I chose to simply goose the timer and transmit all pending updates immediately instead of waiting for up to 99ms to transmit.

I didn't limit how often they could call flush and I'm not aware of an issue caused by it. As you mentioned, most values are updated at 50Hz, and that isn't much bigger than 10Hz. So if a user flushed each teleOp, they have only affected bandwidth by 5x at most. Also, only modified values are transmitted. I also allowed the user to specify how often their client or server waits to transmit updates. It defaults to 100ms and I haven't really heard of anyone using other values. For most NT stuff, 10Hz is fine.

By the way, the auto chooser for LV has its own rough edges. I'll document them here.

The selector presents all strings written to it within Begin.vi. Sometimes users don't find that initialization spot.
On selection, it writes the selection to the robot. But if the robot writes the value, it doesn't update the dashboard selector.
If the user builds a custom dashboard, they can change the default value of the selector, but the network table value isn't transmitted until it is changed. They would want to write the variable once anyway.

Hope to make it smoother next year.
Greg McKaskle

[cpapplefamily]

Sorry to hear you've been having issues. We had a couple mysterious, non-reproducible issues. We've taken the following mitigation tasks:

1) Poll Smartdashboard (via getSelected()) every half-second during DisabledPeriodic()
2) Write the present auto mode number seen on the robot back to a different indicator on Smartdashboard (which provides feedback that the robot has received changes in mode)
3) Drive team actively selects a new mode every robot boot, and double checks that it's acknowledged. No OK until we confirm correct auto is going to be executed. Restart Smartdashboard or reboot robot if needed.

It's held up well enough for two regional so far....

This was the approach I was going to look at. Anyhow after some futher investigation the last Autonomous fail was not a software issue after all but more a series of events that lead up to this fail. Almost like the show why do plane crash? because a ground crew forgot to put the widgit in the gizmo on the last scheduled service 3 month prior.

In our case match one ran as expected but some time during the match the pinball Choo choo was hit and the escapement jammed.

Our Auto sequence is this:

1 Reset pinball if not on switch
2 open claw
3 close claw
4 lower wrist
5 drive under low bar
6 spin 90 deg
7 strafe to castle wall and raise wrist to fire angle
8 fire ball

Match 2 we observed the ball was never fired but it must had released and the cam came off the reset switch. (no step 8)

In the tie breaker step one never finished because it was jammed (observed in the pits when our tears finally dried). The turnaround time is so fast during elims there was no reset/test time in the pits.

We further proved this theory by looking at the driver station log files and observed the PDP currents for the Pinball, claw and wrist. In match one the pinball was already set on step 1 so no current resisted till step 8 on that channel.

In match 2 the pinball fired but is hard to tell if it rest

In match 3 we see when Autonomous starts the pinball channel goes high current, looks to trip the breaker, rest and autonomous is over.

If you have not ever look at these log fills ( I never have) do so look at a normal match, look at a match that did not go so well. I now know to plan if a command does not Finnish in a reasonable time it maybe best to time out and move on.


addSequential ( new my_Command , timeout)