Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

So we tried doing this same thing with out dashboard and robot. Specifically sending three enum values from the dashboard to the robot. We got this working when we were running live on the robot through labview on a development computer. We would get one of the "The loop containing the RobotDrive code is running to slowly" error every once in a while but the code would function almost perfectly.
Once we deployed the code to the robot ("set as startup" after building), however, we started to get "Watchdog not fed" errors that would stop the code. Once we pulled the UDP receive stuff from the code on the robot, everything started working right. We decided to use the digitial inputs on the driverstation instead, but I would like to figure out what we did wrong in the old code. Does anyone have any ideas why this would have happened?

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

I glanced through the forum posts, but couldn't find how you are doing the UDP. Where was it running? Make sure you build and Run as Startup so that you are running the new code. The behavior shouldn't change between the debug-run and the build-run.

If you don't figure it out, post the code or pictures of it.

Greg McKaskle

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Has anyone managed to solve the problem of the UDP transmission interfering with the normal Driver Station communication?

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

What problem?

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

See, every time we've tried to send information to the robot using UDP, it's hindered the regular communication: The robot will stall during Teleop and Autonomous, the communications light on the Driver station will turn on and off, and occasionally, we'll lose the connection entirely.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Are you sending data too fast? The way I got it working, I had a loop wait timer in the transmission loop, along with no wait timer on the recieving loop, (but having a good timeout value on the recieving loop.) I posted some screenshots of working UDP sending and recieving for the robot a few posts back.

Send
Receive

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Thanks for taking the time to respond. I have added pictures because I am not really sure what we are doing wrong. The robot receive code is in the periodic tasks vi and the dashboard send is in the dashboard main vi.
Right now the image processing is in the same loop as the udp send, but we did separate it from this loop to check if that was slowing down the code, but there was no difference in effect.

Again, the problem is that when we "run as startup" we get enough watchdog errors to make the robot essentially undrivable.


Edit: forgot to note the "larger" sized photo is the send and the smaller is the recieve

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

You're missing a Wait in the second block diagram.
That will suck all the life out of your CPU.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

I haven't memorized the UDP function icons, so I might be reading it backwards, but I think that second diagram is the receive processing. As such, it will only run when a new UDP packet is received (or until the UDP receive timeout occurs, which is 25 seconds by default). It doesn't need a Wait inside the loop, and adding one can actually cause some undesired effects if packets arrive faster than the loop time.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Well we did have a wait in there (30 ms), but while using the debug-run we started to get watchdog errors which had us loose control for a few moments about every 10 seconds. Those errors were more or less random and we had times where they would not happen for about a minute and then they would continuously happen. After taking out that wait we stopped seeing that problem and actually thought we had everything fixed - until we did a "run as startup".

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

I was having the exact same problem and it was driving me nuts, however I think I have resolved the issue. I stopped having driver station interference problems when I used a String-to-IP function fed into the open UDP VI into the net address input. It should match your team IP: 10.te.am.02. Also you should set the UDP Write VI net address to your team IP.

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

That is a good catch, and if we get a chance we will try that, thanks!
My only concern about that is that we were able to send data using our code to the robot so the actual communication was not having problems, and because the open is outside of all loops I don't see how it could have caused the communication indeterminacy/watchdog errors when the communication was working.

We did have the UDP Write VI using our team IP (which we got using the global variable for Robot IP).

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

Thanks for posting these routines. We have used them with slight mods and have our image processing working pretty well.

We are running a modified version of the supplied Rectangle routine. Right now it is running as an independent program. We have the Drivers Station, Dashboard, and our image processing running. Is there a reason or rule that requires that the image processing be integrated into Dashboard? Will FMS know or care that it is a standalone program?

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

UDP traffic is UDP traffic. As long as it's on the right port none of the networking hardware will know what program it came from. I also don't see any rules that prevent you from running whatever software you want on your DS PC as long as it is in addition to and not instead of the DS software (though I would personally recommend against Minesweeper, Solitaire or Pinball)

Re: Transmitting data to the cRIO from the Driver's station via TCP/UDP
 

The only required program is the Driver Station app.
The Dashboard is entirely optional as well as any other programs, such as the Kinect Server. I've run wordpad so I could take notes.