Driver Station Errors

[apalrd]

Most times I encounter a tripping watchpuppy are because a semi-unrelated thing is causing an error every time it runs, and the error handling time is enough to trip the watchpuppy. While running, try probing all of the device refs in Teleop, and see if any are creating errors.

It is also possible that bad communication is causing these errors. The Teleop loop is timed to the incoming packets, so if the packets lag enough then the RobotDrive might not run fast enough.

[Tom Line]

cbilgin, trying checking to see if you are still getting these errors with the robot disabled. The diagnostic is not telling you the problem is with teleop - but in robot main. They are Two different things, and I suspect you're looking in the wrong place.

[Mark McLeod]

Yea, Teleop looks fine.
There is a small error On your Elevator motor output.
I think you meant to use multiple rather than addition of 0.9

[Alan Anderson]

This has nothing to do with your error, but it looks like you have a feature where a joystick trigger makes the robot drive backwards. Is that to make it easier for to control it intuitively when the robot is facing the driver? You might want also to swap the left and right motor signals in that case, so that it turns the way the driver expects it to.

[cilginbilgin]

Originally Posted by Alan Anderson

This has nothing to do with your error, but it looks like you have a feature where a joystick trigger makes the robot drive backwards. Is that to make it easier for to control it intuitively when the robot is facing the driver? You might want also to swap the left and right motor signals in that case, so that it turns the way the driver expects it to.

Our minibot deployment arm is at the back of our robot and it is to make minibot deployment easier for our driver.

Thank you for the correction!

[cilginbilgin]

Originally Posted by Mark McLeod

Yea, Teleop looks fine.
There is a small error On your Elevator motor output.
I think you meant to use multiple rather than addition of 0.9

Actually I summed it with 0,9 because I just dont want elevator to fall down because of gravity.

[cilginbilgin]

Originally Posted by Tom Line

cbilgin, trying checking to see if you are still getting these errors with the robot disabled. The diagnostic is not telling you the problem is with teleop - but in robot main. They are Two different things, and I suspect you're looking in the wrong place.

Is the problem with Robot Main? I didnt even change anything with Robot Main. Should I change Robot Main if yes what should I change with Robot Main?

[dotbran]

I had this problem and I had to change all of the slot values manually in the Open 4 Motor VI - One on each motor and one in the front panel

[cilginbilgin]

Originally Posted by dotbran

I had this problem and I had to change all of the slot values manually in the Open 4 Motor VI - One on each motor and one in the front panel

I didnt really understand what you have done? Where is Open 4 Motor VI? Isnt that enough to have constant slot values and changing slot values from Block Diagram?

Thanks for your help!

[Team 4117]

Rookie team here looking for some last minute help...

After ongoing LabVIEW programming issues/errors we decided to restart from scratch:

1. Deleted all cRIO Robot Projects
2. Installed updates for LabVIEW, Driver Station, & Utilities
3. Re-ran cRIO Imaging Tool
4. Created new cRIO Project and have not changed anything

When wireless we have intermittent communication (program still runs but is choppy) and we keep getting

ERROR <Code> -44061 occurred at "Left and Right Motors" in the VI path: Robot Main.vi
FRC: The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.

I am trying to determine if our wireless is causing this error or if this error is causing our wireless to have issues (sending too much info?)... when we are tethered to the cRIO we don't get this error and we can still receive the wireless camera image on the dashboard with no apparent delay.

Please advise...

[Greg McKaskle]

If you flip to the rightmost tab on the DS called Charts, it contains a chart of various robot things. One is the voltage of the robot battery, one is CPU usage, and the two top ones are the communication round trip time in milliseconds and the lost packets. If spikes there correspond to the choppiness, the issues is either with the wifi environment (too many competing networks on the same channel(s)), a badly mounted radio (too far into the robot, too close to motors), or if it is latency and not dropped packets, it may be due to load of the DS computer or cRIO.

Greg McKaskle

[Team 4117]

Ok so looks like this is definitely a wireless issue. To me it looks like it's both dropped packets and latency (see attached for screenshot of Chart with no robot code).

So question now is how to fix...

Our wireless radio is on the perimeter of our robot and about 5" (nearest edge to nearest edge) from the closest motor. It is only about 3" from our battery and cRIO and only about an 1" from the digital sidecar. It has a short power cable though and would take a significant amount of re-wiring to get it any further...

I looked under network connections (see second screenshot) and it appears to have a pretty good connection (72Mbps) but I am no expert in these things.

I am tempted to hit the reset button on the back of the wireless radio but from what I recall it was a nightmare to configure it the first time and I'd like to avoid that if possible.

Please advise...

[Greg McKaskle]

The only thing that stands out is the 255.0.0.0 subnet mask. I'm not sure that alone will impact the lost packets, but I'd drop it to 255.255.255.0. Next I'd run InSSIDer and see if the channel is really a good one. I'm not sure what the green bars on the Windows control panel mean, strong signal, not much traffic, etc.

Please post any solution or improvements that you find.

Greg McKaskle

[Team 4117]

I just tried logging onto the classmate to change the subnet but I get an error:

"Your system is running low on resources. You cannot log on as a new user. Please use an account that has already been logged on."

I get the same error when trying to log onto the driver station.

Battery is fine and I get same error with power cord plugged in. So confused...

[Team 4117]

Restarting the classmate fixed the "Low on Resources" error but now I'm concerned I have something running behind the scenes.

I changed the subnet but it didn't seem to help.

I'm bringing it over to a veteran team now to see if they can figure it out.