View Full Version : More pBasic Woes...
11-06-2001, 09:38 PM
Well, frankly, I need some help. Since I despise tank drive (I don't like its tendancy to make the bot hop up and down and jitter and stuff.), I decided to engineer a nice, simple four-wheel steering system, much like Delphi Automotive has engineered recently for use on GM's large trucks, to reduce the turning radius of the trucks to about the radius of a compact car. Now, the diagram (Below; excuse the crudeness of the drawing please, I'm no artist, and all I have on this PC is Paint. By the way, it's not to scale at all.) I've included is basically the setup I want to go with, due to its mechanical simplicity, using only rack, van door motors (not pictured), pinion gears (blue circles), bearings, and drive motor assemblies (red boxes). The larger bearings (pink circles) are fixed in place, while the smaller (green circles) are attached to sliders (not pictured) and to the rack.
I have the mechanicals squared away here, but I have a bit of a problem with a bit of code I want to include to 'accident-proof' the robot. You see, I do not want a driver to have the ability to accidently leave the wheels in a turning angle when he should be going straight. I would like to put something in the code that the robot controller interprets as 'when x-axis = 0, return steering boxes to forward'.
Is it possible to define a zero point on the rack and make the motors turn the wheels so the point aligns zero rack with zero forward, automatically? Would this require use of the light sensors as well? This would really help prevent an escapade such as getting off the bridge while not at the bottom of it. (I did that once, and busted the dead axles on our rookie-year bot.)
11-06-2001, 09:47 PM
Okay, the image will not display, but that's okay. You can click the link, or you can admire this amazing text art!
o = small bearing
0 = large bearing
O = pinion gear
><>< = rack
II = plate metal
I._I = motor assembly
Please ignore the (`) and (.) because they are only there for formatting.
11-06-2001, 10:45 PM
There are a couple of tricks you can use to be able to see the picture.
If you are using internet explorer, you can drag the link up to the address bar and let go, and it will open a new window with the picture displayed.
If you don't use IE, you can click on the link. After the error page loads, you click anywhere in the address bar and press enter and the picture will load.
The easiest way, though, is to click the picture that I attached to this message ;) (its also quite a bit smaller for you modem users).
Ok, in response to the message below:
The reason that I created the attachement was that I didn't remember that I had a free webserver that I could upload images to. Now that I remember, see above.
11-06-2001, 11:00 PM
Joe, I appreciate you formatting it into a nice small jpeg, but what I was really going for a display of the diagram, not just another link. But thanks for the attachment hinty. I'll be sure to use that when posting annoying things like pBasic coding, always a nice thing to share.
11-11-2001, 10:08 PM
In my opinion, in order for steering drive wheels to work, you really need feedback.
Essentially, you need to have a pot that will give you the true position of the wheel in question.
Your operator interface will define a "desired position" (perhaps via a steering wheel or a pot on the operator interface side - some calculation may be required to go from the pot you read to the actual desired position -- typically you have to at least scale the values to match up correctly).
Given an actual steering position and a desired position, you can calculate a "steering error" term by subtracting one from the other.
This error value can be scaled by a "gain" and then added or subtracted from $7F (127) to generate your PWM output for your steering motors.
There is a whole bunch of places to stub your toe while implementing the above scheme, but if you do, you can have a very cool drive system that is easy to use.
For your thinking purposes, I will list a few things that may trip you up:
Define increasing pot values the same way that increasing PWM values (i.e. higher PWM values tend to move the steering motor in the direction that moves the pot to a higher value).
Get the feedback loop working with a basic system first -- for instance map the steering angle to the wheel value of a joystick.
Get your fancy arc-sin method of calculating desired angle working after you have your feedback loop working.
16 bit unsigned math is going to drive you nuts! Get used to it. Basically, you will have to test for the sign of your error term before you calculate your PWM value and then use IFs & Gotos to subtract an abs(error) term.
For gains for your feedback loop, multiply by a GainNum and then divide by a GainDem. This will give you more resolution in your gain choices -- you would be surprised how often 1 is too small and 2 is too large. If you multiply by 24 and divide by 16, viola! you have a gain of 1.5.
When I say "divide" I don't really mean divide. I mean divide by 2^N which is to say ">> N" Shift right is a MUCH faster operation than division. Also, 2 complement math (which is effectively what Pbasic gives us access to) works for plus, minus, multiply (for 8 bit numbers at least, watch for overflow/underflow problems) BUT DIVIDE DOES NOT WORK. This is why you have to test for the sign of the error before you do the division.
PWM outputs have $7F as "off" you will have to make sure you don't add too much or subtract too much so that the PWM acts fine until a large error is encountered. In my code there are a bunch of things like this that take care of this problem "... + $8000 MAX $80FE MIN $8000 - $8000" This will make the ... be no more than $FE (a.k.a. 254) and no less than 0.
Don't make the mistake of thinking that "... MIN 0" actually makes the ... no less than zero. Trust me, the above ... will remain unchanged regardless of what ... is.
Start will a low gain and increase it until it goes "unstable" or until it is oscillating too much. Then reduce the gain until you have an acceptable amount of oscillation and an acceptable reaction time. My controls profs would kill me if they new I was giving you such crude advice but, hey, it works (mostly).
One more note, you should try to gear your pots such that full travel of your steering mechanism translates to about 180 degrees of travel of your pot (assuming that you are using 270 degree pots). This has been a good compromise for us. It gives us enough resolution without being so close to the edge that we are hitting the end areas of the pot, which we have found is not as linear and/or reliable as the middle of the pot.
One final word of caution. You will break a lot of pots when you try this. It is very easy to make a sign error that will cause your steering motor to go insane. Have your finger on the kill switch as you download and run new code. Good luck.
vBulletin® v3.6.4, Copyright ©2000-2013, Jelsoft Enterprises Ltd.