Comms/FMS Problems
 

Our team was having a comms problem recently at the Pittsburgh regional.
Info:
Labview
CAN Jaguars
Driverstation pc runs in windows 7

During one of our practice matches, autonomous was functioning fine. However, right when we started teleop we then lost comms to the cRIO but still had the camera feed.

In the pit we found out that if we deployed code, and ran code, the robot would drop comms right after given a command. If we stuck code, power cycled, and then ran the code without deploying, the robot operated fine. However, we did not and will have a chance to test if the code will work with FMS before our qualifying matches.

Obviously, we are concerned that this will affect our qualifying performance, so it would be great if anyone had a theory on whats going on?

Re: Comms/FMS Problems
 

does the default code have the same issues? (that rules out many programming issues if default code fails too)

Do you have any sensors unplugged?

does it still fail without the camera?

what camera settings (FPS, resolution)

Re: Comms/FMS Problems
 

I do not know the cause but a safe thing to always check are the wire connections and WAGO connectors for the cRIO secure and tight. If it is loose the cRIO power could be resetting.

Re: Comms/FMS Problems
 

So I am a programmer on OP's team

First off thanks a bunch for the responses already

We're pretty sure its not an electronics issue, since as we mentioned before, if we reboot w/ stuck code it works fine. We even managed to test our climber (which isn't too gentle) with this stick/reboot method and it was completely fine.

This testing of the climber also happened w/ the camera on, so we're pretty sure it isn't a camera issue and the bandwith its using is aound 3.4mb/s out of our 7 so we dont think its bandwith either

The real puzzle is why the code wont work from a deploy, but will work after we stick and reboot.

Re: Comms/FMS Problems
 

Can you enable netconsole and look at the output when this happens?

Re: Comms/FMS Problems
 

Firstly, what on earth do you mean by stuck/stick code?

Secondly, try using Netconsole and see what output you get when you run the command that breaks things. Also look at what diagnostic messages you're getting when you run that command. That info will help troubleshoot the problem.

Re: Comms/FMS Problems
 

You should be running the DS practice match option in the pits to try reproducing the issue.

Re: Comms/FMS Problems
 

Stuck code is basically a description for the process of building/compiling the code, and then setting it to run as startup on the cRIO (the communications issue seems to pop up less often when we run the code that's already on the cRIO whenever we start, when compared to deploying/running code from a computer to the cRIO).

Netconsole seems useful, I will look into it, thanks.

Another issue that may factor into this is possible concurrent modifications to the Jaguars, as we are looping reading inputs and setting outputs in different loops. I don't exactly know what the Jaguar is doing on lower layers of software, so to what extent this may affect our issues is unknown.

Re: Comms/FMS Problems
 

Have you run with the Driver Station in "Practice" mode?
This simulates the field conditions by running in Autonomous then moving into Teleop.

It wasn't clear to me from the earlier post if you have ruled out the possibility that the problem only occurs when you leave Autonomous (e.g. on the field) rather than starting from reboot in Teleop (testing in pit).

In other words, what Marc said more concisely :)

Re: Comms/FMS Problems
 

Running with Front Panels open can significantly affect the CPU Usage an consequently the timing of your VIs. When combined with usage of the CAN Bus, running from the PC may be causing CAN timeouts. These timeouts trigger errors which are computationally expensive to process, leading to more errors resulting in never being able to communicate with your Jags.

Just a theory, but I would check the Diagnostics tab of the DS and the cRIO CPU Usage on the Charts tab in addition to the NetConsole suggested above.