Re: Programming Issues with Crab Drive System
 

All I see is the Channel A and Channel B outputs....I suppose you can use the digital counter but where would I get an analog signal?

Re: Programming Issues with Crab Drive System
 

He said not just quadrature.

The jaguar does not support continuous pots, so the us digital sensors won't work.

Re: Programming Issues with Crab Drive System
 

I was thinking of using the ABOB for that....but I only see a digital out for the US Digital encoders.

Re: Programming Issues with Crab Drive System
 

Sorry, I read "just not" instead of "not just"

The kit came with a few optical encoders (which are quadrature, IIRC)

It probably could technically work with the US digital sensor, but going from 1% to 99% of travel would go the long way around, and if you ever hit the transition point, expect some bad results. It certainly would cause more problems than it would solve.

Your root problem still probably needs to be solved. the Crio does PID just fine, and you already have it working, so now you just need to get the motors to respond equally.

Re: Programming Issues with Crab Drive System
 

Unless WPILib has changed WRT this since last year, you can only have 4 quadrature encoders running simultaneously. Otherwise, only the last 4 you instantiated will tick properly, the ones before the last 4 will tick WITH the last one you instantiated. (We wanted to use 7 encoders last year, only to discover we couldn't).

Re: Programming Issues with Crab Drive System
 

Thank you....that's what I thought....you could use the other channels for counters I presume.

Re: Programming Issues with Crab Drive System
 

Hi All, thanks for responding to the questions that our student programmer has posted.

This is our first (and maybe last) attempt at a crab drive system. I am not a programmer, but can answer some of the questions related to the mechanical end of our machine. We decided to go with the denso window because of the limited motor selection this year. The denso motor is controlling two wheel modules each with an additional stage of reduction of 1.78:1 (18 tooth sprocket on the denso motor, 32 teeth on each wheel module. Yes, they are side loaded and flex quite a bit underload so that may be one of the issues. We attempted a quick fix by boring out the center of our sprocket to expose the unsupported metal shaft, machined a boss to go over the end of the shaft, and welded it to an aluminum plate that goes on top of the motor to support the free end of the non rotating motor shaft. The motor no longer appears to flex and twist, although we are still putting side pressure on the plastic spline.

You can't really see it, but the wheel modules themselves are held vertically by two sets of ball bearings. One in the upper plate, and one in a lower plate in combination with a roller thrust bearing. So I believe we are okay as far as any binding in the wheel module itself. It seems to rotate quite easily. These bearings are a bit close toghether, Maybe about 1-1/4". We could space them up to 2" if we made a riser for the upper plate to add stiffness, but it seems okay at the moment.

As mentioned we are using an absolute magnetic encoder. We mounted it on our idler gear at 1:1 with the wheel module. It also is supported by two sets of ball bearings. The encoder itself has no side loading.

We originally had one left and one right denso motor, but just changed it to two left motors. I figured if we used one left and one right, then we would have at least one spare for each side, but that could have been a mistake. fortunately, it only takes 5 minutes to change to the other motor.

The main reason we are considering different wheel material, is because our machine was having trouble turning in regular tank mode with the wheels set in the wide configuration. Right now, we are using 4" wheels with roughtop (aka andymark plaction) out of the toughbox (machined new plates) with double motors per transmission. Those roughtop treads seem to have too much traction even in a wide chassis configuration. We just switched to the wedge top and will see how they do.

Our biggest worry right now, is whether the denso motors are up to the task in general. Even with the 1.77:1 extra reduction, we have very limited experience with them. Gearing them down even more will be a real pain. Any thoughts? I suppose we could use FPs, but we'd rather use them to control the ball.

Worse comes to worse for the PID balance issue, we can still chain all wheel modules toghether, but of course we would lose some features that we wanted to do. Also, has anyone chained two denso motors toghether? We've coupled 3 motors of different types before, but never two window motors with seperate worm gearboxes. Just wondering if we can actually do this without a problem or will the gearboxes give us trouble. I guess I am worried that because they do not back drive well, two gearboxes could get out of sequence and bind with each other.

Our students have not yet atempted to tune the machine since the denso motor mount modifications and tread change. Hopefully that will do the trick.

Any help is greatly appreciated. I hope all your teams are doing well and are having an excellent build season!



Alan Ing
Engineering Mentor
Team 368 (Honolulu, Hawaii)

Re: Programming Issues with Crab Drive System
 

Alan,
That takes care of many of my suspicions. You will find that using the high friction material will make any drive system very hard to turn in tank mode. A normal drive system will put the drive motors in near stall conditions during this move. With a high torque drive system, the robot will actually hop as the torque overcomes the friction with the carpet. Omni wheels would be indicated in a normal drive but not in crab. We have employed a "foot" in the past that has either non-driven omni wheels or just a nylon pad and descends between two of the wheels for changing direction. Going to a wheel that has less friction is the right way to go but you still need enough to climb the bump. The window motors do have some backlash in the gear box that may hamper your PID routines. I have not looked closely at this year's motors yet, but in the past there was a screw adjustment at the end of the worm gear to reduce the amount of backlash. There is a tradeoff though. The screw also makes back drive harder and gearbox friction higher. I don't think you should have any trouble with these motors for steering. Even with the ball bearings, there still can be incredible friction developed with the bearings that close together. We have used a bottom plate on our modules in the past, that overcame the short moment arm between the upper bearings. We have been using a simple bronze combination bearing for the top. It supplies both a normal bearing surface and the thrust needed to support the weight of the robot. The bottom plate then has a custom made delrin ring to provide the bearing surface at the bottom. This plate takes all side forces during drive and hits. If you can remove the window motors easily but leave all the chains in place (with tension), I would then see how smoothly the two sides turn without the motors. You may find it is a simple matter of changing the wheels and wearing in the bearings, chains, and sprockets.
By now you have realized that it is a complicated drive system that adds some weight. However, if your strategy will use crab effectively it is worth the effort. Ask questions anytime.

Re: Programming Issues with Crab Drive System
 

That's not entirely true. You can only have 4 encoders in 4x mode. You can have an additional 8 in 2x or 1x mode. Encoders in 2x or 1x mode are implemented as counters by the FPGA, but still use the encoder class.

We used 4 encoders in 1x mode and 1 encoder in 4x mode last year.

Re: Programming Issues with Crab Drive System
 

Hi Al,

Thanks for the reply. Our students tried the chassis again with the modified window motor mounts. Seems a bit better, but unfortunately for us, the window motors overheated after about 5 minutes of somewhat light use and shut down again. I have a bad feeling they are just not the right motors to use this year. We are fortunate enough to have a clamp on meter that can read DC current and measured about 2-3 amps while turning in place. Under drive crab conditions, this shot up to 7 amps and peaked out around 10 intermitantly. After reading the motor specs, I finally realized that this motor is only rated for 13.25 Watts. Not good. We will check again, but it really doesn't appear that we are binding anywhere. Gearing down the window motors more than 1.78:1 will be difficult. Our options at this point are:

1. Add an additional window motor per side for a total of 26.5W. (Still worried if they will work well together since they have worm gears plus they will add more weight.)

2. Go with the FP motors (100W +) coupled to some 64:1 banebot P60 transmissions we have laying around from last year using the same sprocket combination for a total of 64x1.78:1 (114:1), uncorrected freespeed of around 137 RPM. I imagine that should be more than enough to handle the steering mechanism. The down side is that we wanted to use the FP to control a soccer ball. This would only leave us those weak Mabuchi motors which are approximately 18W and 9W. Worst comes to worst, we can combine those two for about 27W.

I would certainly appreciate your opinion on this. The FP solution is the quickest for us. Probably could do either of these with 2 days of after school work. Can't spend too much more time on this. My day job is killing me:eek:

Oh, by the way, what sort of deadband in degrees is acceptable for crab drives. The students have it set pretty high to me, like 10 degrees. I told them that could leave us with wheels pointing as much as 20 degrees apart.


Alan Ing
Engineering Mentor
Team 368

Re: Programming Issues with Crab Drive System
 

Alan,

We have been doing crab for many years. We have used 1 globe motor to drive each side (2 wheels). The window motors should be able to handle the same task as long as they are geared properly.

Al was confusing the Van door motor with the window motor. Window motors do not an adjustment screw.

Re: Programming Issues with Crab Drive System
 

Alan,
I submit to Raul for all things mechanical. In looking at the specs for the window motors, it would seem you are not near the stall current of 18 amps but you are still tripping the thermal breaker inside the motor. That leaves a bigger question. Perhaps your current meter is inaccurate on peaks. Under what conditions did the 7-10 amp peaks occur? This might give you an idea of what is causing the intermittent load. I am not a programmer but I do not believe we have had deadbands programmed into crab steering. Our auto modes in the past have been very accurate. 20 degrees seems like a lot of tolerance. I am guessing that this was an attempt to fix a PID issue and what it causes is high current corrections to get back to center when the error exceeds the deadband. If that is where you current peaks are occurring then maybe your answer lies there.

Re: Programming Issues with Crab Drive System
 

The Jaguar has a digital quadrature encoder input as well as an analog input.

There are a couple modes that use these inputs, combined with PID, to control the output to the motor.

Speed Mode: Uses the encoder and PID to regulate the speed of the motor.

Position Mode; Uses either the encoder or the analog input (usually a pot) and PID to control the position. Pretty much servo control.

The analog port has three terminals +, S, -. These are designed for use with a 10K potentiometer (continuous or not). See the Jaguar Getting Started Guide at www.luminarymicro.com/jaguar for a diagram of recommended connections (pg. 22).

This doesn't mean that you cannot connect some other type of analog signal to the 'S' pin... :D check this post out, specifically #4 in the list of features. I powered a US Digital Analog Encoder off of an external source and then scaled the output signal to the 0-3V range for the Jaguar.

Before doing this I would definitely read the rules about custom circuits.

-David

Re: Programming Issues with Crab Drive System
 

Raul/Al,

It appears that our current spikes occur when the two modules become out of sync. Our students have yet to get them running together. Sometimes one leads the other or it oscillates.

This all occurs during very mild driving. Which does not give me much confidence that they will last during a match. We can't run it long enough to really tune it.

Has anyone used the denso motors to steer this system on carpet? If so what kind of reduction did you use? If I remember correctly aren't globe motors good for about 40W? The windows are only 13W or so. Getting anymore reduction than 1.78:1 will take some time. We will have to double reduce them which will mean finding the space to add and properly support a countershaft and at least two more sprockets. Maybe we can get about 3.56:1 at best. Thats a 40 RPM free speed which seems a bit slow. I imagine that would drop our current to half.

Regarding the deadband, I would think we would need to get it down to less than 5 degrees. Any thoughts?

Thanks!

Alan

Re: Programming Issues with Crab Drive System
 

Alan,
It seems strange that the two sides do not run in sync. This sounds like a programming issue or it is the effect of the deadband you mentioned. (if the two sides get 20 degrees apart that is telling you something) If you are driving when this happens there will be some incredible side forces developed on the modules which increases the needed steering power and raises the current in your CIMs and window motors. I am just guessing here that the programming is tied together somehow for both sides and that is where some of your problems lie. The programming is fighting itself. If that is happening clear the code that does that and pull the breaker on one side. Tune up the other side until it acts the way you want without driving. Repeat for the disabled side. Our crab system would oscillate when the wheels were off the ground. The programmers were fine with this as most of it settled out when sitting on the floor. I know that we had to calibrate both sides when we used two motors so that they would center properly. We used a movable plate that the pots mounted on so we could set both pots at a specific value when all the wheels were facing forward. We also had chain adjustments to perform wheel alignment on the modules that were tied together.