How to get maximum output from a Jag?

[Thundrio]

We are using bicycle wheels on our robot this year (ironically to make crossing the barrier easy), but we are having difficulty crossing a replica of the barrier in the center of the field. When we apply full forward using RobotDrive() (java, arcade drive, 4 motors), it gets the front wheels over the ramp and cuts out when the bottom ones hit the ramp.
We are using 4 black Jaguars updated to firmware 101 and connected with pwm connections. Our mechanical lead has done the math and says the four cim motors we are using should be able to output more power/torque(not sure if I'm using the right word) than we are getting. One of our mentors believes this is because we need to ramp up the speed over a period of time, which should let it cross the barrier. We tried switching the jaguars to automatic ramp mode, which did not help anything. Afterwards we reset it back to manual ramp and using bdc-comm tried to set the ramp values on the jags to 1000, but realized the value reset to 0 when the robot was powercycled (and after we manually changed the values, my code couldn't move the jags until after a powercycle)
Now the mentor believes that it is something in the RobotDrive/Jaguar wpilibj code (which I showed him) that is causing the ramp rate to reset, or to cause the robotdrive to not give the maximum output. As programming lead I explained that the jaguar will only accept values from -1 to 1, and by my understanding full forward sends the maximum output (I tested this by making a button that when pushed sent a value of 1/-1 to all of the Jaguars, which gave the same effect as full forward). My question is are we actually able to get more out of the Jaguars than just using RobotDrive() (without using encoders/CAN/PID loops), and if so how.
Also a quick wpilibj question if anyone can answer. I proved that I was sending the maximum value to the Jaguars by assigning them to a button and outputting the resulting speed using .get(). however I do not know how to read the Jaguars values when using robotdrive (if this is possible). When I create Jaguar objects that are assigned to the same ports as specified in RobotDrive, it will not run.

Any help on this would be great.

tyvmia

[artdutra04]

Can you post a photo of your robot? It sounds like the problem may be a mechanical problem from an inadequate drive train gear ratio. This would cause the CIM motors to run on the wrong side of the power curve, which would cause too much current draw and a tripped Jaguar over-current protection.

[Daniel_LaFleur]

We are using bicycle wheels on our robot this year (ironically to make crossing the barrier easy), but we are having difficulty crossing a replica of the barrier in the center of the field. When we apply full forward using RobotDrive() (java, arcade drive, 4 motors), it gets the front wheels over the ramp and cuts out when the bottom ones hit the ramp.
We are using 4 black Jaguars updated to firmware 101 and connected with pwm connections. Our mechanical lead has done the math and says the four cim motors we are using should be able to output more power/torque(not sure if I'm using the right word) than we are getting. One of our mentors believes this is because we need to ramp up the speed over a period of time, which should let it cross the barrier. We tried switching the jaguars to automatic ramp mode, which did not help anything. Afterwards we reset it back to manual ramp and using bdc-comm tried to set the ramp values on the jags to 1000, but realized the value reset to 0 when the robot was powercycled (and after we manually changed the values, my code couldn't move the jags until after a powercycle)
Now the mentor believes that it is something in the RobotDrive/Jaguar wpilibj code (which I showed him) that is causing the ramp rate to reset, or to cause the robotdrive to not give the maximum output. As programming lead I explained that the jaguar will only accept values from -1 to 1, and by my understanding full forward sends the maximum output (I tested this by making a button that when pushed sent a value of 1/-1 to all of the Jaguars, which gave the same effect as full forward). My question is are we actually able to get more out of the Jaguars than just using RobotDrive() (without using encoders/CAN/PID loops), and if so how.
Also a quick wpilibj question if anyone can answer. I proved that I was sending the maximum value to the Jaguars by assigning them to a button and outputting the resulting speed using .get(). however I do not know how to read the Jaguars values when using robotdrive (if this is possible). When I create Jaguar objects that are assigned to the same ports as specified in RobotDrive, it will not run.

Any help on this would be great.

tyvmia

What wheel size and what gear ratio are you using. Sounds like you are tripping the breakers from overcurrent.

[Thundrio]

That's what my mech lead says now I showed this thread to him. He says he didn't know the Jaguars tripped from overcurrent (which explains everything according to him). Now he wants to use victors for driving instead.

I love being a programmer =)

[Daniel_LaFleur]

That's what my mech lead says now I showed this thread to him. He says he didn't know the Jaguars tripped from overcurrent (which explains everything according to him). Now he wants to use victors for driving instead.

I love being a programmer =)

I don't think that'll help because I believe it's the snap action 40A breaker thats tripping.

The reason I believe it is tripping is because your gear ratio is too low for the size wheel you are using ... thus my earlier question as to your wheel size and gear ratio.

[Thundrio]

20 inch tires and he says the gear ratio is "big".

But the reason he says he doesn't think its the PD board is we had our mentor who put a "ring thing" (yes its a technical term, it was attached to his multimeter but idk what it was) around the out wires on the jags when we ran against the barrier and it wasn't drawing 40 amps from the jags.

ty for all the help.

[nitneylion452]

"Big" is a relative term. For 6" wheels, 12:1 is "big." For 20" tires, I'm not sure what I'd constitute as "big."

Also, the Jag's overcurrent protection shouldn't trip before your 40A breakers. It seems like you need a higher gear ratio that you have. It would be helpful to know what exactly it is you have though.

[artdutra04]

Also, the Jag's overcurrent protection shouldn't trip before your 40A breakers.Actually, this happens quite easily. I've seen numerous occasions where the Jags brownout for several seconds due to "over current" but the 40a snap action breakers are fine.

[Thundrio]

the mech lead says the gear ratio is 5:1 running of a andymark cimple box using 2 cims.

[nitneylion452]

the mech lead says the gear ratio is 5:1 running of a andymark cimple box using 2 cims.

EDIT: A CIMple box's ratio is closer to 4.67:1. Just wanted to throw that out there.

EDIT 2: In this case, you need more torque rather than speed.

You need a much higher gear ratio. 5:1 is not nearly enough for 20" tires. 5:1 is barely enough for 6" kit wheels.

I hate that AndyMark is providing these gearboxes. You can't do nearly enough with them. The ToughBox was much better. Provided a lot of torque and gave good speed right out of the box (okay, right after assembly). That's not to say that I don't LOVE AndyMark. They are among the best vendors to deal with.

@art

Really? I've been fed lies! Though I find it hard to believe that a we use a breaker that trips at a higher current than the Jag's internal protection.

[artdutra04]

the mech lead says the gear ratio is 5:1 running of a andymark cimple box using 2 cims.There's your problem! :ahh:

To run a robot with 20" wheels, you need an overall ratio between your CIM motors and the wheels of about 40:1 to 50:1. With 20" bicycle wheels and only the AndyMark Cimple Box ratio of 4.67:1, your robot is currently geared for about 99 ft/sec! With this gear ratio and wheels that large it's unlikely you'll even be able to drive even in a straight line without tripping the 40 amp breakers.

If you switch over to an AndyMark Toughbox (12.75:1 ratio), you can then use a final sprocket reduction (for example, a 12-tooth sprocket on the Toughbox output and a 42-tooth sprocket on one of your wheels). This will make your robot geared for about 9 ft/sec under nominal load, which should fix the over current issues with your drivetrain.

[remulasce]

Actually, you /do/ get a breaker that trips before the Jaguar- except only in theory. The jaguar protection is electronic and trips based on the combination of current and length of time drawn. It will allow 40 amps forever, 60 amps for 2 seconds, and something like 100amps for a fraction of a second (an exponential curve) before tripping. However, even with this extra allowance, the electronic protection will trip long before the breakers. If I recall correctly, the mechanism inside the breakers triggers based on temperature, so they can take bursts of current rather easily before they finally heat up and trip. That last sentence was mostly dim-memory, though as a former driver tasked with playing D, I can assure you that the jaguars trip long before the breakers.


And ditto on the gear ratio: When I was looking to motorize my bike, I was considering how to run two CIMples in series for a 25:1 ratio. And that was just to get a good top speed, I wasn't even going to hope for any sort of acceleration.

[Thundrio]

Ok, so just to be clear, this is not an issue that can be fixed through software (whether that is switching to victors, ramping, or what), we have to switch the gear ratio correct (I want to be 100% before I tell the mech lead its not my fault).

[Ether]

(I want to be 100% before I tell the mech lead its not my fault).

The problem is, it's not clear that you have given a full description of your drivetrain. All you have told us is this:

the mech lead says the gear ratio is 5:1 running of a andymark cimple box using 2 cims.

As was pointed out in a previous post, there is no 5:1 Cimple box. It's 4.67:1. That's not a big difference, but most folks would give the proper number so it raises questions. And, you haven't clearly stated what happens between the output shaft of the gearbox and the wheel. Are you direct-driving the wheels? Or do you have chains, and if so, what are the sprocket tooth counts on the driving and driven sprockets?

Also, you said you had 20" tires. How do you fit four 20" tires on a robot without violating the frame perimeter? Are they really 20" diameter? Are they staggered or something?

[Bill_B]

There are at least two ways the jaguars can "trip" out, or stop trying to send as much current as the motor can use. The first and most prominent one has already been explained. The jags will also reset if the voltage to them goes below a certain level. Voltage can drop due to excessive current being drawn from a mostly-discharged battery. It seems probable to me that a few frustrating runs with the described mechanical setup might have depleted the battery being used on their test. This would further complicate their problem diagnosis.

BTW I too want to see those 20" wheels, as they must be overlapped somehow AND the bumper placement must be something to behold for a frame that can support such wheels. Take some pictures. If you're not sure how to post them, mail to me and I'll put them up for you. :cool:

[bdbayes]

My team is actively having the same problem. We are currently using 16" wheels with the standard cim gear box and a 3:1 ratio for the chains instead of the standard 2:1 provided with the KoP. I am glad that we are not the only team having this problem.

[Kilo Foxtrot 7]

Alright so I'm the Mech in question.

let me clear up some things

1. yes we are using 20in wheels and yes they are staggered

2. the drivetrain is running a 5:1 gear ratio on top of the 4.67:1 of the gearboxes so a total of a 23.35:1 ratio

3. i am 98.9% sure that we are not tripping the 40A breakers

4. we are using a fresh battery

so that being said is there any way to keep the jags from triping

Thx

P.S. thund plz get your facts strait before posting it saves me from wasting my valuable sleeping time. %-l

[Daniel_LaFleur]

Alright so I'm the Mech in question.

let me clear up some things

1. yes we are using 20in wheels and yes they are staggered

2. the drivetrain is running a 5:1 gear ratio on top of the 4.67:1 of the gearboxes so a total of a 23.35:1 ratio

3. i am 98.9% sure that we are not tripping the 40A breakers

4. we are using a fresh battery

so that being said is there any way to keep the jags from triping

Thx

P.S. thund plz get your facts strait before posting it saves me from wasting my valuable sleeping time. %-l

Now that we have the real gear ratios, lets go through the numbers (as a teaching exercise).

Freespeed of CIM = 5310 RPM
/60 (min / sec) = 88.5 RPS
/23.35 (gear ratio) = 3.79 RPS (rounded)
20" dia * 3.14 = 62.8" circ
62.8" circ * 3.79 RPS = 238.01" / sec
/12 (in/ft) = 19.83 ft/ sec.

These are theoretical numbers that will never be attained but typically anything over ~16ft/sec in a single speed gearsetup will trip the breakers at startup and while turning (depending on CoF, weight on wheels, wheelbase, etc).

Now lets calculate thrust.

Stall torque (again for theoretical measurements) of cim = 344 in/oz
* 23.35 (gear ratio) = 8032.4 in/oz
/20" (distance of torque) = 401.62 oz
/12 (in/ft) /16 (oz/LB) = 2.09 LBs thrust
* 4 (CIMs) = 8.367 LBf thrust

Thats low, but managable (someone check my math ... I'm terrible in the morning :p )

All in all your setup might work, but I'd expect tripping of the breakers when turning and in any sort of pushing match.

[Ether]

Now lets calculate thrust.

Stall torque (again for theoretical measurements) of cim = 344 in/oz
* 23.35 (gear ratio) = 8032.4 in/oz
/20" (distance of torque) = 401.62 oz
/12 (in/ft) /16 (oz/LB) = 2.09 LBs thrust
* 4 (CIMs) = 8.367 LBf thrust

Thats low, but managable (someone check my math ... I'm terrible in the morning :p )

Get a cup of coffee :-)

[Thundrio]

Alright I uploaded a video of a drive test from a few weeks ago, although I believe the drive train stuff is all the same (aside from a bit of tightening, but it looks the same). Unfortunately we don't attempt to go over the bump in this video, but here it is.

http://www.youtube.com/watch?v=bGlak6ijWPg
The robot doesn't start moving until about 1:15(I trimmed it with yt but atm the changes are still being processed -_-)

For me the important thing is to find out whether our issue (I know its difficult to discern our exact issue) is one that can be fixed via software/firmware, because I would enjoy people getting off my back so I can program.

[Ether]

...

You have a high center of gravity and a shorter-than-normal wheelbase (because of the 20" wheels). Even with your present low-torque gearing, you popped a wheelie. What's gonna happen when you go over the bump?

With your high center of gravity and shorter-than-normal wheelbase, you don't need to be geared for 19 feet/sec - it would be very difficult to control at that speed. Change that 5:1 sprocket ratio to 10:1 and you'll cut your amps in half (for a given wheel torque) and still have adequate speed.

If you modify the gearing for more torque, you will have to be extremely careful with the throttle. Adding a slew rate limiter (http://www.chiefdelphi.com/forums/showpost.php?p=1127623&postcount=2) to your joystick would limit your acceleration and help mitigate the wheelie-popping.


PS - You and Kilo Foxtrot 7 need to take your bickering off this forum.

[Thundrio]

I'm not sure how to add that code in.

change = joystick - limitedJoystick;
if (change>limit) change = limit;
else (if change<-limit) change = -limit;
limitedJoystick += change;

My idea is that just have limitedJoystick created as a joystick in slot 3 (a virtual joystick). Then I basically take the above code and put it right before my robotdrive (which calls the fake limitedJoystick). But it is not working (I didn't suspect it to) even after I created change/limit as a double.

Any help would be appreciated, I would like to get the slew rate limiter tested as soon as possible so it either fixes the issue or we need to try something mechanical (Since the mechs won't do anything to fix it if they think it can be fixed through software).

[Ether]

I would like to get the slew rate limiter tested as soon as possible so it either fixes the issue or we need to try something mechanical (Since the mechs won't do anything to fix it if they think it can be fixed through software).

Slew rate limiting will help prevent the wheelie-popping. I don't think it will help you get over the barrier.

What is your wheelbase* measurement, exactly?


* wheelbase: distance between front and rear axles.

[ianonavy]

My idea is that just have limitedJoystick created as a joystick in slot 3 (a virtual joystick). Then I basically take the above code and put it right before my robotdrive (which calls the fake limitedJoystick). But it is not working (I didn't suspect it to) even after I created change/limit as a double.

Using pseudo-Java, this would go in an IterativeRobot:

Joystick joystick = new Joystick(1);
double lastJoystickValue = 0;
// Limit the Joystick to a change of 1% every iteration of the robot. Basically,
// limit the acceleration of the robot.
final double MAX_CHANGE_PER_ITER = 0.01;

public void teleopPeriodic() {
double currentJoystickValue = joystick.getMagnitude();
double magnitude = limitRate(currentJoystickValue, lastJoysitckValue);

drive(magnitude); // pseudo method
lastJoystickValue = magnitude;
}

/**
* Uses the value from the last iteration to limit how much the Joystick can
* change in one iteration.
* @param goalValue The ideal value that we ultimately want to reach.
* @param lastJoystickValue The value of the joystick from the last iteration.
*/
public double limitRate(double goalValue, double lastJoystickValue) {
double difference = goalValue - lastJoystickValue;
if (difference > MAX_CHANGE_PER_ITER) {
return lastJoystickValue + MAX_CHANGE_PER_ITER;
} else if (difference < -MAX_CHANGE_PER_ITER) {
return lastJoystickValue - MAX_CHANGE_PER_ITER
} else {
return goalValue;
}
}


I hope this helps and makes sense. You will need to modify it for your purposes (port to C++, change for your DriveTrain Subsystem, modify for Mecanum drive, or whatever else).

[Thundrio]

The mech lead says the wheelbase is roughly 15 inches (I won't be there for another few hours, I just called him).

Thanks for the pseudo-code ianonavy, I'll give that a try.

[Kilo Foxtrot 7]

There is a cimple box at 4.67 to 1
and there is a 5:1 reduction from the cimple output to the wheel (12 tooth sprocket to 60 tooth sprocket)

This makes a 23.35 reduction

We need help trying to identify if we can change the ramprate on the jags to a level that prevents it from overloading and do some testing. How do we program a different ramprate in the JAG using Java?

edit: btw, clarksnack is our mentor that Thundrio was talking about in the original post.

[clarksnack]

Is there a way to set the ramprate of the Jag in the Java code? We tested one of the motors using the BDC COMM software and placed the ramprate at 1000 and just the one motor appeared to have much more torque available without the Jag internal trip "tripping" How can we program the ramprate in the jag using java?

[Ether]

it gets the front wheels over the ramp and cuts out when the bottom ones hit the ramp

The mech lead says the wheelbase is roughly 15 inches

I am having trouble parsing the above two statements.

When you say "ramp", are you referring to the barrier or the bridge?

And what do you mean by "bottom ones"? The rear wheels?


If the wheels are 20" diameter and the wheelbase is 15" diameter, how can the front wheels be "over the ramp" (the barrier) before the "bottom ones" (rear wheels) hit the ramp (barrier)?

Unless by "over the ramp" you mean "on top of the ramp" ??

See the attached PDF.

[Thundrio]

I am having trouble parsing the above two statements.

When you say "ramp", are you referring to the barrier or the bridge?

I am referring to the barrier.

And what do you mean by "bottom ones"? The rear wheels?

by "bottom ones" I am referring to the rear wheels.


Unless by "over the barrier" you mean "on top of the barrier" ??

I did mean on top of the barrier, as they do not go all the way over. It does start to pop a wheelie but we have a wheelie bar in place to stop it

sorry for the confusion. -_-

[Ether]

Is there a way to set the ramprate of the Jag in the Java code? We tested one of the motors using the BDC COMM software and placed the ramprate at 1000 and just the one motor appeared to have much more torque available without the Jag internal trip "tripping" How can we program the ramprate in the jag using java?

You can set the ramp rate in the Jag if you are using CAN bus.

If you are using PWM, you can enable the fixed ramp rate of full reverse to full forward in 1/8 second by placing the limit jumpers parallel to the front of the Jag. See Pages 2-3 of this (http://www.ti.com/lit/an/spma033a/spma033a.pdf) document.

Or you can put the very simple code shown here (http://www.chiefdelphi.com/forums/showpost.php?p=1127623&postcount=2) to limit the rate at which your joystick command is allowed to change. That will limit the rate at which your Jag changes voltage.

You can try it, but I do not think ramp rate is your problem.

[clarksnack]

Ether, there is a field in the BDC COMM software called ramp. If the joystick limit is manipulated is it truly adjusting the Jags ramp or is it manipulating the operators input ? seems like two different functions. Is there code examples where we can change the ramp in java?

secondly, are you saying we can change the ramp in CAN bus, but not directly in Java through PWM?

thanks greatly for the insight and help.

[theprgramerdude]

You cannot change the ramp dynamically through PWM, in any programming language. Really, though, the ramp isn't the problem.

[Ether]

are you saying we can change the ramp in CAN bus, but not directly in Java through PWM?

If you want to set the rate of the ramping function that is built-in to the Jaguar, you have to use CAN bus. There is no way to use PWM to communicate anything to the Jaguar except the %PWM you want.

there is a field in the BDC COMM software called ramp. If the joystick limit is manipulated is it truly adjusting the Jags ramp or is it manipulating the operators input? seems like two different functions.

The Jaguar's built-in ramping feature imposes a slew rate limit on the Jag's output.

You can accomplish much the same thing by limiting operator commands (joystick commands), or by limiting vehicle commands derived from the operator commands. This can be done in your software.

Is there code examples where we can change the ramp in java?

The pseudo-code I linked to can be used to pre-process your joystick values before passing them along to the rest of your code.

Or, that code can instead be used further downstream in your code, in order to limit the slew rate of specific vehicle behaviors. For example, consider a skid-steer vehicle with a tank-drive user interface.

Process the joystick values into forward/reverse and rotate commands, and then apply the slew rate limiter to the forward/reverse only, then process the vehicle commands into motor commands. That will limit your forward/reverse acceleration but not your rotational acceleration.


Having said all that, I do not think ramp rate is your problem.

[Thundrio]

Well then what do you think the problem is? I have provided as much information as I can think of, and if more is needed I will gladly provide it.

thanks for all the fish.

[Ether]

Well then what do you think the problem is?

You are geared way too fast. It's like trying to drive 5 mph in high gear up a San Francisco hill.

I think you should gear down for more torque / less current.