using mplab with vex

Other VEX
1

i got a vex set a few weeks ago along with a programing cable and i’ve worked with programing languages before but never with a robot other than easy c

i had decided initially that i didn’t want to compromise my ability to do anything possible with the vex kit so i got mplab and the ifi loader etc. rather than using easy c

i had expected that i would be able to find some sort of help online with programing my vex but after a week of seaching on and off all over the internet, i have yet to find just one site that could help me

i so far have;

~successfully created a connection between my computer and the vex
~downloaded some different hex files onto it so that i could test whether the ifi loader was workign
~gotten the starter code for mplab and gone through all of it like 5 times

i still dont undertand what exactly im looking at with the starter code. it seems to be nicely commented but its just confusing me.

to put it in context i wish to be able to make a 3 wheeled bot that uses a single back wheel on a servo to turn with the other two being powered to make it go forward/back. What i dodnt understand is how the vex recieves and transmits its data… i know how pwms work and how to create algorythims etc but how do i simply say when this joy stick has this value then make this pwm send this value. and then where in the starter code do i put it?

any help would be appreciated and im sorry if i have missed some really simple resource for getting started…

2

Well i don’t think i can answer all your questions and i have never seen this type of info written anywhere but i will try to help out a little.

I would start by getting the Sensor Test code from Vexlabs because you will need it down the road and build off of that version.

Once you get that look at Your RC and Radio controller while you have ifi_aliases.h open and study all of the inputs and outputs and the names they are assigned to in the code.

On the RC you have motors 1-8 which are assigned to pwm01, pwm02, ect.
You have Digital/Analog I/O 1-16 which correspond to rc_dig_in01, rc_dig_out01, rc_ana_in01, ect.

On the Controller if you look under and beside the joysticks and on the buttons on the back you will see they say channel 1 - channel 6. theses correspond to PWM_in1 - PWM_in6 in the code.

The inputs From the Controller and the pwm outputs range from 0 - 254 and rest at 127 (0 being full reverse, 254 being full froward). these numbers are what you use to control different actions.

The main file you need to be worried about editing is user_routines.c . This is were all of the drive code is stored and where you call your different routines when you get that far. All drive code is in Default_Routine at the bottom of this file.

now if you wanted to drive your three wheeled robot you could just delete the pre defined code below (from user_routines.c ) so there is nothing being overwritten:

pwm01 = PWM_in1;
pwm02 = PWM_in2;
pwm03 = 255 - PWM_in3; // reverse direction of left side (CCW)
pwm04 = PWM_in4;

Then paste in something like this and plug the two motors into pwm1 and 2 and the servo into pwm3:

pwm01 = PWM_in3;
pwm02 = 255- PWM_in03;
pwm03 = PWM_in1; // Drive servo

good luck, hope i could help.

3

Basically, you would use Kevin Watson’s FRC code and use that as your project file, since VEX and FRC both use the PIC8717F22 as a base.

Analog inputs (used for analog sensors like a light sensor) are defined as rc_ana_in01, etc. But to get an input from them you need to use the ADC function, so you would do Get_ADC_Result(rc_ana_in01) to get that value.

Digital inputs are a lot simpler, and you can simply retrun rc_dig_in01.

Digital outputs are rc_dig_out01 etc, but only certain ports can be used as digital outputs.

Motors and servos, are controlled by pwm definitions so you would say, pwm01 = 255 for the motor on motor input one to go full forward (255 full forward, 127 neutral, 0 full backward)

Transmitters i.e., the joysticks, are defined as PWM_in1 and so on. Your defintions can go up to PWM_in12 since you can use two tranmitters, with the second tranmitter using the range from 7 to 12. The good thing about the joysticks is that they map directly to the motors, so when
pwm01 = PWM_in1, if PWM_in1 = 255 (full forward), then you have pwm01 going full forward.

The buttons on the back of the VEX transmitter (Channel 5 and 6) are defined using BUTTON_FWD_THRESH as the button on the top, and BUTTON_REV_THRESH as the button on the bottom.

if(PWM_in6 > BUTTON_FWD_THRESH)
pwm06 = 255;
else if (PWM_in6 < BUTTON_REV_THRESH)
pwm06= 0;
else
pwm06=127;

The above code says that if the button on the top is pushed the motor goes full forward, if the button on the bottom is pushed, full backward, otherwise stay on neutral.

The most important thing about this code is knowing where to place it. ALL teleop code that needs to be executed must be placed in user_routines.c in Proccess_Data_from_Master_uP(). You can obviously make functions in other files in order to modularize your code, but if it’s run in teleop mode (with the transmitter) you need to place the function calls in here.

Autonomous code is found in user_routines_fast.c and in the if case “if(autonomous_mode)” or something like that. Autonomous code can only be implemented if called in that if case, since this prevents sabotage during the competition.

Make sure that if you do write your own functions to handle the robot, like with the transmitter, that you comment out Default_Routine() in Process_Data_from_Master so that you don’t have multiple definitions getting passed, and your robot not moving.

There is a lot of documentation in Kevin’s code, like aliases, so it would be good to read through it, and there is always the documentation on the VEXLabs site.

4

just a quick correction:

DONT comment out Process_Data_from_Master_uP(), as that is where the pwms are updated from. comment out default_routine, and call your own custom functions.

5

right that’s what i meant :slight_smile:

6

thanks for all of your help guys. as soon as i get home from school today ill have to try it out. ill let you know how it goes

7

Another option is to use the WPILib library (EasyC uses it) and MPLab. Do a Google search for WPILib. There is an excellent doc on how to use it and what functions are available.

You can’t get quite as low level as you can with the default FRC code, as it insulates you from needing to know some of the low level details, but it is quite usable.

I thought the Vex used the 18F8520 like the old 2004/2005 FRC boards?

8

as far as i know, its the same one as the current board, and the same default code runs

9

The Vex Controller is definately based on the PIC18F8520 not the PIC18F8722 plus some of the aliases are named different for the rxData and txData data structures. The PWM stuff is different as well.

But just use the VEX default code, set the MLABS IDE device to PIC18F8520 and load the 8520 library and linker script and you should be set to go.

Some of Kevin’s code, particularly the serial stuff has an include for the 8722.h file so this should be changed to 8520.h.

Oh, and remember the slow loop is not 26ms is more like 18ms.

I have ported over the new structure that Kevin wrote this year to the VEX but I have not been able to get more than 4 PWM’s working.

10

I do not mean to thread-jack, but I have a related question regarding Vex and mplab.

I have been trying to get serial communication working on the vex using Kevin’s code. Everything seems to be fine, I can send stuff to a terminal application like hyperterminal just fine, and the oscilliscope also shows output in the expected range. But, when I am trying to read in the data from a separate serially connected microcontroller I am not getting consistant output.

I have a Vex controller connected to an ABB (Atom bot-board) with an Atom28 on board. I can capture the signal sent from the Vex, but it seems to be flipping bits (sometimes it reads as 90 sometimes as B0, neither are correct). I do not know why.

I am trying to read it as I8N1_115200, but I have tried other serial modes with no success.
The Atom does not expect a “\r” and it expects 8-bit words. I have written a simple output function to reflect this, but it still does not work. (Again, communication to a terminal program is fine.) As far as I have been able to determine, everything on the Atom side is working as it should be expected.

Does anyone have a suggestion for this? Has anyone successfully gotten the Vex to communicate with other microcontrollers?

11

Let me second using the WPILibrary and the MPLab compiler for the Vex. The library does a lot of work for you and makes it very simple to do complex control programming in a few lines. There is very good documentation on all the calls.

On the serial port question, I’ve hooked a number of different serial devices to the Vex.

  1. Are you sure you have the right voltage levels? The serial ports are at a TTL, not RS-232. When I connected the Garmin GPS I used the orange Vex box to convert the levels. There was also a null modem between the GPS and the orange box.

  2. Baud rate - are you sure the baud rates and the bit configurations are set?

  3. Are you polling fast enough to get the bits back without a buffer overflow? Do you get framing errors?

Are you using the base code, WPILib or something else?

12

I hope you don’t mind if I make you my new best friend then. I have been trying to get to this to work for months.:stuck_out_tongue:

Yes both boards operate at TTL levels.

That is one area that I might be having trouble with. I can easily control the baud rate and settings for the ABB, but the Vex is a little more confusing to me. I believe I have it set to No parity, 8 bit transmission, at 115200 baud.

I thought I read that the Vex serial is not inverted, but I can’t capture anything from it unless I have the serial input (on the ABB) set to inverted.
Also I can’t confirm that information as correct.

I am not exactly sure what you are asking. What do you mean by get the bits back? The atom does not have a buffer. It is, of course, possible to make a software driven buffer, but that has its own issues.
By “get framing errors” are you asking if an error flag is being set? I never thought to check for that. When I started on this task I knew nothing about serial communication, nor even very much about PICs.
I am still trying to assimilate all the necessary data, compile it, and integrate it into my knowledge base. I am not a robot.

By base code do you mean the Vex startup code? If so, then yes. With Kevin Watson’s serial_ports stuff involved as well. That was the only way I could find to control the serial comm on the Vex. If there is an easier (or more robust) solution, I would love to hear it.

13

DanielR. I sent you a private messagewith some code samples in it, did you get it?

Thanks!
Foster

14

I wrote a short tutorial on using MPLAB with the WPI Lib here if it helps.

15