We’ll have the driver station all connected and we drive around the robot and all that. But when we turn the robot off, then back on and connect the laptop to the router again as usual, driver station won’t make the connection. We have to restart the driver station program in order to get a connection. Is this normal? It should automatically detect the connection and enable, right?
It should automatically Disable, but the connection light should go green.
That’s the thing. If I keep driver station on, and turn the robot off and on, the 2077 access point connects, but the Robot Code light and Communication light stay red. It is only when I close the driver station program and re-open it that the lights go green.
Note that we are not using the classmate, just a Windows 7 laptop. I have disabled Windows Firewall and Real-time antivirus. This laptop is capable of connecting to the internet as well as the robot.
Our router is set with an access key. We are using the Dlink DAP 1522.
Anything I can do to troubleshoot this? I believe we have the latest version of driver station.
Sounds like the Driver Station can reach the robot’s DLink, but can’t get round-trip traffic to the cRIO after a reboot.
So the network path is getting confused on the Driver Station laptop.
You might try disabling all other NICs, like the one you’re using for Internet, and checking for excess IP addresses assigned to the wireless NIC connecting to the DLink. Check for excess IPs under Advanced on the NIC window where you check or set the IP address.
Does your driver statio automatically connect to the dlink SSID?
If you go to network connections, right click on the Network with your team number, connect, and click on connect automatically.
Okay, I’ll check for excess IPs next time I get on. Note that we’re only using one NIC, “Wireless Network Connection”, both to connect wirelessly to the school internet and to the robot’s d-link. To connect to the internet, I made a little script on the desktop:
@echo off
:start
for /f %%V in ('netsh wlan connect KM-Wireless') do set TEST=%%V
if %TEST% neq Connection 2>nul (pause|echo+Could not connect to access point KM-Wireless. Press a key to try again, or close this command line window to end. . .)
if %TEST% neq Connection goto start
netsh interface ip set address "Wireless Network Connection" dhcp
Then to connect back to the robot, we simply restart driver station, which automatically sets the static IPs for the NIC and ethernet. (Please note that we haven’t run this batch script, we simply do the procedure I described, and get the problem I described.)
We have access point 2077 set to connect automatically. We do not have KM-Wireless set to connect automatically.
I checked numerous times and there is only ever one IP, no excess IPs.
I actually did get the bug to go away, by switching the auto-start Dashboard in Driver Station to LabView, instead of Java, which essentially disables auto-starting SmartDashboard. We just start it manually now.
The bug comes back in the same way sometimes, though, but the problem occurs fairly randomly. Another similar problem that happens at the same time is that the SmartDashboard will not connect to our Axis Camera. I can load the webpage and find that when SmartDashboard is on, the framerate is a lot slower. But sometimes when the wireless is good, SmartDashboard shows the camera, and driver station works normally. I’m pretty sure its just that both programs are fairly intolerant of wireless network underperformance.
So far I have swapped all the ethernet cables, which didn’t change anything. I also connected the router and axis camera using their wall-power connectors, problem still didn’t change. This eliminates the power source being bad, as well as the ethernet cables being bad. I also connected the laptop directly to the Axis camera via ethernet, and SmartDashboard streamed the camera feed effectively. This suggests a wireless issue to me.
This narrows down to either the laptop or the router. I can’t see how the laptop could be the issue since this problem seemed to start randomly (we had the robot sitting on, and the camera feed was going to SmartDashboard normally, but then all of a sudden the camera feed died on the SmartDashboard. We could still access the axis setup page, but the feed was generally slower. This is also when the Driver Station started to misbehave as I’ve described). Perhaps the laptop has some Windows service that starts routinely and messes some things up, making it seem random, but I doubt it. I think it is most likely the wireless environmental conditions changing and causing network lag, causing Driver Station and SmartDashboard issues.
My next plan of attack tomorrow is connecting the laptop directly to the router via ethernet, with the camera and cRIO connected as well, on the same network. I’ll also try swapping connected ethernet ports. If that works, then it would more emphasize either a wireless connection issue, or (possibly) a laptop configuration issue. If it still DOESN’T work, that would suggest an issue in the router itself, which is what I’d prefer not to see. I’ll also try using a different laptop. If that works better than the other one, that would suggest a laptop config issue.
Has anyone else here had similar experiences to this? Any advice anyone would like to give so far?
Have you throttled the video stream from the camera?
The DLink does have a 7Mb/s bandwidth limit to emulate the bandwidth limit on the real field.
A camera video stream running at full resolution/30fps/no compression sucks up about 15Mb/s.
You’d see an impact on the Dashboard, but not on the drivability of the robot.
The FRC Bridge Configuration tool sets the artificial bandwidth limit as well as Quality of Service to favor command packets over Dashboard traffic.
It is full res and 30 FPS, and I’m not sure about compression. What settings would you recommend if we wanted two camera streams, from two different cameras, through one router?
Oh, and another symptom for the Driver Station is that sometimes it takes over 30 seconds to start up. Yet other times it takes less than 5 seconds. It is always a random file it pauses on when it takes longer.
You can play with the camera settings yourself using the default Dashboard.
http://www.chiefdelphi.com/forums/attachment.php?attachmentid=13851
That way you can see how visually appealing the video stream is as you play with the settings.
It doesn’t give true bandwidth, like transmission overhead, just the bandwidth based on the size of the video itself.
You need to at least hold the combined video stream under 5Mb/s, but the less the better because higher rates start impacting your packet transit times.
Maybe 50% compression and 15fps, but I’d have to play.
Last year we used two cameras, but kept the bandwidth to about 1Mb/s for the combined video streams.
Thanks, didn’t know the default dashboard was capable of that. Is it possible for it to switch between two camera IPs? Or does it only work on the 10.20.77.11 default?
The default dashboard is just a built EXE from the LV template dashboard. If you want two image displays, you would need to make one from the template and drag a copy of some controls, indicators, and a loop on the diagram.
Greg McKaskle
We’ve had this exact same problem, and it’s been driving me nuts because when you close the driver station, the Computer attempts to shut down.
How exactly do I make a new LabView dashboard?
This is the closest thing I could find: http://www.ni.com/white-paper/13757/en
That is unfortunately about a totally different NI product with the word dashboard in the name.
There are a number of tutorials, but perhaps the one to start is the one in LabVIEW itself. Launch LV, and in the Getting Started window there is a tutorials tab, number 6 is about making dashboards.
Greg McKaskle
Thanks, I’ll try it later when I get the chance.
We use Java and Netbeans for our programming. Will WPIlib still let us access inputs and outputs on the traditional dashboard? If so we may just use the normal dashboard this year, since SmartDashboard has usually been finicky with problems like this. I suspect that SmartDashboard is causing the driver station to act strangely like this as well.
Another issue we have is sometimes the router will take a while to connect, and soon say “limited access”. One time we had this issue, and we unplugged the axis camera, and afterwards it worked right away, so lowering the camera settings may be a good fix. Will try this next time I get the chance.
The router takes nearly a minute after power is applied before it will accept wireless connections.
The “limited access” message from Windows is merely complaining that your computer can’t find a route to the Internet on that network interface. That’s normal for a connection to the D-Link on a robot.