Help! RobotDrive Error in all 3 languages

Technical Programming
1

After having spent countless hours trying to solve this problem, we are now interested in what new ideas people might have towards solving the following problem. Please read through the entire post. I realize that it is rather lengthy, however this is an important problem that could possibly affect other teams.

When we first started the programming, we started with Java as our programming language. While trying to create a simple program, we discovered that while driving, the robot had a tendency to turn towards one side. After spending several hours solving a series of mechanical problems, we still had the same problem. We then began to test the output of the jaguars with our multi-meter. We discovered that one side was outputting approx. 12.5 volts while the other side was outputting approx. 10 volts. Believing that this was an issue with the jaguar firmware, we went to update the jaguar firmware, however have been unable to update the jaguar firmware so far due to the fact that we do not have access to a computer with a serial port outside of our school district (our school district does not allow us access to the necessary computers).

We later made the discovery that there was yet another problem. We decided to test the control circuit of the PWM cables. We discovered that one side was putting 2.27 volts through the control circuit while the other was putting 0.67 through on the other side. This led us to believe that it was not in fact a jaguar problem, but instead a problem with the cRIO or the digital sidecar. After having swapped out a series of different components, we decided to try something different.

Since we still had the electrical board from last year, we decided to run the program on the old electrical board. We made the necessary changes to the board (such as module placement and cRIO imaging) and then downloaded the test program. We discovered that an entire other electrical board had the same problem. After switching out an additional series of parts, we now believed it to be a programming error.

We then proceeded to reduce the program to the simplest program possible. We wrote the following piece of code.

Please see the attached file JavaV1.txt

We then discovered that the program at what seemed to be the simplest level did not work properly.

Discovering that this piece of code did not work properly, we instead decided to try a different programming language. We then proceeded to reformat the cRIO, and prepare a new code sample in Wind River. We discovered that this code had the sample effect as the Java code that we had previously tried.

Please see the attached file windriverV1.txt

Since the Wind River program did not work, we reasoned that the Java and Wind River ran on similar libraries, and were perhaps experiencing the same error. We then decided to try Labview on the robot. We reformatted the robot and deployed the basic template code provided with Labview. However this did not work either, providing the same result as Java and Wind River.

With time quickly shortening, we are in desperate need of some help with this problem. Any and all ideas would be appreciated.

JavaV1.txt (566 Bytes)
windriverV1.txt (1.22 KB)


JavaV1.txt (566 Bytes)
windriverV1.txt (1.22 KB)

2

Did you switch out the power wires? There could be a frayed wire somewhere…

3

We tried both our new electrical board and our board from last year. We did not switch any of the cables between them.

4

Just as a note, after some further testing, we discovered that in Java, by controlling the individual jaguars instead of through a RobotDrive instance, I am able to match the speeds correctly.

5

You didn’t mention if you had calibrated the Jaguars …

6

I am not sure what you mean by calibrate.

7

In the Java example you initialize the RobotDrive object at its declaration:

public class RobotTemplate extends SimpleRobot {
RobotDrive drivetrain = new RobotDrive(1,2);

I’m not sure that’s a good way to do it. The constructor might need some resources that are initialized later in order to work properly. I would move it to the robotInit() method just to be safe.

public class RobotTemplate extends SimpleRobot {
RobotDrive drivetrain;

public void robotInit() {

[INDENT]drivetrain = new RobotDrive(1,2);
}[/INDENT]
}

8

Can you clarify on this more? I assume what you are doing is taking a multi-meter and measuring the voltage on the PWM Signal Wire to Ground. First, this is going to be inaccurate as the PWM frequency is pretty high and your multi-meter may not interpret that as correct, unless you have a true RMS meter. I may be wrong on this point, someone correct me if I am. The better test for this would be to use an oscilloscope and measure the pulse width.

However, this may be a non-issue anyways depending on your electrical and software setup. If you are running the basic tank drive software with all the CIM motors hooked up normally (red-red, black-black) one side will need to be inverted from the other. If this is done in software one side will get a different PWM signal than the other, and this can be easily determined by looking at the speed controllers while driving forwards. If the speed controller led’s for the left side are different than the right side that means they are inverted in the software. Which is perfectly fine.

You didn’t specify your actual drive-train setup, are you guys doing 4wd or 6wd?

I suspect that you have one or more of the following problems: a) You still have binding issues in your drive-train b) Bad weight distribution on your wheels c) Not all wheels contacting the ground.

If you see the same problem in all 3 programming languages using the default code (disregarding many other teams using the default code without issue) the problem is probably not the software. When you drive fully forwards and the speed controllers led’s are constantly on (green or red) that means the software is putting out a full throttle command.

9

We are actually planning to use a 2WD with 4 motors. After further inspection of the National Instruments documentation of the Jaguars, we discovered that to go in full reverse is 0.67 and to go full forward is 2.27 which is the values we were recieveing. We are using a multimeter to test the output of the control circuit. This now leads me to believe that it is no longer a software problem and instead a firmware problem with the jaguars. Does anyone have a suggestion as to how to update the firmware on the jaguars? When I connect the jaguar to the computer, it just reads 0 for everything, but it says that it is connected.

Thank you to everyone who has contributed towards helping us find a solution to this problem.

10

I would add d) drive motors (like CIMS) do not run at the same speeds forwards vs backwards for the same absolute value of PWM request. So many robots have a tendency to have a drift to one side. (lots of threads about that out there in SEARCH-land I bet) Adding a small constant bias solves many of the effects of a + b + c + d.

I’m hacking this in pretty fast, but it should get you going …


#define SIDE_BIAS 0.1   // TBD from experimentation
#define NEUTRAL_DEADBAND 0.17  // maybe less - experiment
.
.
. 
		while (IsOperatorControl())
		{
                       float yStick = stick.GetY();    //as opposed to stick->GetY(); ....not sure
                       float xStick = stick.GetX();

                       if( (yStick > -NEUTRAL_DEADBAND) && 
                           (yStick < NEUTRAL_DEADBAND )   )
                       { // in the Y deadband ... spin only so no bias to spin
                           yStick = 0. ;  
                       }
                       else // translating fwd/rev add the bias to the spin axis
                       {
                           xStick += SIDE_BIAS ; // set sign correctly, here
                           xStick = (xStick > -1.) ? xStick : -1. ; // keep in range
                           xStick = (xStick < 1.) ? xStick :  1. ;
                       }
              
			//myRobot.ArcadeDrive(stick); // drive with arcade style 

                        // using squared inputs has a smoothing effect on handling
                        myRobot.ArcadeDrive(yStick,xStick,true) ; 

			Wait(0.005); // wait for a motor update time
		}

…something like that…

For better drift compensation, try a yaw rate sensor as feedback to a proportional control of the SIDE_BIAS value :wink:

Thanks,
Eric

PS JAG firmware upgrade instructions:

http://www.usfirst.org/sites/default/files/uploadedFiles/Robotics_Programs/FRC/Game_and_Season__Info/2012_Assets/JaguarFirmwareUpdateInstructions02.pdf

11

I doubt it. I would strongly suggest that this is a wiring or mechanical issue. If you flip the PWM connections does the lower output voltage you are measuring follow the PWM signal or stay with the same Jag?

Have you tried measuring the voltage on the input side of the two Jaguars while this condition is occurring?

I think it is likely that the side measuring the lower voltage has mechanical binding and/or improperly terminated wiring or long wire runs and is dropping a greater voltage before it gets to the input of the Jag (and likely dropping more voltage inside the Jag as well if the current draw is higher)

The directional bias mentioned by the previous poster for the CIM motors is a few percent and while it can cause the robot to drift slightly dependent on construction it shouldn’t result in the substantial difference you appear to be reporting.

12

@EricS - Thanks for the code sample. I will take a look. We have tried using the updating manual, but it appears as though our school district does not have the drivers installed for the serial port to work.

@RufflesRidge - We are going to go and try and different things with the Jaguars today including what you have mentioned.

Thank you everyone who as contributed towards solving our problem.

13

Seconding this. Even a few percent bias is enough to be noticeable while driving - something we’ve seen every single year.

If you have an oscilloscope handy, you can actually see what’s really going on:

The Jag outputs a PWM signal to the motor - Essentially, it never gives the motor 10V, or 8V (unless that’s what your battery is at). Instead, it’ll oscillate between a high and low voltage, and the width of the pulses averages out to be 10V, or 8V, or whatever you want.

When hooked up to a motor, the motor essentially does the averaging for you. So if you hook the scope or a multimeter up to a Jag with a motor attached, your going to see the output voltage you expect for the speed its going. On the other hand, if you remove the motor, you’ll see the actual square waveform on the scope.

We’ve done this demonstration on our team (we were fortunate enough to have an old scope donated last fall by our primary sponsor). It’s very clear that for the same speed forwards and backwards, the waveforms are simply inverted images of each other.

The issue comes with the motors - they have a forward bias. In other words, they prefer to run forwards. As a result, you’ll see the robot drift to one side, since the motors running in reverse are running slightly slower.

Don’t believe it? Here’s something any team can do with what came in the KoP:

  • Hook up the nice rotary encoders we got from US Digital to 2 CIMple boxes.
  • Hook a motor up to each CIMple box.
  • Place some sort of load on the output shaft of the CIMple boxes, (a flywheel, a pully lifting a weight, something). We don’t want to just let these run at free speed with no load.
  • Run the motor leads together, but switch polarity - red from one motor meets black from the second motor, and vice-versa.
  • Hook the encoders into your digital side car, and that up to the cRio.
  • Set them up in code to read out the speed or distance.
  • Hook the CIM motor leads directly up to power, with no speed controller between them
  • Run the whole thing, and look at the encoder output - you should see that one is running faster than the other!
14

Are you using the same type of jaguar on both sides?

15

I think that we have solved the problem. On our robot, we have 16" drive wheels. We built a second frame today from the KoP and discovered that it drives very smoothly and very straight when you are only using 6" wheels.

We continued extensive testing on the jaguars and discovered that the jaguar tends to output more power going in reverse than going forward. While this is not a problem with the standard 6" wheels provided, it does present a problem when you have 16" drive wheels and casters on the front. This will likely have to be a programming fix unless anyone has any other ideas because it will be a matter of limiting the reverse power down to what the forward power is outputting.

We believe that we have found the other issue. While trying to drive a couple of days ago, we discovered that one side would stop while the other would keep going full throttle. This problem only seemed to present itself when the robot was pushing against something (ie. a person). We now believe that the gear box could have been assembled incorrectly and is therefore causing issues when the motors come under load.

I will add new information as more is discovered tomorrow.

16

You may want to try recalibrating the Jaguars. The calibration procedure allows you to readjust the Jaguar’s response to input signals, allowing you to avoid transforming the signal in code (which I suspect is the fix you may attempt to implement). Standard FRC applications generally do not necessitate recalibration, but given the extreme nature of your application this may come in helpful. For directions, see pages 13 and 14 of this document. “Full-forward signal” and “full-reverse signal” refer to throwing your joysticks forward and backwards.

Note that the issue may not necessarily have been an incorrectly assembled gearbox, but an inappropriate gearing. I noticed you posted on the thread, but just to reemphasize the point, see this post.