Running the Motors Backward in WindRiver & cRIO Freezes

[kyungjin]

In order to fine-tune and test things, I was playing around with some of the motor control code and I kinda ran into this...

Jaguar1->Set(1.0);
This set of code worked and drove the motors forward at 100% power.

Jaguar1->Set(-1.0);
This set of code didn't work and whenever this function was called upon (I used buttons to control this), it would just ignore the code.


Also, for some reason, the cRIO sometimes locked up and froze, running the last set of processed instructions and refusing to run anymore. For example, I might be driving the bot's left wheels when the cRIO freezes. In that case, the cRIO refuses to take any other instructions and keeps powering the left wheels at the same speed until either the power is pulled or the Disable/Enable switch is toggled. I've reflashed this unit many times and tried tweaking the code, but nothing really worked. Anyone have the same problems or is this some kind of hardware defect?

[Bongle]

Here are my ideas:
1) You've got a jumper set on a jaguar that prevents it from going backwards. Try looking at the jumpers on the right side of the jaguar (marked F and R). They should both have jumpers on them. If it still doesn't work, try replacing the Jaguar. We had the same problem this weekend when a motor would only run in reverse.
2) Your battery is low and causing your cRIO to act funny.

[Brian C]

While I admit to being more familiar with Victors than Jaguars the controller may need to be calibrated. This is the procedure directly from Luminary Micro's information:

CALIBRATION
PROCEDURE
To calibrate the servo-style PWM input for a
specific range, connect a PWM source, then:
1. Hold down the USER switch with a
straightened paperclip.
2. After 5 seconds, the LED flashes Red and
Green to indicate Calibration mode.
3. Instruct the controller to send a full-forward
signal.
4. Instruct the controller to send a full-reverse
signal.
5. Instruct the controller to return to a neutral
signal.
6. The LED will flash Green and Yellow to
indicate a successful calibration.
7. Release the USER switch.
The MDL-BDC samples these signals and centers
the speed range and neutral position between
these limits. A calibration failure will be signaled if
an out-of-range signal is detected.

Or if you're looking to have a motor go in an opposite direction from the joystick input as in tank drive where one motor needs to be in reverse when driving in one direction. You can simply reverse the wires on the M+ and M- terminals from the motor.

[kyungjin]

Hey, thanks for the quick replies.

I'll be sure to try both of the solutions when I get to school in a few hours.

For the cRIO issue though, I don't think it's the battery that's causing it to act all weird. I don't remember the battery ever dipping below 11V and this is a reoccuring issue, so I'm pretty sure that's not the case... Anyway, I will look into the battery. In the meantime, do you know of any possible case/solution where the cRIO will act the way it does?

[Kingofl337]

Repeat the process tethered and see if the issue goes away. Also make sure you have the gaming adapter in tne filtered 12volts.

[kyungjin]

I think everything is hooked up right and the jumpers seem to be in the right places...

Here's some other things I've noticed...

The lights on the jaguars and victors seem to flash (sometimes green other times orange) when this occurs. Also, when we connect it up to the console (we're using the SimpleTemplate project), it says something like...

FATAL ERROR: Unable to access allocated resource in Resource.cpp

... or something like that... I can't remember what it exactly says...

This seems to be a major problem plaguing us... We can't even get this thing to run reliably for more than 30 seconds...

[Bongle]

The lights on the jaguars and victors seem to flash (sometimes green other times orange) when this occurs. Also, when we connect it up to the console (we're using the SimpleTemplate project), it says something like...


The lights on the victors jaguars mean a few things:
-Fast flashing green: PWM signal says "partial power forward"
-Fast flashing red: PWM signal says "partial power reverse"
-Solid green: PWM signal says "full speed ahead"
-Solid red: PWM signal says "full speed reverse"
-Solid orange: PWM signal says "neutral"
-Slow flashing orange: PWM signal not present (can happen when the cRIO is booting, and when the PWM signal is unplugged)
-There's on other that indicates an error, it might be fast flashing orange but I'm not sure.


We get that fatal error thing every time we boot too. We haven't investigated, but it doesn't seem to affect our robot's performance.

[kyungjin]

For us, the Fatal Error constantly repeats until we disconnect the system... I'm not sure how "normal" this thing actually is...

[Alan Anderson]

FATAL ERROR: Unable to access allocated resource in Resource.cpp

I think that's something you should ask National Instruments about. I'm not up to speed on how the guts of the C++ libraries work, but it sounds like it might be reporting a FPGA problem.

Or you might just have a program bug that tries to connect a gyro to an unsupported analog pin...

[kyungjin]

Well... This seems to be happening with or without any other sensors plugged in (just the basic setup of the benchmark test with some connected motors).

This awful cRIO has been giving us nothing but problems... ugh...

[Greg McKaskle]

If your cRIO is freezing, hook up a null-modem serial cable and use hyperterminal or another terminal program to see the diagnostics from the kernel. It will often tell you what is wrong, or at least give you info so that people can help.

If you truly think you have a problem with the cRIO, try isolating it. Reimage it to the latest image, make sure it is a fresh battery with nothing else hooked up that doesn't need to be, and run an example program. If that crashes, freezes, or misbehaves, contact NI tech support by phone.

If it doesn't, then start adding things back on somewhat slowly.

You aren't going to get this debugged without more isolation and more information.

Greg McKaskle

[bomber7]

I know this thread might be a little dead, but I think I might know the solution.

If you access the 'raw' values of the joysticks you get -1 to 1 ( 0 is stop ), if you access the 'raw' values of pwms you get 1 to 254 (128 is stop)!!! so 1 WOULD run your motor full speed, while -1 would be invalid.

Try setting it to 254 (not 255) and seeing if you still get the error.

I'm pretty certain the above applies for setting raw values on the pwms, I am not sure if it is true for Jaguars.


...............
Edit: On second thought, after reviwing the relevant source files of the WPI library I find it unlikely that the above is true.

[yarb65]

I have the same problem and I have used both Jags and Victors. The RIO is not freezing. The motor just will not reverse when using a button. Works great when using x,y,axis.

[Analog]

Re-flash and power cycle.

[kyungjin]

I did in fact stumble upon finding how to run the motors in reverse.

For sake of discussion let's assume that we are trying to make a Jaguar motor called wheel in port 3 go half speed backwards...

For some reason, if we code it like this, the motors only accepted forward values, thus doing nothing when going backwards:

Jaguar Wheel = new Jaguar(3);

Wheel->Set(-0.5);

I was experimenting with the code in the WPI library and found that the correct way to set motor speeds or use any other functions for that matter was:

<Object Name>.<Function Name>(<Parameters>);

Therefore, the above example would be coded something like this:

Jaguar Wheel = new Jaguar(3);

Wheel.Set(-0.5);

... where Wheel is your object name... Set is your function name... and -0.5 is your parameters (as specified in the WPI library function for setting motor speeds).

I hope this solved the problem for you. If not, it could be a hardware issue (maybe check to see if your Jaguar or Victor has jumpers that allow forward/backward movement).

- Daniel

[kyungjin]

Oh, and as the freezing cRIO...

It seems to happen when the cRIO is outputting messages to the console (Target Console). The way I see it, there is significant lag (about half a second) between values inputted into the cRIO (for example joystick values) versus values outputted from the console on your computer using printf commands. This leads me to believe that the cRIO freezes all operations trying to send values when the processor gets overloaded (because the values outputted are too slow to match the values inputted) on the cRIO and thus cannot send data as quickly to the DSU. In either case however, it works fine whenever the robot is set to run by itself (without the target console).

For us, the freezing still happens... It works for maybe 5 to 15 seconds at a time, more or less, but it's still a valuable source of data collecting and error correcting.