Weird Crio/Programming problem

[mattiej]

Hi! My team has been having a weird problem with our robot. We wanted to build a test chassis to test our drive train, but we have been running into issues. We fixed all of the electrical issues, but now I am having a new problem.

The issue is this: sometimes when driving, the current action of the robot will "stick". If we are driving forward at full speed, the robot will do that forever. Sometimes, jerking the joystick will fix this. Other times, the robot will drive correctly but immediately come to a stop, even if you are driving it forward.

So far, I have tried all that I can think of(and find). We first tried reformatting our crio and reimaging it. This didn't change the problem. I then tried using a default robot mecanum code (with some edits to references that didn't exist). This also did not change it. I then switched to a crossover, then an ethernet cable. Neither of those changed it.

As far as errors go, we get quite a few. We get a few different watchdog expiration codes (excluding the System 1 User 0 state switch code), a radio error code (we were tethered so I didn't think that this made a difference, a 44004 (note positive, not negative) Frc: No robot code (which seems like the problem to me, since we were running robot code), and a -44004 code because we don't have our camera plugged in.

Also, I notice that whenever we connected to the robot, the driver station graph for crio CPU would "dissapear" (I assume this meant 100%).

What are we doing wrong?

[Mark McLeod]

Watchdog errors will cause your robot to stop moving. They are due to a communication loss or slow down between the Driver Station and the robot.
You might have code that's executing too slowly (often due to excess error messages). That'll throw Safety Config errors and stop your motors, just until the next command packet arrives at the robot.

A positive 44004 error is: FRC: The Driver Station has lost communication with the robot (which would cause the robot to halt)

A negative -44004 is an attempt to open the camera twice.

The sticking of the joystick sounds like a code problem. It's possible it could also be a malfunctioning joystick, since it can be fixed by jerking it, but I'd suspect the code first.

The loss of the cRIO CPU graph on the Charts tab is due to a Driver Station bug. It was mistakenly plotted against the 12v scale, so it'll disappear off the top as soon as code begins running. If you look at the log through the Viewer utility it should plot correctly.

Some of these symptoms can be caused by a low robot battery. It'll dip lower when you pour power into the motors.

[mattiej]

Originally Posted by Mark McLeod

Watchdog errors will cause your robot to stop moving. They are due to a communication loss or slow down between the Driver Station and the robot.
You might have code that's executing too slowly (often due to excess error messages). That'll throw Safety Config errors and stop you motors just until the next command packet arrives at the robot.

What would we need to do to fix this? I have safety config enabled.

Originally Posted by Mark McLeod

A positive 44004 error is: FRC: The Driver Station has lost communication with the robot (which would cause the robot to halt)

I've connected both wireless and tether, and I have still gotten this error. My computer is also only running labview and the Driver station. What else could cause this?

Originally Posted by Mark McLeod

A negative -44004 is an attempt to open the camera twice.

Not entirely sure why it is doing this. Since we aren't using the camera, is it okay to just get rid of that code?

Originally Posted by Mark McLeod

The loss of the cRIO CPU graph on the Charts tab is due to a Driver Station bug. It was mistakenly plotted against the 12v scale, so it'll disappear off the top as soon as code begins running. If you look at the log through the Viewer utility it should plot correctly

Ohhhhh okay. That makes sense. Is this Viewer utility in LabView or the driver station?

Originally Posted by Mark McLeod

Some of these symptoms can be caused by a low robot battery. It'll dip lower when you pour power into the motors.

I tried switching out the battery with what I've been told was a fully charged battery. I'll charge up another battery and try again, but with the new battery it didn't fix the problem.

[Cecil]

When you say tethered, do you have it tethered to the D-Link or to the cRIO? It almost sounds like the D-Link is losing power/connection for a second. Do you have the DC to DC converter plugged into a normal 12 volt slot on the Power Distribution Board or the dedicated 12 volt port at the top of the board? Your motors could be drawing enough that it could reset your D-Link.

[Mark McLeod]

If the Safety Config is tripping, then you should see an error message on the Diagnostic tab window eventually. You probably have to scroll back through all the messages carefully.
If you suspect it, then you can Disable the Safety Config, but I'd put the robot up on blocks to test it, so that if it tries to run away it won't get anywhere or hurt anyone.
In fact, I'd put the robot up on blocks until you get this figured out.

Lost communication can also be caused by a poor DLINK power connection on the robot. If you have the robot up on blocks try directly connecting an Ethernet cable between the laptop and the cRIO to test run.

You can use a Diagram Disable structure (same menu as the programming loops) on the camera code or delete it altogether if you don't plan to use it. Code for the camera is in Begin.vi and Vision Processing.vi and both will need to be disabled.

The FRC Driver Station Log Viewer should show up on your Start -> All Programs menu. It got installed with the Driver Station update.

Just check the voltage readout on the Driver Station whenever you see problems.

[katsauga]

is there a chance you have a bad joystick?

[mattiej]

Originally Posted by Cecil

When you say tethered, do you have it tethered to the D-Link or to the cRIO? It almost sounds like the D-Link is losing power/connection for a second. Do you have the DC to DC converter plugged into a normal 12 volt slot on the Power Distribution Board or the dedicated 12 volt port at the top of the board? Your motors could be drawing enough that it could reset your D-Link.

We are directly hooked into the cRIO. We have the D-Link hooked in correctly though.

Originally Posted by Mark McLeod

If the Safety Config is tripping, then you should see an error message on the Diagnostic tab window eventually. You probably have to scroll back through all the messages carefully.
If you suspect it, then you can Disable the Safety Config, but I'd put the robot up on blocks to test it, so that if it tries to run away it won't get anywhere or hurt anyone.
In fact, I'd put the robot up on blocks until you get this figured out.

The robot is already up on blocks. Always test that way after laptop #1 got destroyed by a robot. I didn't see a Safety Config error message, but I will double check.

Originally Posted by Mark McLeod

Lost communication can also be caused by a poor DLINK power connection on the robot. If you have the robot up on blocks try directly connecting an Ethernet cable between the laptop and the cRIO to test run.

We tried the Ethernet cable and still had the same issue.

Originally Posted by Mark McLeod

You can use a Diagram Disable structure (same menu as the programming loops) on the camera code or delete it altogether if you don't plan to use it. Code for the camera is in Begin.vi and Vision Processing.vi and both will need to be disabled.

The FRC Driver Station Log Viewer should show up on your Start -> All Programs menu. It got installed with the Driver Station update.

Thanks!

Originally Posted by katsauga

is there a chance you have a bad joystick?

That's next on the list for testing. But from looking at the Driver Station just now, I did notice that the driver station seems to be returning a ~.07 value on an axis when it isn't even being moved.

[Cecil]

Originally Posted by mattiej

But from looking at the Driver Station just now, I did notice that the driver station seems to be returning a ~.7 value on an axis when it isn't even being moved.

Was the joystick bumped/moved in any way other than its normal position when plugging it in/starting up the laptop? I've run into the problem where it initializes as 0 wherever it is when it is plugged in, making the robot move immediately when the robot is enabled.

[mattiej]

Originally Posted by Cecil

Was the joystick bumped/moved in any way other than its normal position when plugging it in/starting up the laptop? I've run into the problem where it initializes as 0 wherever it is when it is plugged in, making the robot move immediately when the robot is enabled.

I actually typed it wrong. It was a .07 value. But I have replugged it.

[BitTwiddler]

It sounds to me like perhaps the robot is not responding to or is dropping Driver Station Packets.
Do you have many time delays in your teleop vi (I'm assuming you're using LabVIEW)? If so then you may need to move some of your driving code to one of the periodic task vi instead. Good communications with the Driver Station requires that the teleop.vi gets called as often as possible.

[mattiej]

Originally Posted by BitTwiddler

It sounds to me like perhaps the robot is not responding to or is dropping Driver Station Packets.
Do you have many time delays in your teleop vi (I'm assuming you're using LabVIEW)? If so then you may need to move some of your driving code to one of the periodic task vi instead. Good communications with the Driver Station requires that the teleop.vi gets called as often as possible.

We are not using any time delays in the teleop vi. All we are doing is accessing our robot drive and joystick, and using a mecanum drive vi.

[Alan Anderson]

Originally Posted by mattiej

We are not using any time delays in the teleop vi.

Have you added any loops to the Periodic Tasks vi, or have you removed any of the delays in existing loops? Look for a While somewhere that's running unthrottled; such things can eat all the processor cycles and starve the communication task.

[mattiej]

Originally Posted by Alan Anderson

Have you added any loops to the Periodic Tasks vi, or have you removed any of the delays in existing loops? Look for a While somewhere that's running unthrottled; such things can eat all the processor cycles and starve the communication task.

We haven't added any, but I will try removing the existing loops. As fa as While loops go, I haven't seen anything egregious. I'll start hunting though.

[mattiej]

I figured out the problem! At some point in the base code for the Mecanum example, there is an endless loop. Not sure where, but I just switched over to the arcade code it worked for me.