Building a Scalextric Digital 'Autopilot'

This Christmas I wanted to build something Scalextric-related for my nephew, so I figured a custom built dual channel 'autopilot' could be a fairly simple but very useful thing. Autopilot maybe sounds a bit too high-tech compared to what this device actually is. Simply put, it's only a custom built hand controller without spring-returned throttle. Nevertheless, it can be fun to have if you don't have any friends over but still want to have some other cars on the track (so called pace cars).

Here's a quick guide how to build one yourself.

What you need

• A suitable box
• A cable with a 2.5mm plug for each channel
• Two buttons/switches per channel (brake switch can be left out if not needed)
• One 5 kohm linear potentiometer + a suitable knob
• One 17.6 kohm resistor for the brake switch per channel
• One 8 kohm resistor for the lane change switch per channel

Instructions

To start with, a schematic of a hand controller.

Schematics of a Scalextric hand controller and which is replicated in the autopilot.

When the electrical connections figured out, get a suitable box to fit the amount of channels you will be using.  For cabling I used a 2.5mm stereo plug-plug cable that I cut it in half. I couldn't find a mono cable, so I used a stereo, which works equally well.

Cables mounted through rubber grommets.

To more easily get the holes drilled for the components I created a paper template that I just layed on the box. Then it was easy to mark the holes in the plastic.

 

 

 

A paper template for the holes needed and the components that will be mounted in the holes.

With the holes drilled and the components mounted in the holes, it's time to heat up the soldering iron. I used the legs of the resistors to connect the switch buttons together.

Components mounted, resistors put in place and everything soldered together.

When everything is connected, test that all channels works, and then just screw the cover on the box back on. To give it the right looks, add some scalextric logo =)

Here's my finished autopilot box.

The finished controller box with a scaley logo taped on it for better looks.

Chipping an AUTOart Peugeot 307 WRC 2005

I found this car on eBay quite cheap, and as I had a saloon chip laying around I figured it was time to get a car to put it in.
It was a bit of a gamble as I didn't know if I could fit the chip inside it. But as I've managed to do it on a Mitsubishi from the same manufacturer, I figured I could give it a try. However, when I got the car and popped the body on it, and desperately trying to find a suitable spot for the chip, I just had to give up with the conclusion that it's not possible to fit the saloon chip without destroying quite a bit of the nice looking interior.
I had to get a one-seater chip instead and hope that it would fit...

So, today I got the F1 chip and took a new look inside the car, and this time I found a spot to mount it in! So, let's get started.

Car's body removed

 The place that I found for the chip will be just underneath the hood of the car, i.e. above the car's guide blade. In this spot, the chip can be mounted without having to do any sort of modifications to the car's body or chassis, which makes it a bit easier. The downside, on the other hand, is of course the risk that it will touch the gears on the front axle.

I begun with stripping away everything on the chassis, i.e. both wheel axles and the motor. The wheel axles have some kind of locking mechanism on top of the bearings. These have to be twisted about 45 degrees to get loose.

Remove the bearing locks by turning them counter-clockwise

To get rid of the motor, the connections to it must be soldered off.
Now with everything removed, it's a bit easier to get the work done. I started with drilling the 3mm hole for the IR LED just in front of the holder for the driving shaft's bearing.

Everything in the chassis removed and the 3mm hole for the IR LED drilled

 To get the IR LED kept in place, I added a small amount of glue,

A bit of glue keeps the IR LED in place

Next I added a bit of extensions to the motor cables, and soldered them to the chokes on the motor (the resistor-like things). I let the original cables from the guide blade to be where they were and soldered the green and yellow cable to each of them. Every solder got a bit of heat shrink tube to protect from short circuits. I added some small strips of electrical tape to protect the cables from contacting the axles. The back-side of the chip also got some tape to protect it from a metal mesh in the hood and the LEDs for the driving lights.

Everything put in place. Note the chip upside-down in the front of the car.

To get the chip to be kept as high up as possible (and hopefully not touching the gears), I added a rolled piece of tape on top of it (see picture above) which will make it stick to the inside of the hood. When I had mounted the body, I gave the chip an extra push upwards with a screwdriver through the wheel arc to make sure it really stuck to the hood.


And the final result:

The underside of the car, where the IR LED is visible.

The finished result

Chipping an AUTOart Mitsubishi Lancer Evolution VII WRC

I finally took the time to chip my Mitsubishi Lancer Evolution VII WRC from AUTOart.

After popping the hood, this is what's revealed. What one immediately notice is that it's very little space for the chip in here (as the car is apparently not designed to be chipped). Another problem is the placement of the IR LED as the drive shaft is in the center of the car.

I started by removing all the stuff inside the car, that includes both wheel axles, engine, cables and the switch with which you can choose the polarity to the engine. I then drilled the front-most hole to suitable size for the LED.

 The problem here is that the dive shaft will short the LED's pins, so I tried getting it as low as I practically possible, however not all the way down as that could risk it touches something on the track. A bit of electrical tape on the LED's pcb should protect it from shortening...

I found that the chip itself can only be positioned on the left side of the motor and as far to the front as possible. The chip does also need to stand flat on the bottom which requires some cutting of plastic enforcement aligned with the rear-end of the motor's fittings.

 Another problem is the light's pcb in the car body. This must be cut loose in one end and bent back as far as possible to make room for the chip (see blue frame in above pic).

After this, it's just a matter of soldering all wires together and below is the result:

 Underneath you can see the IR LED between the front axle and the motor.

Scalextric Car ID Sensor

Of course I also have to build a car id sensor for my digital scaley track.
On the same great Electric Images site both electrical schema and PIC assembler program are provided for you to build your own.

My goal is to have support for at least four id sensor on the track. Two at the start/goal line of course,  and one at each end of a future pit lane.

Building a test setup

I've only tested the id sensor on my breadboard so far, but I had some problems getting it to work (as usual...).
After getting the components needed and the circuit built, I ran some first tests just to see if the confidence LED blinked, but no, nothing happened... I started analysing the assembler code to find out how it works. I measured the timing of the IR signal from the car with my oscilloscope and created a stimulus profile in MPLAB to simulate the same car. The simulation showed no signs of problems, so I just tried fiddling with the span for each car id that the program accepts. Suddenly I got some flashes from the confidence LED and thought I had solve the problem.

Sending the serial data to the computer

After getting the LED to show signs of successful id sensing I connected the PIC's 7th pin to the powerbase's USART port and modified its code to send the data over the USB cable so I could verify that the correct car id is actually sensed. After some struggeling with the USART configuration I got some garbage data sent to the computer. I blamed the PIC18F for the garbagage data and got a RS232 chip from the radio schack to be able to connect the PIC directly to my computer's serial port instead. What a disappointment when I realized that more or less the same garbage showed up through the serial port too. Now I tried to find the fault in the serial sending part of the code and did some more debugging in MPLAB, just to come to the conclusion that it seemed to work. The only strange thing was some undocumented OR:ing with the hex value of 0x30 and 12 bits package size, which in itself hadn't anything with the garbage data to do.

Finding the cause of the problem

I realized that I had to start debugging at some really basic level, so I modified the program to send the hex value of 0x55 (10101010) continuously on the serial out pin. I hooked up my oscilloscope and measured the bit timing. AHA! Now I finally found something that wasn't right. The bit timing was way off. It should have been 17.6uS (@ 57600bps) but it was something in the 25uS region. Now the question was, why?!
As the PIC contains a built in clock, it had to be something wrong with it...and yes, at the program memory address 0x3FF where the factory calibration value is saved, I did only find the value of 0x00. Not good....

Fixing the clock problem

Luckily I'm not alone with the problem, and after a short trip to google I soon found sites describing the issue and how to fix it. At this page a complete circuit schema and assembler program are provided to recalibrate the built in clock. Soon I had built yet another circuit and got a new calibration value. Using the tip at this page on the same site, I marked the pins on the PIC according to the binary value of the calibration value, to (hopefully) never have to the recalibration again =)
This time the original id sensing program worked for real and the data sent over the serial line worked perfect!

 

In the video the car is programmed with id 3.

Next thing is to figure out a way to support 4 of these serial data lines on one cable, preferably the same USB cable as to the power base.

The Scalextric Digital Power Base project (Part 3)

The PIC software

The software running in the PIC processor is of course taken from the same site as the electronic schema, i.e. Electric Images. I didn't get it to work right away, but after some tinkering with linker scripts (that also takes care of not writing over memory space used by the bootloader) etc, I finally got it compiled and running on the device.

USB Interface

Next challenge was to implement the USB communication. Using this blog I got some inspiration and hints on how to make it work.  After some troubleshooting trying to get data sent from the device to the computer, I realized that I still had some errors in the linker script. This time regarding the memory position of the USB I/O buffers. After fixing that, the communication worked like a charm. Next step was to implement some functionality for the USB communication. In the ProcessUsbIO(void) function I added the following two commands:

switch(ReceivedDataBuffer[0])
{
  case 0x80: // Set remote controlling
    use_remote_data = ReceivedDataBuffer[1];
    break;

  case 0x81: // Send/Receive track/car data
.
.
}


The first command, 0x80 sets a boolean variable that tells the base station to use USB data for sending data to the cars. The other command, 0x81, sends the current handcontroller states to the computer and receives commands to be written to the cars.

Overriding the hand controllers

In the original digital base controller, when connecting it to a computer, the computer takes complete control over the power base. That means that all data from the hand controllers are flowing through the computer before being sent to the cars. So I made some changes to the PIC code so that it would send the commands through the USB interface and read them from there to be sent to the cars. To my surprise it was a quite easy task and did work pretty well without any notice of delays or lags, using 10ms read/write intervals.
The logic in the PIC to handle the data to and from the computer (command 0x81) looks something like this:

  case 0x81: // Send/Receive track/car data
    ResetToSendDataBuffer();

    ToSendDataBuffer[0] = 0x81;            // repeat command id
    ToSendDataBuffer[1] = PORTCbits.RC0;// track power enabled
    ToSendDataBuffer[2] = amps_read;    // amps used on track (raw ad value)
    ToSendDataBuffer[3] = live_buf[0];    // track packet type
 
    // loop through each car data
    for (car = 0; car < 6; car++)
    {
      BYTE breakData;
      if (pre_car_brakes[car].bits.on)
        breakData = 0x80;
      else
        breakData = 0x00;

      ToSendDataBuffer[car+4] = pre_live_buf[car];
      ToSendDataBuffer[car+4] |= breakData;
    }

    TransmitDataToHost();

    // only write to live_buf if remote data is set to be used and speed packets are written to the track
    if (use_remote_data && live_buf[0] == PKT_SPEED)
    {
      for (car = 1; car < 7; car++)
      {
        live_buf[car] = ReceivedDataBuffer[car];
        car_brakes[car-1].bits.on = ReceivedDataBuffer[car] & 0x80;
      }
    }
               
    break;

The basic idea here is to save the hand controller states in temporary variables called pre_live_buf and pre_car_brakes. From there they are sent to the computer. When the computer then sends the commands for the cars, they are directly written to the original live_buf and car_brakes variables used in the original code.

I'll post the full code at some later time as it's not so nice looking at the moment as it's still in a proof of concept state.

The Scalextric Digital Power Base project (Part 2)

The Electronics

PIC Programming

The first challenge I had building the Scalextric Power Base according to the Electric Images' blue prints was to get all the components and to "burn" the program into the PIC18F2550 processor. I thought it's best to buy just the PIC to start with and try to get it working. I found a test circuit board I created in vocational school for a PIC16F84 processor and thought that it must somehow be possible to use the Ludipipo/JDM programmer on it, even if it's as simple as a programmer can be (only three resistors and a diode). Because the test board was designed for a much smaller PIC than the 18F2550 didn't of course fit, so I taped a breadboard onto one side of the test board and connected power and data to it (see pic).

I had a very tough time getting the programmer to work with the PIC, I almost gave up. I probably tinkered with it for like 4 months! before I got it to work (but don't think I'm that crazy that sat every evening with it, after all it was summer so in total it took me perhaps one or two weeks worth of evenings). On the same time, I got to blow some dust off my rusty electronic knowledge.
The trick that finally made it work was found here, a short but very important notice about a low pass filter on the data line that decouples them from high frequent noise.
After I got the programmer to work, I burned a bootloader (such as the one described in this blog post) into the device to be able to program it via the USB interface instead of using the troublesome serial port. When the USB programming went smooth, I could concentrate on the program itself. It took some trial and error before I understood how the MPLAB IDE and the C18 compiler worked, and I didn't of course want to ruin the bootloader that I finally got into the PIC, which of course required some extra fiddling with linker scripts.

Circuit Board

Now that I got something into the PIC, the next step was to try getting all the required components for the power base. After trying hard to find a place selling the BTS7960B half bridge IC on the net I realized that it is discontinued and is replaced with another one, called BTN7960B. This made it a little bit easier as I now found it on digi-key. While waiting for the components to arrive from the states, I begun designing the more permanent stripboard on which the circuit would sit.

To do this I used an application called VeeCAD, which makes the design phase much easier than trying to figure out a working design on the physical board itself.

Download the VeeCAD file here

When I had all the components that I needed and the design was completed I soldered it all together and tried it out using a car directly connected to the output, and to my big surprise it worked the first time!!

When I later connected the power base to the track and added a lane changer (LC) to the game, some bug/design flaw appeared. When the car moved over the IR-sensor of the LC, the car stopped and the LC made some strange noise. Read more about the problem at SlotForum. I still haven't fix the root problem, but found a workaround (described in the forum thread).

The Scalextric Digital Power Base project (Part 1)

Introduction

It all started last Christmas when I got a Scalextric slot car track as a present from my wife. Well, actually I was with her buying it, she just convinced me to take it =)

At first it was of course fun to just drive and re-live the childhood, but I had bigger plans for it! As my nephew already had one of these Scalextric tracks I had got inspired and already had came up with a few ideas of what one could do with it.

The first thing I did was to build a lap-time system using micro switches build into the track, sending the switch's state to the computer through a Toradex I/O card to my custom build application that then signaled a program called Ultimate Racer 3 that took care of the race setup, lap-timings etc.

This worked ok, but when I found out what the digital era of slot car racing meant and I stumbled upon a complete electrical schema and source code for the microcontroller at Electric Images, I thought that I just had to try to build one myself!

The goals that I put up for the project was that I at least should be able to do the following with my setup:

• Control the cars with standard Scalextric hand controllers (duh!)
• Interface it with the computer using USB
• Be able to use existing software that can communicate with standard Scalextric power bases (like the C7042), such as SSDC and PC Lap Counter. The original power base uses the RS485 serial standard to communicate with a computer.

The two last bullets does of course require some custom software to translate my data flowing on the USB line to the protocol used by the C7042 device.

In the coming posts I will describe in more detail about how the project has gone so far, what problems I've faced and what new things I've learned.