Lorentz forces and cheating at the Pinewood Derby


So...it wasn't quite as good as I was getting before.  My explanation is that battery voltage will always tend to sag a bit when you draw large currents.  Pulling an amp through one of these cells might drop the output voltage by 500mV or so.  Drawing an amp through five of them combines their voltage drops and dips the output voltage down to 17 or 18V.  This substantially reduces the output of the motor and slows things down.

Either way, it was far too late to do anything about it, so on to race day!

FORTH!? Behind a dalmatian!

What happened?

So there are three factors that contributed to my car not performing like I'd hoped.  Firstly, even at its best, the car generated very little force.  With more time to properly design/tune the motor, I probably could have greatly improved the efficiency, but as is, it's more of a proof-of-concept.

Secondly, I had remembered the steel starting gate correctly, but I had forgotten exactly how it was shaped.  Rather than any kind of door or gate, there's a simple steel bolt in the center holding the cars back.


There's a very good chance that the bolt wasn't wide enough to effectively trigger my reflection sensor.

Finally, the biggest reason my motor didn't work was the air-gap between it and the track. In order to get any appreciable amount of force out of the motor, the distance between the stator and rotor had to be minimized.  Unfortunately, I had forgotten how the track was designed.

Thinking back to my Cub Scout days, I had assumed the track was like this:

cubscouttrackWhich would have placed my motor very close to the aluminum rail.  In reality, the track was shaped like this:

newtrackWith two separate rails:

newtrackpicSo even if I had tuned the motor perfectly, it would have been very difficult to get it to work across an air-gap of nearly 10mm. Even large industrial machines typically have an air gap less than 1mm.


Despite losing the pinewood derby, I am very pleased with how the whole project turned out.  I was able to learn a lot about induction motors, and everyone was pretty impressed with my ability to fling small pieces of tinfoil across a table.

I'm also really proud of the paint job! Even after its batteries die, I think this car makes one hell of an ornament for a shelf.  It'll have to do until I can afford a real Tesla...

Looking back, the only part of the project I'm still a little miffed about was losing to this jerk:


Download the files for this project here: Tesla package v1.0

Table of contents

13 thoughts on “Lorentz forces and cheating at the Pinewood Derby

  1. I'm curious as to whether your firmware could've been improved further by refactoring the interrupt. Because interrupts must not change the state of the chip, the routine begins by pushing every register it uses onto the stack, and ends by popping them back off. The compiler is pretty bad at reducing number of registers used, so complex interrupts may have an overhead of about 30 cycles(15 registers, pushed and popped), about 2us at 16MHz, per interrupt.
    This could be improved by reducing the complexity of the ISR, programming it in assembly, or by abandoning the interrupt and refactoring the timing-critical code into the main loop.
    I'm not sure what your code looked like at this point, or what kind of timing requirements you had to meet at your fastest frequency, but I imagine that it could be possible.

    • Oh yeah, I'm sure I could have done a lot to make it faster. I'll upload the code and design files tonight if you're interested. I've only done assembly on the 8051, and I didn't have enough time in this project to figure all of that out for the AVR, so I opted for more coils/slower frequency. Based on the measurements I took, I'd need to get my switching down to something like 5us per interrupt if I wanted to make it work with the smaller coils.

      • Neat project!

        Your best bet on AVR is to just unroll the switching (you only have 6 steps -- explicit code is way smaller than accessing data) and don't even bother with interrupts. You can use a timer to set the overflow flag or similar, but you can just spin on that flag and clear it from software (write back the value you read) rather than even bothering with jumping to the vector, setitng up the stack, etc.

        That being said, I do software PWM very similar to yours at much higher speeds with interrupts, but written in assembly, and with some tricky tricks like using "ijmp" as the interrupt vector. Doing that from C would be particularly fun. Last I experimented with naked interrupts on AVR, GCC would like to emit random moves to unused registers at times, making it very difficult to manage your own stack unless you just inline-assembly the whole thing. You can, however, reserve registers for this purpose, which is nice.

  2. Nice job. I enjoyed reading it. You should test the motor again with the aluminum piece but use a piece of wood or plastic to give you a bigger gap between the motor and aluminum. Then you can see how much the bigger gap affected things.

  3. >The strange thing is that it only ever used 17% of the processor and if I started another instance at the same time, it would take another 17%.

    100/6 = 16.6667

    It was a single threaded task, so it could only use one core.

  4. Pingback: Bookmarks for October 13th | Chris's Digital Detritus

  5. Pingback: TECNOLOGÍA » Lorentz forces and cheating at the Pinewood Derby

  6. It kills me that you have to drop your voltage from 20V to 10V! Use a hardware timer (if available) to generate a 100 kHz PWM (if you can) to wave-shape the current and you wont need to! Your ultra-small inductance is working against you here.

    DRV8313 is my favorite motor driver.


    • I'm actually already using the hardware timer, but it's a pretty complicated waveform to generate entirely with hardware timers (three phases and all that), so I ended up just increasing the number of turns.

  7. Pingback: Ultrasonic parking sensor | ch00ftech Industries

  8. Pingback: Lorentz forces and losing the Pinewood Derby | ch00ftech Industries

  9. Pingback: Animated EVSE | ch00ftech Industries

Leave a Reply

Your email address will not be published.