Multi Drive Fun...

[Sachiel7]

Well, as I've posted in a few other threads, I've got this great Multi-Drive system cooked up for this year. I'll list the Drive types one more time:

-Skid-Steer
-Crab/Swerve (I will refer to it as Crab)
-Car
-Angle

Well, as far as the designs go, they're done. I've "proto'd" them about 3 times, and each attempt was a success.
Anyway, I had some concepts for control/sensors, and decided to prep the programming pre-season as well. So, I worked on getting down the math.
So far, I've gotten the Crab done. That's the only thing I've worked on so far.
Anyway, for those who are interested in crab control, here's what I came up with:
-First off, Jump for Joy! The new PIC can calculate negative numbers! This has always been a pain for 1 joystick drive in the past.
-Plot your Joysticks X and Y axis' at a point on a graph(for visual example)
-Get the Dx (Distance of X from origin) and Dy (same of y).
-Flip Dx and Dy so Dx=Dy, Dy=Dx
-Get the Hypotenuse of the Vector to form a triangle. Basically
H = SQR(DX^2+DY^2)
-Next, you need the Angle that H is from DX.
To get an accurate readout, you need the inverse sign (sin-1) of (DX/Y) Remember, DX is actually the original DY value.
Since no known Programming Language (or none I've used) has a function for sin-1, or ArcSin, you must define it as this:

A = (2 * ATN((DX / H) / (1 + SQR(1 - (DX / H) ^ 2)))) * (180 / PI)

This will give you the Angle in Degrees.
Now, you know the angle. Orient it properly with the graph.
My system is designed to have the wheels pivot 180 degrees. They start in the 90 degree position. We Want (-127,0) to be 0 degrees, (0,0) to be 90 degrees, and (127,0) to be 180 degrees.
Instead of a fancy wheel turning system, it's smoother, and worth a little math. If you look carefully you will begin to realize that the angle of the wheel when reflected over both axis' is the same. In other words, if you know the direction of the hypotenuse (negative, for example) than you know which direction to turn your drive motor, and how many degrees to pivot the wheel(s). So, if you wanted to drive forward, without pivoting the wheels, and then you shift backward, you don't need to waste time and energy rotating your wheels all the way around, just reverse the drive. The same applies for angles reflected over the x axis.

Now, to determine your PWM output:
-Get the Hypotenuse, and make sure it has the proper sign for it's quadrant.
-Double the Hypotenuse. This allows the maximum output to the motors

When tinkering with this, you may realize that when corners are approached, the output is well over 254. That's simply because the hypotenuse is longer than the sides in a 45 degree angle. So in other words, you need to limit the Hypotenuse.
Now, there are better ways to do this, I'm sure. This is just the path I decided to take, because it is good enough for the application we're using it for.
Here's Some simple math:

C=H
If C > 127 then C = 127
if C < -127 then C = /127
C=C*2
Drive =C

You will notice that the range in which 127 resides as C is from 127 to 90, roughly 37 values set the same.
Now, for us, this is just fine. We're glad that we can achieve full speed when one value is 0.
Anyway, I put together a small program that takes a used defined point, and displays the drive speed/direction, the Hypotenuse, Wheel Angle, DX, DY, etc., and draws it as a triangle.
It works just right, and even though it's dull looking, it still shows that the math works. I need to go back and clean out the code, but I'm just glad it's working.

Anyway, the Skid/Car/Angle coding is simple as pie.
For those wondering what I'm calling "Angle" drive, it is like car where a set of wheels pivot, but 2 setd pivot opposite directions on the front and back. It's really easy to do some figure 8's with that one
Car only pivots 2 wheels, Crab pivots all 4, and Skid locks 'em in back at 90 deg.
I think we may be one (if not the) first teams to build this kind of system on the east coast. Another slight variant from typical designs is the fact that motors aren't connected to the wheel assemblies. Their force is transferred out to 2 sets of wheels each, across a chain system.
I won't post tooo much info on my lovely system, though. At least, not until it's built...

[FotoPlasma]

First of all, I'd like to commend you for the amount of work and thought you've put into this topic. It's great to see people going through this process of recognizing and defining a problem, and going through the process of generating a solution. Lately, the amount of purely technical (as opposed to speculative (the new control system) and argument-based (the etymology of drivetrain terminology)) discussion on ChiefDelphi has been declining, and this is a very refreshing. But I digress. This isn't what the thread's about.

Your method of converting the joystick position to a polar coordinate system (from (x,y) to (r,theta), that is) seems to be a very effective method for determining the intended orientation of the modules, but I think there are simpler methods (which don't produce the same results, but which are comparably powerful). One of these methods is to map an arbitrary analog value (the X-axis of one of the joysticks, in our situation) to the orientation of the modules. Concerning this, you'd want to shrink the value of the intended orientation (the X-axis value) by a factor of 2, based at 127. Hrm. Getting into tangents seems to be a forté of mine.

One of the most involved processes you'll probably get into is perfecting the algorithm for powering the motor which controls the orientation of the modules. Driving the motor at full speed has the chance of "over shooting", and causing the system to abruptly and violently reverse direction, while, if you don't give it enough juice, you'll wind up (essentially) stalling the motor (I'm not absolutely certain that this is technically correct terminology), when it can't overcome resistance to motion in the steering mechanism, and converting electrical energy almost entirely to heat, instead of mechanical energy (I could be wrong about this process, as well, though). So, you'll wind up wanting to move the motor faster when the difference between the actual orientation and intended orientation is above a certain threshold, and stepping the speed down as it approaches the intended orientation. And again with the tangents...

Speaking of tangents, one thing you might consider, instead of using a mathematical function to determine the arcsin, is using a lookup table, given input values mapped directly to output values. I believe it'd only really be space-wise and speed-wise effective if you're dealing with integer values, but that should be fine. Space and speed permitting (declaring and defining 255 or 360 bytes and spending instruction cycles reading these values, as opposed to performing mathematical operations on any given input value, which would probably take considerably more in the way of instructions), a lookup table implementation of arcsin might be the optimal route.

Oh, also, what you're calling "angle" steering is also referred to as "complementary" or "monster truck" (thanks, Mike ) steering.

And a question. What do you mean by "[the] motors aren't connected to the wheel assemblies"? I'm thinking of a coaxial system, such as 217's 2003 drivetrain (pictures are available online).

Just throwing a little kindling on the fire. I'll probably have more to say, tomorrow. Staying up until 3am the day before a midterm isn't good planning, on my part.

[Sachiel7]

Thanks for the suggestions!
I'm going to toy around with some different ideas, and see which should work pretty good.
Well, Basically The motors (Preferably the CIMs) are attached to a chain system, and geared down by sprockets.
Now here's the thing:
We're only using an 8:1 gearing ratio.
Now, I know every team will say you need at least 20:1 w/ the CIMs, even I tell myself that, but we surprised ourselves this past year.
First off, the fact that the Cims were used to running at 30amps meant that you needed higher gearing, and with the slight boost to 40a, we needed a little less.
Now eight sounds like it wouldn't quite cut it, but compared to the torque of other bots, we did good.
Since we didn't sacrifice too much speed, we were the fastest at our regional (9fps), there were a few bots that would shift to something around 35fps (which I thought was a little silly), but everyones default speed was 7fps or less.
Now, somehow we managed to have enough torque to push bots and bins over the field. I remember a match at VCU this past year where we cleaned out the Red scoring area and Pushed RoboDogs (or is it Dawgs?) into the starting position, and held them there, all at the same time. So far we've beaten alot of the local teams at sumo matches. We had an event at the Science Museum of Virginia, and we brought over the VCU practice ramp. We ended up challenging the teams to sumo matches for the hill, and we won just about every time, or we tied.
Now, 8:1 probably still has it's flaws. But it worked great for us this past year, and so we'll probably use it again.
Anyway, the Chain system carries across to 2 wheels on both sides. 1 Powers the Left side, one the right.
A Worm gear Motor (preferably the windows) is mounted to a large sprocket which pivots to wheel assemblies 180deg. The forward/reverse force is sent down to the wheels through some beveled gears into the wheel assembly, and then another chain/sprocket.
So far I've made models from legos, edubot parts, and tried some dynamic simulation, and it works pretty well. My main concern is the strength of the beveled gears. I tried to find some w/ a small enough pitch and enough strength for the system while receiving force. I think I did ok, we'll see once we get crakin' on it.
Anyway, I haven't heard of anyone whos'e really attempted an on the fly multi drive, let alone that kind of forward thrust system.
I might post the little program I came up with the other night/morning ( ) just for fun.

[mattf]

your ideas sound really interesting, but i have a few questions & comments.

about not having an inverse sin function...the standard C math library, math.h, implements asin(). also, it defines some constants like M_PI which are quiet useful. you can read more on it here:
http://www.opengroup.org/onlinepubs/.../xsh/asin.html

you mentioned that your wheels will pivot 180 degrees. if you want to swerve, then wouldn't your modules need to be able to turn infinitely in any direction? if you're trying to move in a full circle (without changing orientation), then you'd only be able to complete a quarter of the turn since your wheels wouldn't pivot past 0 degrees (or 180 in the other direction). am i not understanding how this is supposed to work?

when in car or angle mode, i would imagine that for steering, you'd want to wheels to be pointing forward (90 degrees) when the joystick is centered horizontally. how do you plan to realign the wheels when the joystick is centered?

[Matt Leese]

I would highly recommend against using the asin() from the C standard library. I'm fairly certain that the PIC chip does not have a Floating Point Unit and asin() operates on floating point values. This means that the entire floating point process is emulated and software and will be very slow. Using floating point is something you have to consider very carefully.

Matt

[Sachiel7]

Think of a circle like this:
The Robot Starts with it's wheels like this:

``U
__U__

Where the U's are the wheel, and the Lines the limits of movement. I'll use F to show which way the wheel is turning.
Please ignore the `'s, the're just for spacing.
The driver would start by driving forward 45 deg to the right:

````F
```U
__U__

Then All the way to the Right:

__UU_F

Then Back and to the right:

`U
__U__
```F

Then straight Down:

``U
__U__
``F

Then Down to the left:

```U
__U__
`F

Then All the way left:

F_UU___

And Finally, Up and left:

F
`U
__U__

So, you can get full motion with 180 degrees of pivoting. You just reverse the drive direction based on which side of the Y axis you're on (positive or negative).
Sure, you need to move the wheel back some to change your angle, but you'd have to do that anyway.
I'll post a link to a quick animation showing the bot doing a circle (3d sim) just in case you can't understand my little ASCII demonstration

[mattf]

aahh so you're pivoting the wheels 135 degrees in the opposite direction & reversing the motors. gotcha. so then how would that work on the joystick? if the joystick is at (127,127) and your wheels are at 0 degrees, you'd have to move the joystick to (-127,0), let the wheels rotate, and then move it straight back? i'd like to see the animation if the offer still stands

[Jnadke]

Originally posted by Sachiel7
Now here's the thing:
We're only using an 8:1 gearing ratio.
Now, I know every team will say you need at least 20:1 w/ the CIMs, even I tell myself that, but we surprised ourselves this past year.

This is very much a meaningless number. It would be very easy to get by with an 8:1 gear ratio if you have the correct wheel size. The wheel acts like a lever, converting the rotational torque into a force. The smaller the wheel the less gearing you have to do.

speed = (free speed) / gear ratio * pi * wheel diameter / 60
Still, 9 FPS at that geardown would yield a wheel diameter of 0.25 feet or 3". That's a fairly unbelievable number. Are you including any sprockets/belts in your gear ratios? Something tells me you calculated them incorrectly. Either that or your top speed is wrong.

The goal of gearing down your motor is not necessarily to achieve enough pushing torque, but to maximize your acceleration. Virtually all your torque will go into accelerating a 130lb robot (gears weigh so little compared to the robot as a whole that very little torque is lost), so the acceleration up to the top speed can be modeled by F=ma. If you're only seeing 9FPS out of your robot then you most likely have not maximized your potential for your given wheel size. If you want to design your robot for speed then you should have enough torque to accelerate to top speed within 10 feet (usuallyt that's all the usable room there is on the field). The equations can be a little tricky, given that the torque of a motor depends on its free speed, but it can be done. Once you have set up your equations, you should then be able to solve for the gear ratio.
An easier way to calculate the minimum gear ratio is to say that the motor must go from drawing 120A to 80A within 1 second and from 80A to 40A within 5-8 seconds. This is from the breaker spec sheets of how long it takes for them to trip.

Having a large top speed is useless if your robot cannot accelerate to it rapidly. A robot geared for an 8FPS top speed will most likely traverse the field faster than a robot geared for 20FPS (assuming both are using single-motor drivetrains).

[Matt Krass]

Originally posted by Jnadke

speed = (free speed) / gear ratio * pi * wheel diameter / 60

I think your formula is slightly off, it should be

speed = (free speed) / gear ratio * pi * wheel diameter / 60 / 12

That's for feet/sec, without the division by 12 it's in/sec I think.

[Rob Colatutto]

robot speed (ft/s) = (wheel rpm * pi * wheel dia) / 12 / 60

Dividing through the rpm as you go from gear to gear usually gives you less errors since you could do the total ratio wrong. And don't use the free speed, just the normal load speed of the motors.

[JVN]

Originally posted by Rob Colatutto
And don't use the free speed, just the normal load speed of the motors.

I usually use the free speed, then just put in a 15% "speed loss" to compensate for drive friction. It is hard to pre-determine the load a motor will see from the gearbox itself (the only load acting on the motor when it is running straight out across the field).

Otherwise, Rob, Matt, AND Jnadke have the formula right, the only thing you need to take into account is unit conversion. (personally, I prefer doing it all in metric and RPM, then converting to fps and lbs at the very end).

[Sachiel7]

Our Drive system:
1 CIM w/ 10t sprocket to 40t sprocket on jack shaft.
2 10 t sprockets going to 40t sprockets off jack shaft. 40t sprockets mounted to 8" wheels.
Maybe I'm off, but I'm not too sure. Anyway, we'll be using a similar wheel chain system, with the same gearing.
I'm still working on the animation, but if you want you can try some sample input yourselves!
Just download the Crab Input Simulator Program I created here:

http://www.chiefdelphi.com/forums/pa... SC&sort=date

Now, I'm still working on it. It runs under dos, just to warn you.
(That's what you get for proggin' Qbasic for 10 years )
Anyway, It's only version 1. I've already got v2 in the works, with an actual "Wheel" instead of triangles to show how the system works.
I'm also zooming in the input window so the 127-90 values aren't lost as the same speed, and I'm working on a buffer system that detects rapid changes in speed/direction and buffers the change down, so It won't be so harsh.
I'm also trying to find a good spot to upload the video. Right now, our team is running off a yahoo group while the website's being worked on, and you can't access our files without being a member.
I might just encode it as an animated GIF, or post it in the white papers. I'll need to really crunch on compression though...
Anyway, I'll post back when It's done.

[Jnadke]

That's where the problem is...
When you have reductions cascaded like that, the gear ratio is multiplied and not added. This is because the shaft serves as an intermediary and induces a torque on the middle of the sprocket/gear instead of the edge. Your actual gear ratio is 16:1 to the output shaft of the wheels and your top speed would be 12FPS.

If you have three gears in a line and all the teeth are engaged to eachother, that's when the gear ratios are added. This is equivalent to skipping the intermediary gear and taking the gear ratio of the first gear to the last gear.

Originally posted by Matt Krass
That's for feet/sec, without the division by 12 it's in/sec I think.

It all depends on what units you want to use. I was including as little conversions as possible, and therefore was assuming the wheel diameter would be expressed in feet. Obviously you have to divide by 60 to convert from minutes to seconds, an easier value to interpret. Other than that, it's up to personal preference.

[Sachiel7]

Ah, thank's for clearing that up.
I was having some conflict going on in my team over gear reduction math. They thought you were supposed to add (plus, they were taking college engineering courses ) and I was sure you were supposed to multiply it.
I think friction might be compensating for some speed loss. I'm pretty sure we're not 12 fps, we were more around 9-10 in our initial tests. But that's good enough for me

[Dan 550]

Wow Satchiel, you've really put some effort into your drive prototypes in the math/programming zone. :thumb: