Nov 022014

The Innovation First VEX line of robotic components consists of a wide range of structural, sensing, and motion actuating elements. All of these sensing and actuating components are driven by the one and only control component, the Vex Cortex.

The Vex Cortex is the controller, or the brains, for a VEX robot. The Vex Cortex sports an ARM processor for user programs, 8 12 bit analog inputs, 12 digital input output ports, 2 UART ports, a single I2C port, 8 3 wire RC servo motor compatible outputs, and 2 H-Bridge 2 wire DC motor driver ports.


Today we’re going to walk through the first part of a tear down of the Cortex controller. The reason we’re doing a tear down is that as nice as the Cortex is it suffers from at least one well known weakness, the built in H-Bridge motor driver ports are undersized and prone to burn out under normal use.

The 8 RC style motor drivers rely on external plug-in H-Bridge motor drivers. If a motors stalls or over currents the external bridge can burn out but it is easily replaced. If the built in H-Bridge drivers burn out the Cortex is permanently damaged. Innovation First, the makers of the VEX Robotics line, including the Cortex, will disavow all responsibility after the warranty period runs out. Even if, in my opinion, the weak design of the internal motor drivers is the root cause of the failure.

VEX Forum\Official Technical Support\Cortex started smoking

VEX Forum\Official Technical Support\Possible Cortex Motor Controller Burn-Out?

With the right tools the internal H-Bridges can be replaced and the Cortex brought back to full functionality. The repair of the motor drivers will be covered in another post.

Keep in mind that opening the Cortex probably voids your warranty, and modifying the Cortex surely makes it ineligible for competition. Given that caveat, here we go.

Disassembling the Cortex is straightforward, flip the Cortex on it’s back and you will see four philips tip screws, one in each corner.


After removing the four screws gently pry apart the front and back covers. The circuit board will likely stay with the back of the housing with the front cover lifting off easily.



With the top off of the Cortex the main circuit board is exposed.


After removing the top gently pry the circuit board off of the bottom part of the housing. The circuit board is just wedged into tabs on the bottom of the housing and is not fixed in place.


The Cortex has two thermal overload breakers inline with the motor control circuits. If the motors draw too much current the breakers overheat and reduce current to the motors, effectively putting the motors, and your robot, out of action until the breakers cool down. The breakers serve to protect the Cortex but pose a serious issue in a competition. The breakers take up to tens of minutes to cool down, effectively putting your robot out of the match you are in and potentially out of the next match as well depending on how fast and furious the matches are coming.


The major components of the Cortex are shown below.


The main system processor that controls the Cortex is an NXP LPC2458FET180.


From the NXP website for the LPC2458.

"The LPC2458 microcontroller is ideal for multi-purpose communication applications. It incorporates a 10/100 Ethernet Media Access Controller (MAC), a USB full-speed Device/Host/OTG Controller with 4 kB of endpoint RAM, four UARTs, two Controller Area Network (CAN) channels, an SPI interface, two Synchronous Serial Ports (SSP), three I²C interfaces, and an I²S interface. Supporting this collection of serial communications interfaces are the following feature components; an on-chip 4 MHz internal precision oscillator, 98 kB of total RAM consisting of 64 kB of local SRAM, 16 kB SRAM for Ethernet, 16 kB SRAM for general purpose DMA, 2 kB of battery powered SRAM, and an External Memory Controller (EMC). These features make this device optimally suited for communication gateways and protocol converters. Complementing the many serial communication controllers, versatile clocking capabilities, and memory features are various 32-bit timers, an improved 10-bit ADC, 10-bit DAC, two PWM units, four external interrupt pins, and up to 136 fast GPIO lines. The LPC2458 connects 64 of the GPIO pins to the hardware based Vector Interrupt Controller (VIC) that means these external inputs can generate edge-triggered interrupts"

The datasheet for the LPC2458 is here.

The system processor runs the Cortex system firmware, as opposed to the user uploaded robot control program. The system processor manages the wireless link and the bulk of the communication with the joystick.

The user processor, the processor that runs the user uploaded code, is a STMicroelectronics STM32F103 ARM Cortex-M0 processor.


From the STM32F103 datasheet:

"Medium-density performance line ARM-based 32-bit MCU with 64 or 128 KB Flash, USB, CAN, 7 timers, 2 ADCs, 9 communication interfaces including up to 2 x I2C interfaces, up to 3 USARTs, up to 2 SPIs, a CAN interface, and a USB 2.0 full-speed interface."

Four particularly interesting chips are the drivers for the internal H-Bridge motor drivers. The internal motor drivers form an H-Bridge consisting of an International Rectifier IRF8313PbF HEXFET Power MOSFET coupled with a Fairchild FDS4935BZ Dual 30 Volt P-Channel PowerTrench MOSFET.



The top half of the H-Bridge motor drivers are found on the bottom side of the circuit board.



The Top Half / Bottom Half nomenclature of the H-Bridge comes from the way H-Bridge circuits are typically drawn. The positive voltage to motor control FETs (P-Channel) are typically drawn above (nearer the top of the drawing) and the motor to ground control FETs (N-Channel) are typically drawn near the bottom of the drawing, top half, bottom half.


That pretty much wraps up the interesting chips. The VEX Cortex controller is not a particularly complex board but it is almost all surface mount components which makes it just this side of impossible for most robotics clubs to work on when it fails. At $250 USD each burning up a Cortex is not a cheap proposition.

In an upcoming post we will cover how to replace the motor driver FETs when motor ports 1 and 10 fail.

Jan 162014

Download and install a build environment

The Sparkfun Redbot, Pololu 3pi, and Pololu Zumo robots are all based on the Atmel atmega328p processor. All three have a wealth of libraries and supporting software. All three support at least the two most popular methods of creating code for the AVR processors, Arduino and avr-gcc (Windows and Linux). The two Pololu robots also support the Atmel Studio build environment.

Downloading and installing the Arduino environment is pretty straight forward. Download for your environment, unzip or untar, run. Not much more to it than that.

Atmel has taken over the support of the avr-gcc tool chain and hosts the builds for Windows and Linux. Installing the tool chains for Windows and Linux are documented on the Atmel site.

Get the supporting libraries

All three robots have additional supporting libraries; Arduino style for the Redbot and Zumo, Arduino, Atmel Studio, and straight avr-gcc style for the 3pi. Both vendors, Sparkfun and Pololu, provide links to download their libraries. Pololu supplies prebuilt installers for different versions of their libraries. Both companies also provide source on Github; Redbot / Zumo / 3pi. For the Zumo you want both the Zumo Shield library for Arduino programming and the libpololu-avr library for direct avr-gcc programming.

I prefer to go straight to the source and download the libraries fresh from Github. All of the libraries provide a “Download Zip” link to download a compressed bundle straight to your desktop. After you have the downloaded bundle you can uncompress and install it. I prefer to use GIT directly, under Windows and Linux, and clone the repositories directly to my desktop. Whichever method you use you will eventually have copy of the libraries on your local machine.

To clone the repositories locally under Windows I use the git bash shell from git-scm, under Linux I use git. If git is not installed on your flavor of Linux use your distro’s package manager to download and install it.

Install the libraries

The Redbot and Zumo Arduino libraries need to be installed where the Arduino environment can see them. Arduino provides tutorials on installing 3rd party libraries so I wont repeat that information here. Pololu also provides ample documentation on installing their libraries, for all three environments, Atmel Studio, Arduino, and raw avr-gcc.

For the Pololu 3pi robot I am using raw avr-gcc. The steps I used to install the Pololu libpololu-avr library are:

1 ) Insure you have the avr-gcc tools installed

From a command line run avr-gcc –version
If the program is found move forward, if not, return to installing the avr-gcc tool suite.

2 ) Build the Pololu Library

The Pololu library make file by default builds all of the flavors of AVR libraries for all of the Pololu products that use the library. For the 3pi you only need support for the 168 and 328p libraries.

New 3pi robots are based on the Atmel AVR 328p processor. Older 3pi robots were based on the 168 processor. The example program makefiles still reference the 168 library. At this point it is easiest to keep both the 168 and 328 libraries. Over time it makes sense to migrate to the 328, if you have a newer 3pi robot, but for the sake of expediency build both libraries for now.

Edit the libpololu-avr/Makefile and remove the building and installing of unneeded libraries.


In a command window in the libpololu-avr directory make the libpololu libraries. Simply type make in the libpololu-avr directory. The build process should eventually yield two files called libpololu_atmega168.a and libpololu_atmega328p.a. These are the 168 and 328p libraries containing the functionality provided by the Pololu library.

3 ) Copy the libraries and include files

Next you need to make the libraries and required include files visible to avr-gcc. You can either modify the example make files as you create or re-use code to point to your local versions of the pololu libraries and include files or you can copy the library and include files to the avr-gcc default path. Pololu recommends copying the files into the avr-gcc path.

See the pololu/libpololu-avr/README.txt file:

== Manual installation ==

If you have the source repository of the library instead of a binary
distribution, you will need to build the library (.a) files by running
"make" and also copy all the files in the "src" subfolder into the
"pololu" subfolder.

Next, copy libpololu_*.a into your avr-gcc "lib" subfolder.

Finally, copy the entire "pololu" subfolder into your avr-gcc
"include" subfolder.

You are now ready to use the Pololu AVR library.

Use the make show_prefix to discover the avr-gcc paths used in your install.


– Copy the library files, libpololu_atmega168.a and libpololu_atmega328p.a, into the avr-gcc lib directory.
– Copy the pololu directory, libpololu-avr/pololu, not just the files in pololu, the pololu directory and the contained files, into your avr-gcc include directory.
– Copy the contents, including any sub-directories, of the libpololu-avr/src directory, into the newly copied pololu directory in your avr-gcc/include path. In this case copy the “contents” of the src directory, not the src directory itself, into the avr-gcc/include/pololu directory.

Test your install and build the demo code

If all of the above worked you should be able to change into the libpololu-avr/examples_templates/3pi-demo-program and type make.


Now that you have a hex file you need to upload it to your robot.

I use avrdude directly from a command line. Using the Pololu AVR programmer the command looks like:


If everything worked cleanly you should have a fully functioning build and deployment environment ready to write new code.

Jan 092014

I’ve always been interested in competitive robotics. Two (or more) robots duking it out on the field of honor. Trying to solve a problem as fast or efficiently as possible, all the while trying to avoid, out score, or destroy the competitions robot.

Competitive robotics can generally be divided into to groups, direct combative and competitive problem solving. Both are a lot of fun, although combative can get pretty ugly, and expensive, in a hurry.

Competitive robotics puts a lot of pressure on developers and implementers to find optimal solutions in unstructured environments where other participants are actively trying to out score, block, or destroy your robot. You often need to come up with ad-hoc solutions in the middle of competitions to account for variations in the environment and to counter competitors robots.

Things we’ve had to overcome include changes in playing field surface, broken parts, changes in starting conditions, changes in competition rules that you don’t find out about until you get to the competition, and as always, differences in competitors robots that require you to adapt and modify your strategies on the fly.

In competitive robotics you push, pull, climb, and race to get the task at hand done before your competitor does. Changes in traction on different fields requires adapting your motion platform’s drive system. You can change your wheels, from slicks to diggers, or the other way round. Sometimes simply cleaning the tires, washing the dust and dirt off, improves traction enough to make a difference. Sometimes you need more. We’ve created studded tires by lacing plastic wire ties around the wheel and tire and cutting off the tails to leave the knobs pointing out. You do what you have to do to keep your robot moving and stop the competitors robot from moving.

Broken parts are always a bane. Hopefully you’ve built your robot to be maintainable. Motors die, drivers burn out, axles twist and break, screws fall out and pieces fall off. Broken parts require more an act of Nascar like pit crew skills than design changes. How fast can you swap out or adapt parts, under pressure in the middle of a competition, while maintaining a competitive robot. Sometimes you just work around the broken part, changing code to not use the broken functionality or adapting other sensors or actuators to try to work around the broken parts.

The four robot platforms I’m actively using are the

IFI Vex Robotics line,

Pololu’s Zumo Mini Sumo bot,

Pololu’s 3Pi,

and Sparkfun’s Redbot.

All of these platforms are extensible in various ways. Each of them have varying degrees of physical reconfigurability, with the VEX robot being the most physically reconfigurable, the Redbot next, then a toss up between the 3Pi and the Zumo (at the level of not much). All four platforms support adding sensors and of course full reprogrammability. The 3Pi, Zumo, and Redbot benefit from having the same microcontroller, the Atmel Atmega328p, and the same programming environment, Arduino or avr-gcc. The VEX controller is based on an ARM Cortex controller and uses the quite capable (but not free) RobotC development environment.

The VEX ARM processor arguably provides a much more powerful computing platform but is a more closed environment. The Redbot was designed to be modified with multiple sensor and actuator mount points and a fully open design. The 3Pi and Zumo have an open software development environment but suffer from a more closed hardware platform. Both the Zumo and 3Pi robots are able to be extended physically but not as simply as the Redbot or VEX robots.

The VEX robot, while powerful and benefiting from a reasonable line of accessories, is pretty much closed. The manufacturer, IFI, provides scant documentation on the VEX controller internals.

Each platform has different strengths and weaknesses.

The VEX line is expensive and relatively closed. The platform is physically very reconfigurable and being targeted at middle and high school students is pretty robust. The IFI provided sensors are mechanically robust and easy to interface. The downside of being targeted at students is the platform is not easily extended. IFI / RobotC provide few opportunities to step outside the bounds of the RobotC development environment. The upside is, it is harder for a student to get too far afield. The downside is, it is harder for a student to bring new innovations to the platform.

The Redbot line is fully open and extensible. The schematics, board layouts, and platform components are open and documented on Sparkfun’s website. The Redbot is probably the least robust physically. The Redbot is a great development platform but with an eye towards high extensibility and low cost it is probably at the highest risk of taking a catastrophic hit in a competition. That said the Redbot might be the best price to performance platform of the four. The Redbot’s size makes it too big to qualify for mini sumo competitions.

The 3Pi platform is hands down the best choice for line following competitions. It is pretty much designed to be fast and excel at line following. The 3Pi is low to the ground, is probably the fastest by far of the four robots mentioned here, and has a built in integrated line sensing array. The 3Pi platform provides for some extensibility. The 3Pi can be readily extended with sensors and other electronics but the motion platform is pretty fixed. Pololu sells a prototyping shield for adding sensors and other electronics. They also sell replacement motors with different gear ratios to achieve different speed to torque characteristics, but that is about it. Two wheel pivot steering with a caster is pretty much all you get. The 3Pi also requires a pretty clean and unobstructed field. The wheels are on the smaller side and not made for climbing or rough surfaces. If you are doing line following, maze solving, swarm bots, stuff that relies mostly on interesting software solutions and limited environmental interactions the 3Pi is the way to go.

The final robot I actively use is the Pololu Zumo. This bot is specifically a mini sumo pusher bot. Like the 3Pi, the Zumo is optimized for mini sumo competitions. Like the 3Pi the physical platform is not readily extended. The mini sumo rules limit the weight and footprint of the bot, so large physical changes to the bot are probably not in the cards anyhow. The Zumo allows for some sensor extension but the base platform with the sensor array consumes most of the available IO of the 328p microcontroller. Like the 3Pi the motors can be changed to achieve different gear ratios. Also similar to the 3Pi the Zumo relies on two motor slip skid steering. The Zumo is a tracked platform and has a pretty good grip but again like the 3Pi it requires a relatively smooth obstruction free playing field.

Each of these robots solves a different problem in a different way. For line following competitions and newer roboticists the 3Pi is the way to go. For mini sumo the Zumo is great platform. For the home hobbyist the Redbot is probably the best answer. For a more physically extensible and more powerful (and significantly more costly) platform the VEX line is the way to go.

In the end all of the robots are great solutions each with it’s individual strengths and weaknesses. Pick the one that best fits your style or target competition and go for it!

Here’s hoping to see your robot on the competition field.