VEX inputs

[Francis-134]

I friend of mine got his hands on some encoders a few weeks ago and make a rather impressive line following program in easyC. They aren't bad, but they are just so honking huge, its hard to put them in without designing your robot around them.

[Gdeaver]

I have the square bot driving straight. One problem I seamed to encounter is that the easy c function to read the encoder count takes a fairly long time to execute. At near full speed there are a few counts occurring between the reads. To compensate I toggle the order of the reads . I'm not using PID, just increasing or decreasing the PWM by 1 each time through the loop.

[Andrew Schreiber]

I am attempting to play with pots but for some reason the pot reads a constant value even when it isnt plugged it. Im going to play with it today during class and ill post a result here before i leave today.

I am just trying to show a proof of concept and this will by no means be a finished product.

Also does anyone know if I could run the grayhill op encoders on a vex robot?? I am doing this to prove out concepts for our first team next year.

[skimoose]

Originally Posted by Damien1247

I am attempting to play with pots but for some reason the pot reads a constant value even when it isnt plugged it. Im going to play with it today during class and ill post a result here before i leave today.

If you're getting a constant value even when the pot isn't "plugged in", you're reading the value across the coil. The analog value should be taken, and read across one side of the coil and the wiper terminal. The pot should be wired to the vex controller like this:

pot coil
+5V ____/\/\/\/\/\/\/\______ GND
|
wiper
|
SIGNAL

The pot coil leads are almost always the outside two terminals and should always read 100K ohms, or 5 volts if energized, across them. The wiper terminal is almost always the center terminal. If you measure resistance across the +5V and Signal the value will change as the pot is turned. If the pot is energized, you should be measuring a variable voltage across +5V and Signal. If you are wired correctly, and you are not getting the correct values, then the pot is failed, or you're not using a 100K pot. Correct wiring is +5V red PWM wire, signal white PWM wire, and GND black PWM wire. as the cable comes off the Vex controller's analog input.

Hope this helps.

[gblake]

ChrisH & GDeaver,

I would appreciate seeing your control algorithms/equations or your code that uses shaft encoders to supply feedback for controlling your Vex bots paths.

I am dabbling with the same thing right now and mine is both wobbly and biased.

Right now I attempting to have both sides maintain 50_tick / 100_msec speeds and I am using 5:1 gearing to make the the encoder count 450 ticks for each revolution of the drive motor.

Because I am think I am getting different response characteristics from my motor(s) when I compare driving them CW vs driving them CCW (see below), I think I am ultimately up against writing some semi-complicated trig equations/approximations. Maybe I am thinking too hard...

I am adjusting the bot's speed by just incrementing/decrementing the EasyC command sent to each motor depending on whether that motor's encoder counted more or less than 50 ticks during a 100 msec EasyC "wait"; and depending on whether that motor is already slower or faster than the other motor.

The slow reads of the encoders Gdeaver hypothesized could be one problem I face.

Another problem might be that (contrary to what I read on in the VexLAbs fora) the motors react differently to commands that are identical except for direction (i.e. sending 127+70 produces a different RPM magnitude from a motor than sending 127-70). That means that starting my left and right motors at values that will produce (nearly) identical RPMs is a matter of holding your tongue in the right place; and furthermore, that incrementing the input to the CW one will produce a different change in output (for that one) than does decrementing the input to the otherwise symmetrical CCW motor on the other side of the bot.

I admit, the assertions in the paragraph above are generalizations from measurements I took on ONE motor while the bot was up on blocks.

I graphed the motor transfer function results (encoder ticks over ten consecutive 100 msec intervals) vs input value) in Excel if anyone wants to compare my results with any other measurements.

Does anyone else have any motor measurements to share? In addition to wanting to combine the fun of implementing my own ideas with not re-inventing too many wheels (see request above for sample algorithms), I am curious if I got unlucky with the one motor I measured; or if there is a pattern we should measure carefully and report in an appropriate FVC thread.

Blake
PS: Should we transfer this discussion to the Vex Shaft Encoder Kit thread???

[Andrew Schreiber]

I would post them but i have been unable to write the code so it registered the encoders. Also, you seemed to be using easyC and i am using MPLAB. Using the sensor test code provided by vexlabs i was unable to make the encoders work. I put his down to the fact that i was attempting to use a grayhill op encoder. I am currently lookin into purchasing a pair of encoders from vex.

[gblake]

Originally Posted by Damien1247

I would post them but i have been unable to write the code so it registered the encoders. Also, you seemed to be using easyC and i am using MPLAB. Using the sensor test code provided by vexlabs i was unable to make the encoders work. I put his down to the fact that i was attempting to use a grayhill op encoder. I am currently lookin into purchasing a pair of encoders from vex.

Damien,

The algorithm should be fairly independent of the encoder used (especially for straight-line motion). I am still interested....

Blake
PS: Private email works for me, if you want to avoid a public posting of incomplete results.

[Andrew Schreiber]

Oh no. im always a fan of posting work, complete or incomplete. The problem is i dont have any writen. I was doing proof of concept for a class. nothing that would be usable, just to make sure it could be done.

Though to make the 'bot drive in a straight line id think youd need two encoders. each time either of them is triggered you would add one to that wheel's count. Now, to make sure that it ran in a straight line i would use a timer to determine the rate at which you are calling interupts (dont ask me how to but i have a hunch it is in the pic18 ref manual ill look into it more after i finish my report on spam)

If i get time i will most definetly write up some code. I cant garuntee it will work or will be correct but i recall we wrote something using the hall effect sensors for the FRC game this year. I will look into it and ill keep in touch with you. .