Rookie coach needs help. The communication with the robot from the driverstation is inconsistent and in my opinion too dangerous to allow us to drop the robot off the jack stands. The communication on the driver station turns on and off in sparatic intervals. Causing the robot to respond witf a delay. Hard wire connection with cRio is flawless. What could be going wrong? I need to fix this so we can drive the chassis. any ideas??
The two most likely causes are the DS and the code on the cRIO.
On the DS, verify that the CPU load is reasonable. Especially when the DS reawakens from sleep, there are tasks that can be run which cause the CPU load to be 100% for thirty seconds to perhaps a minute or two. For this reason, short sleeps are not a problem, but I’d recommend an end of day shutdown. It is also possible that multiple users are logged in and background apps are loading the CPU.
On the cRIO, you don’t mention a language, but each of the environments has a way to determine the CPU usage on the cRIO. If you are using LabVIEW, go to the Tools menu>>Real Time Module>>System Manager. For the best CPU readings, flip to the VIs tab, disable the Track checkbox, flip back to the Resources tab, disable disk and enable CPU, then press the button to Start Monitoring. This will not tell you what is hogging the CPU, but will tell you if it is occurring.
There are other possibilities, but I’d check these first.
Greg McKaskle
Also, check that your battery is charged, that you have good solid connections on all supply wiring and everything is wired as per the “Robot Power Distribution Diagram”.
It seems simple but, sometimes, this gets overlooked if you are concentrating on software.
Greg,
Im a Real rookie coach. When you say DS i have to go look that up. I will in a second, I am loading from a single laptop that has no other user access. All of the other applications are off. On the class mate no other software was available to the robot communication I believe.
You said,
On the cRIO, you don’t mention a language, but each of the environments has a way to determine the CPU usage on the cRIO. If you are using LabVIEW, go to the Tools menu>>Real Time Module>>System Manager. For the best CPU readings, flip to the VIs tab, disable the Track checkbox, flip back to the Resources tab, disable disk and enable CPU, then press the button to Start Monitoring. This will not tell you what is hogging the CPU, but will tell you if it is occurring.
I am using lab view and have loaded code that was unchanced from the NI code. There are some errors when I run the code even with it being unchanged from NI. The thing that confuses me is when I wire direct to the robot the code errors don’t impeed the robot fucntioning. When you say to go to LabView you mean to run it on the laptop the code is deployed from. Is this correct?
Are there other wireless networks in the area that could be conflicting/saturating the airwaves?
I have even known of locations that actively suppressed unregistered access points, although that’s more likely in a University setting than a secondary school.
I assume you have the Classmate wirelessly connecting directly to the D-Link on the robot per the Rev A setup instructions?
P.S.
When you hardwire the Driver Station directly to the cRIO do you plug directly into the cRIO Port 1 or are you connecting to the D-Link (which is then hardwired into cRIO port1)?
Mark,
Thanks for the response.Yes I did follow the set up per revision A and went step by step as I know little to do things any other way. I even went so far as to repeat the steps several times to make sure I did not miss somethng.
Then I called for help and had help from a few local teams. They were a great help but I did a few things that I truely had no clue what I wad doing from their direction. So there is a bit of concern there.
There school has no wireless network. So that wasnt the issue there. I have one at home were the robot sits with me now and have turned it off. Local neighbors, well they just don’t understand, refuse to turn thiers off for my testing purposes.
The network that I set up has limited connectivity. I assume that is because of the lack of internet, but as a rookie it is PURE speculation!
To finish the P.S. Mark,
When I ran the robot wired it was directly into cRio in Comm1
When I deploy code it was through the d-link
Your local friendly neighborhood networks shouldn’t be a problem, so no need to disturb the peace.
Since everything works fine while it’s hardwired I doubt it’s a code or battery problem.
It could be a bad power connection to the D-Link robot radio.
Try hardwiring from the Driver Station to the D-Link, then the D-Link to cRIO port 1 to see if you still have communication troubles.
That will eliminate, or point to, wireless being the issue.
Just wired in through the bridge. No issue or delays. So it appears that is good then. Kinda hoped it would have been that, I could fix a wire pretty easily. Any other ideas??
i do get errors in the NI code though, there is a 44061 code at “Left and Right Motors” in the VI path: Robot Main.vi
FRC: The loop that contains RobotDrive us not running fast enough. This error can occur if the loopcontains too much code, or if one or more loop sare starving the robot drive loop.
Just to be clear this is the code directly from NI
The code errors in the NI default are common. There are a couple of bugs in it that can be remedied.
There are two NI default frameworks, which one did you select when you created your project?
- Robot Framework
- Robot Framework with Game Code
And are you just enabling teleop mode from the Driver Station?
Now that we know it’s just the wireless portion that’s causing a problem you should probably take a look at the wireless setup on the two ends:
- Driver Station side - is this just with the Classmate?
*]D-Link side - you’ll need to browser to the D-Link and verify the wireless settings.
I have to ask, are you using the power module supplied in your KOP to power the DLink from the regulated 12 volt radio output of the Power Distribution board? You cannot use a normal output of the PD for this purpose. Second question, is your Dlink buried inside the robot surrounded by metal, motors, Crio, wiring? The Dlink needs to be away from such devices so that they don’t interfere with the radio communications.
Sorry to hijack this thread, but I’ve been trying to find way to get the CPU usage on the cRIO. You said its possible with all languages, can you explain how this would be done with C++ or direct me to where I could find out.
prior to the hijack.
I am deploying robot framework with game code
and going teleop from driverstation while testing
Wireless I think is the issue. How to do the checking is new to me. How and where is need.
As for Al’s comments.
Cut the converter off of the d-link and wired it to the location specified in the wiring diagram.
Moved the d-link out of the frame yesterday an is on a desktop away from frame and motors
I’m going to disappear for a while. It’s a three team day, so I’ll be moving from place to place.
While it’s running via wireless and getting the sporadic dropouts, describe what the D-Link lights are doing on the front.
One possible option is to switch from the 2.4Gz band to the 5GHz band.
You can see this referenced in the “How To…” document on page 7.
On the other issues.
Sorry for using the acronym – DS. That stands for driver station. People also use it to refer to the computer and HW elements that the driver station application runs on.
The default NI code had game autonomous added to it at the last minute, and the digital inputs for the IR sensors are used in autonomous independent VI, but are not opened and stored in Begin. If the errors refer to that, you can correct it by opening and storing using the same names. An update will be released shortly to fix some issues not found in WPILib and in in the framework template code.
As for how to check the CPU usage on VXWorks if not running LV – you can use the netConsole or serial connection via null-modem cable and look at the commands at this URL http://touro.ligo-la.caltech.edu/~cparames/CDS/vxWorks_commands.html. I don’t have the WindRiver tools with me, but it may be that “i” gives you the info I was thinking of. If not, ask on the WindRiver forum or google a bit.
Greg McKaskle
Greg McKaskle
My one issue with switching to 5 MHz is that the classmate does not communicate with any above 2.5 MHz so that in itself is an issue.
The 1 light flickers constantly while the power light is on a strong. The AP light is a steady 1 second flash.
I completely removed the Labview from my laptop today and installed it again in hopes to have clean code. I also reformmated the the cRio as well as the D-link.
Not to be a downer but this is getting a little tough on a rookie team. Every coach I have talked to locally appears not to be writting code or deep in this. And the kids are busy writting thier robot code right now. This is not what I expected.
Have the symptoms changed in any way? If you turn on the robot and DS and leave the robot disabled, what happens? Be sure to pay attention to the LEDs on the router and cRIO as sometimes a reboot or power outage can appear to be a comms issue.
Post back with the latest observations and consider phoning the NI support number.
Greg McKaskle
The sporadic response may be a symptom of longer transmit times.
The D-Link status lights sound correct.
Rather than being broken, the wireless might just be adding more delay to the communication between the Driver Station and the cRIO and tripping the Safety for longer periods than the wired operation.
The wired operation may be surer and quicker.
So you might be suffering more from those error 44061’s that you’re also seeing, than from flakey wireless.
To explore that possibility, lets disable that error as a debug step.
In LabVIEW:
- Go to the Begin.vi block diagram (picture 1 below)
- Double-click on the Drive
Open 2 Motor icon and then open the block digram for that - In the middle you’ll see “enabled” feeding a Sfety vi icon - Change that to “disabled” (picture 2 below)
- Build and Run as startup (if you haven’t done this we can walk you through it)
*]See how the robot behaves both wired and wireless
As you test the wireless, with sporadic dropouts, watch the Driver Station Diagnostic tab, in addition to what Greg told you to watch. Tell us about any red lights.
Did you get this working, I have same problem… Connected from driver station to bridge, bridge to crio – then OK…
Set lap top ip to 10.2.23.5, sub net same as bridge, 255.0.0.0
Does Gateway need to be set? set it to 10.2.23.4…???
One thing, setting up bride, asked for Pre-shae key, put what was in instructions, change team name: 0223WPAKEY – not sure if leading ‘0’ needed
we are still not communicating wireless, appreciate support