Vex On-Line Controller Code v2.x, ROAD MAP

VEX V5 General Discussion Technical Discussion
1

This is the Road Map I have planned for the “Vex On-Line Controller Code v2.x, Available Source Version”. I have just released v0.81b, so the features of v0.82b and later are tentative, and do not constitute a contract to deliver these features.

***** v0.80b *****

***** INITIAL RELEASE *****
Modified Vex_UserCode_DDT (Dynamic Debug Tool) to “mimic” the Vex On-Line Code for IFI/intelitek Loader 2.x.

***** v0.81b *****

ANALOG/DIGITAL I/O is now selectable with a Single Function Call, “DefineControllerIO()”.

Function “OnLine_Broadcast()” automatically prints out the correct number of ANALOG and DIGITAL INPUTS.

Supports OUTPUT Control of I/O Ports 01-10, if you are not using them for INPUT.

***** v0.82b *****

Support for the Ultra Sonic Sensors and Encoders as a Vex Controller processed device. This is needed because of the tight timing requirements for accurate data. Sending the Raw Data from these Two devices over the Serial Link with its inherent variance would result in unusable information.

Support for Setting, Re-Setting, and Deactivating the Interrupts.

Support for Setting, Re-Setting, and Deactivating the Timers.

***** v0.83b *****

Add back in Support for the Vex DDT (Dynamic Debug Tool).

Support for Mutually Exclusive Modes or possibly a Mixed Mode of the Vex Controller’s communication. Depending on the Init Message, the Vex Controller will either respond to Vex DDT REQUESTS or send On-Line Code 2.x BROADCASTS. (See REQUESTS or BROADCASTS in Post 43026)

***** v0.84b *****

Add in Support for Vex Controller to Vex Controller communication.

Refine or Add commands to let One Vex Controller, control another Vex Controller.

***** v0.85b *****

Add in Support for More that Two Vex Controllers to communicate together. (AKA Device ID Numbers)

Add in Support for Hardware so that More that Two Vex Controllers can be connected together.

***** v0.86b - v0.89b *****

Implement RO-CIP.

2

Great work! I would like to see these new functions since I have used the DDT and JVEX but did not have access to all the Vex sensors. My application is to control my Vexplorer using Vex DDT and an XBEE Pro Wireless Modem to send motor commands and receive telemetry at 115200 Baud using Easy C 2.0 and Microchip PIC18 C.

The information that you provided on the DDT Message formats was very helpful in my understanding how the Vex Controller works. Soon I hope to interface the Vex Controller to a Micropchip 32-Bit PIC32 microcontroller to enable my Vexplorer to run autonomously.

3

Thanks for the Complement! I really want to see a Full Featured control protocol for Vex, and other Robots.

I have been working on other things this last week, so I have been only thinking about the features in release v0.82b.

Support for the Ultra Sonic Sensors and Encoders as a Vex Controller processed device. This is needed because of the tight timing requirements for accurate data. Sending the Raw Data from these Two devices over the Serial Link with its inherent variance would result in unusable information.

Support for Setting, Re-Setting, and Deactivating the Interrupts.

Support for Setting, Re-Setting, and Deactivating the Timers.

I am think of an Array of Function Pointers, (for efficiency, of course) that will call a default function, (or could be “chained” to your own function) on the termination of a Timer, or on the Input of one of the Interrupts. Every Timer and Interrupt would be activated, just being sent to a Dummy Function.

The default function would processes the Raw Data from the Ultra Sonic sensor and give a unsigned int or long unsigned int with a measurement in Millimeters, or Inches (or Tenths of Inches) or the Encoder and give a Direction (with the Quadrature Encoder) and a Pulse Count.

The Encoder might need to have a Feature that I did not put on the Road Map, and that is a Macro Language. Think LOGO for your Vex.

Imagine sending this to your Vex on the Serial Link:

FORWARD 100 ; moves the Vex in a square with sides 100 units long
LEFT 90
FORWARD 100
LEFT 90
FORWARD 100
LEFT 90
FORWARD 100
LEFT 90

And have it Move Forward for 100*90 Encoder Clicks, then Turn to the Left, 90 Degrees, and the Move Forward again, and so on…

Ah well, time for bed… And I need to get some Ultra Sonic Sensors and Encoders.

4

When I was working on a serial control protocol for my vex robot last year, I struggled with various conflicting criteria. Ideally, I wanted a protocol that could be operated from a terminal program using easily typed commands, with responses from the Vex controller that were easily read and interpreted on screen. But I also wanted low overhead on the Vex controller and high throughput.

I ultimately gave up on human readability and decided to write software on the PC side to handle the human interface. In this way, the vex controller communicates parameters in the native binary form that they stored in the controller. This is very fast. The serial routines were adapted from Kevin Watson’s interrupt-driven buffered serial routines. They run in the background with very low overhead.

The message format was a 8-byte message as follows:
byte 1 - sync character
byte 2 - sync character
byte 3 - message type
1=read analog channel
2=read digital port
3=read compass
4=read ultrasonic
5=read encoder distance
6=read status
7=read motor
8=set motor
9=set digital port
10=set compas bearing to hold
11=set distance to move
12=execute move
13=set control mode (radio or pc)
…etc
byte 4 - channel or data (bytes 4-7 depend on the message type)
byte 5 - data byte 2
byte 6 - data byte 3
byte 7 - data byte 4
byte 8 - checksum (sum of bytes 3-7 without carry)

The Vex controller would respond with a similar message:
Byte 1 - sync
byte 2 - sync
byte 3 - message type
1=analog data
2=digital port
3=compass heading
4=ultrasonic distance
5=encoder value
6=current status
7=current motor value
8=acknowledge motor setpoint
9=acknowledge digital port set
10=Current direction setpoint
11=Current distance setpoint
12=Moving
13=Acknowledge current control mode
…etc
byte 4 - channel or data
byte 5 - data byte 2
byte 6 - data byte 3
byte 7 - data byte 4
byte 8 - checksum (sum of bytes 3-7 without carry)

This is approximately the state that the software was in before it was all lost in a hard drive crash.

5

I am working this direction. I agree that Binary is the most efficient (and I have a big Bias for protocols like J1708/J1587, J1939 and RV-C, which are Binary Protocols)

Phase v0.83b will include the “Support for the Vex DDT (Dynamic Debug Tool)”, which is what the Kevin Watson code is similar to. Data from the Vex DDT is delivered on Request, not Broadcast like the EasyC On-Line Window is expecting (See Request and Broadcast in post 21).
I started with the EasyC 2.x On-Line Window, because that PC Software was already available and working. I expect that others will write their own PC software to control the Vex software that I have provided, and modify both the PC and Vex software to solve their Mission Requirements.

I want to add support for an execution-indexed state machine in the Code as well. This won’t provide REAL Multitasking, but it is closer. :wink: I would further like to add some Multitasking using some Assembler Routines developed by an Embedded Programmer in Egypt. (Link forthcoming)

** NEW LINKS ADDITION **

Gamal Ali Labib is an IT consultant in Cairo, Egypt. He specializes in IT security and IT turn-key projects management. He is also interested in parallel processing and VLSI. Dr. Labib has a B.Sc. and M.Sc. in computer engineering and electronics from Ain Shams University, Egypt, and a PhD in computer science from University of London, U.K. You can reach Dr. Labib at [EMAIL=“[email protected]”][email protected].

Articles:
The basics of embedded multitasking on a PIC: Part 1 - Reentrant multitasking
Basics of embedded multitasking on a PIC: Part 2 - Packing Programs for Tasks
Basics of embedded multitasking on a PIC: Part 3 - Preemptive task scheduling

Thanks for posting what you had… I will work it in as well.

6

Look forward to your finished code. As a user, I would like to see better data displays on the terminal for debugging sensor and control software. When I ported my Vex bbot software to the DEMOQE128 evaluation board (https://vexforum.com/showpost.php?p=38736&postcount=102) , PEMicro had a nice utility that did serial graphing on the terminal.
http://www.pemicro.com/fixedlinks/DEMOQEToolkit.cfm
Maybe you could eventually work something like this into your functions.
If you want to look at the freescale flexis drivers used in the demo , let me know. I think Vex controller could interface directly with this utility without much modification.

7

) , PEMicro had a nice utility that did serial graphing on the terminal.
http://www.pemicro.com/fixedlinks/DEMOQEToolkit.cfm

That is a Great Idea!! I have asked a few people here to develop PC based Control Programs for the Vex On-Line Code. Maybe we need a Graphic Terminal Program Module too.

Does pemicro have and documentation on their graphing??

Yes I would be interested in seeing the FreeScale Flexis Drivers… I am interested in all Transfer Protocols. :wink: I just find this sort of this fascinating. :wink:

8

The freescale coldwarrior IDE download has the demoqe128 accelerometer example and you can also download the documentation for the demoboard that describes how to format the data for the accelerometer demo. Also might download the PEmicro DEMO128toolkit that has the sw for the terminal programs.
These are free if you register with freescale.

You can also download the DEMOQE128 manual from digikey

[http://search.digikey.com/scripts/DkSearch/dksus.dll?pname?site=ca;lang=en;name=DEMOQE128-ND

If this is too time consuming for you, I could zip just the accelerometer project code.
Chris](http://search.digikey.com/scripts/DkSearch/dksus.dll?pname?site=ca;lang=en;name=DEMOQE128-ND)

9

You can also download the DEMOQE128 manual from digikey

http://search.digikey.com/scripts/DkSearch/dksus.dll?pname?site=ca;lang=en;name=DEMOQE128-ND

If this is too time consuming for you, I could zip just the accelerometer project code.
Chris

Not a problem… I downloaded the “Download DEMOQE Toolkit” yesterday (free to download is good by me). Thanks for the new links. I will get them today (got Comcast, no download caps until OCT-2008 :wink: ).

Since VexLabs is bringing out a to support it with the DEMOQE Toolkit.write some code

10

Great work !!!:slight_smile:

11

Thanks for the complement. :wink:

I have been slowed down recently. I am working on the v0.82b phase:

***** v0.82b *****

Support for the Ultra Sonic Sensors and Encoders as a Vex Controller processed device. This is needed because of the tight timing requirements for accurate data. Sending the Raw Data from these Two devices over the Serial Link with its inherent variance would result in unusable information.

Support for Setting, Re-Setting, and Deactivating the Interrupts.

Support for Setting, Re-Setting, and Deactivating the Timers.

=======================================================

I am also helping a few people with programming questions as well, and some “day job” real work issues are getting in the way of my free time for this kind of thing too.