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

[PSHRobotics]

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?

[Greg McKaskle]

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

[Pirate programe]

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

[Alan Anderson]

What problem?

[Pirate programe]

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.

[Bendito]

Originally Posted by Pirate programe

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.

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

[PSHRobotics]

Originally Posted by Greg McKaskle

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

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

[Mark McLeod]

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

[Alan Anderson]

Originally Posted by Mark McLeod

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

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.

[PSHRobotics]

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".

[Alex698]

Originally Posted by PSHRobotics

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".

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.

[PSHRobotics]

Originally Posted by Alex698

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.

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).

[rwood359]

Originally Posted by Bendito

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.

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?

[RufflesRidge]

Originally Posted by rwood359

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?

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)

[Mark McLeod]

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.