Forgive me if this is a repeat, but I can’t find any info on the inputs on the VEX controller. I am mostly interested in analog and TTL inputs. If anyone should know of these wonderful little thingy’s I would very much appreciate it! Thanks much!
The reason I’m asking this is because I would like to interface a vex brain with a RFID tag reader.
by inference from the data sheet for the microchip pic 18f8520, (http://ww1.microchip.com/downloads/en/DeviceDoc/39609b.pdf), the sixteen analog/digital pins on the controller will be connected to ports D and E on the microcontroller as these are configurable as either analog inputs or as digital input or ouput pins. the six interrupt pins are probably connected to port B, which can be configured for hardware interrupts, though these pins might also be useable for digital i/o. no way to guess where the motor ports are connected except that they are probably not connected to ports B, D or E. all of this could be doped out with a little patience and an ohm meter, but i’m probably not the guy to do it and definitely not today.
i do know that two of the pins on the serial port are connected to pins rc6 and rc7 on port C, these being the transmit and receive pins on one of the 18f8520’s uarts. i have verified this with a meter.
it may not be unreasonable to guess that the two pins labelled tx and rx are attached to pins rg1 and rg2 on port G, these being the transmit and receive pins of the other uart.
that’s all i’ve got.
mea culpa. mea maxima culpa. ok, i was wrong.
according to the file ifi_aliases.h in the vex starter code available at vexlabs.com the pins on the vex controller are connexted as follows.
Analog / Digital Section
pin 1 = ra0
pin 2 = ra1
pin 3 = ra2
pin 4 = ra3
pin 5 = ra5
pin 6 = rf0
pin 7 = rf1
pin 8 = rf2
pin 9 = rf3
pin 10 = rf4
pin 11 = rf5
pin 12 = rf6
pin 13 = rh4
pin 14 = rh5
pin 15 = rh6
pin 16 = rh7
rx = rg1
tx = rg2
Interrupt Section
pin 1 = rb2
pin 2 = rb3
pin 3 = rb4
pin 4 = rb5
pin 5 = rb6
pin 6 = rb7
Motors Section
pin 1 = re7
pin 2 = rg0
pin 3 = rg3
pin 4 = rg4
pin 5 = ?
pin 6 = ?
pin 7 = ?
pin 8 = ?
sorry, but there are no definitions for those last four.
any pin can be configured as a digital input or output. pins 1-16 in analog/digital section can be configured as analog inputs. the 6 pins of the interrupt section can be used as external interrupts for wheel encoders, bumpers, etc. the pins of the motors section are normally used to produce pwm outputs to control, you guessed it, motors.
Thanks for posting the info Foobert.
I was surprized and perhaps a bit disappointed to see that the Vex User Manual addendum preview for the upcoming Optical Encoder Sensor instructs “You’ll need to plug your shaft encoder into any port in the Analog/Digital bank on the Vex Microcontroller.”
I’m hoping the sensors will be able to utilize interrupts. I wonder if the outside pins on the interrupt section pin out the same as the analog/digital section and that either section can be used with many of sensors. I’m guessing one pin is +5V; the other ground? I suppose this could be a question for the IFI engineers, although there my be an info ‘blackout’ for sensor info until they’re officially released.
white wire on the keyed end of the connector appears to be signal. middle pin on analog/digital and interrupt connectors is 5 volts and on the motor connectors it’s the raw battery voltage. the pin on the unkeyed end of the connector is ground.
it doesn’t appear that the folks at IF are eager to help with buggy interrupt code. there is a disclaimer to that effect in the function InterruptVectorLow in user_routines_fast.c. can’t say i blame them.
Thanx for all your help. I have most the stuff to make a programming module now so I think I’m going to go that route. Someone mentioned that they bought one. Are they for sale now? Where can you get them? I can’t find them.
I purchased one through IFI. Contact them by e-mail at [email protected] I have not received mine yet, it is still in route via. UPS, so I won’t be able to give details on what is included until it arrives. It is my understanding that the ones from IFI are prototype units. So my guess is they may be a little different from what will be released by Radio Shack in August.
Call Innovation First at 903.453.0800 and you’ll be able to order one. The modules are bare board beta units (no housings) and cost about $99 + shipping. The MPLAB CBOT compiler (IDE + C18 C compiler for PIC18F8520) and two cables are included.
One possible caveat: By ordering now, we do not recieve EASYC, a proposed C code generator which may or may not be bundled with the upcoming Radio Shack programming module release (slated for August).
That’s a mistake in the manual. You will plug the encoders into the interrupt port when using them with EasyC (and could do the same if you write your own program). EasyC will give you the option to turn them on, off, read the value, and preset the count. I’m pretty sure they return 90 counts (pulses) per revolution.
Brad
Has anyone actually gotten some of the encoders? They’ve been listed on the vexlabs.com and the radioshack.com sites as being “sold out - coming soon” for the last couple of months.
Have they been released and sold out? Or, have they not yet been released?
I’ve seen them just before Thanksgiving at the local Radio Shack.
Check the Radio shack website to find a local store with the encoders. I bought a set and am playing with them now. I must be doing something wrong or there is allot of latency in easy c. It drives straight with quite a wobble. These aren’t greyhill quality or precision.
i got a pair a month or more ago at the rat shack, took one apart and said to myself, “self. with a couple of photo interrupters appropriately placed you could convert this thing to a quadrature encoder”, but since i can’t find the switches i got some time ago from budget robotics they’ve been sitting in the parts pile ever since. reckon i should hook 'em up and see what i can do. i don’t have easy c, though, having ordered a prototype programmer from ifi over the summer. i got those mean old early adopter blues.
I bought a set about a month ago. Quadrature would be a real nice addition, but I’m not sure how to go about that. I didn’t have any trouble getting it to drive straight if I was just measuring distance. My Squarebot could repeatedly drive a path including straights and turns with reasonable precision as long as the surface remained the same. Move to a different surface and the turn angles changed. Not an unexpected result.
I have recently started working on velocity contol. I have a Proportional algorithm working on one side. It does oscillate a little when running free. Again this is not unexpected, in fact I would have been more amazed if it didn’t happen as it is characteristic of this sort of control. PID’s always oscillate, the question is whether or not the magnitude is acceptable. Gdeaver were you counting clicks or controling speed?
I haven’t added the second side to see if it drives straight yet. Maybe in a few days. I’ve been too busy with going to FLL at Legoland and setting up next weekend’s tournament at CSUN.
Has anybody done anything with Potentiometers?
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.
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.
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.
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. 
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???