VEX – Engineer On The Loose

Vex Cortex Teardown – part 1

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.

Competitive Robotics – introduction

Robots No Responses »

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.