“Although there are other Ice Cream Trucks that have raced in PRS, the Phantom ICT is inspired by audio… specifically the sound of traditional Ice Cream Truck music… You'll here it before you see it…”

Built By: http://phantompowerracing.com/
First Race Date: Not Yet
Current Status: In Progress 11/2016

Motor: Alternators, broken, junkyard, $10 each
ESC/ECU: Custom Phantom Power Racing Controller, running on a Xilinx Spartan 3e FPGA, $priceless
Battery A: 36V LiFe, shared with Phantom #48
Battery B, C: Identical
Gearbox: 1:x belt reduction

Our design is based around a Xilinx Spartan 3e FPGA. We have roughly three generations of controller, in which primarily the form factor has changed. The FPGA design was done from scratch without using any library code. It has a FIFO implemented to capture sampled captures of motor current, throttle position, PWM level, etc. It can be triggered by hitting a certain throttle position level, or a current draw level, etc.

ECU Wiring Diagram

The auxiliary power is run at 12V using a DC-to-DC converter. The output of the DC-to-DC is switched using an automotive relay to turn on the load. The primary load is the field drive circuitry for the motors. Without the switch, the load of the field drives is too much to be switched on through the bleed resistor across the main battery disconnect. This circuit allows the battery voltage rails to come up fully before engaging the field drives or the motor controller.

A gui was developed in Qt on the PC. It can plot the data from the FPGA FIFO, calibrate the angle sensors, adjust current settings, etc.

Fusion 360 3D model This may take a while to load.

I spent a lot of time learning DesignSpark and then Fusion 360 to model this design before building and updating during the build.

Here's the design that I'd love to hear feedback on:

Fusion 360 3D model This may take a while to load.

The most interesting and complicated piece is the rear axle assembly:

This holds the Dodge Neon automotive bearing (salmon colored) in place inside an aluminum holder (purple) that's fixed to a block that also holds the motor (pink). The wheel hub assembly (blue) and the axle green are bolted together to hold the wheel on one side, and the pulley (yellow) and pulley/disk brake mount (light blue) on the other side.

Image FoldersRaw Images

3D modeled in DesignSpark with the idea of doing a bolt-together design, because people kept telling me it was a bad idea. Re-modeled in Fusion 360 because the 2D prints, and lack of revision control, constraints, etc. in DesignSpark were painful, and Fusion 360 was released for free.

Everything was built with a Harbor Freight band saw, a drill press, and precision measuring tools. (Excluding the extremely precision machining done for the spinny bits by Union Area Man in his Pole Barn.)

The body of ICT was built out of corrugated plastic board.

Not enough sleep. Destroyed practically everything electrical except the fuses… go figure.

Abandoning the jasontrollers, slowly I hardened my bench top electronics and got them mounted on the car. This time I have a fuse cover among other things that I skipped in my rush to race the first time. So far no fires.

September through December 2016 I designed a magnetic angle sensor bracket, 3D printed my first part to mount the magnet to the alternator shaft, and added it to the car. I documented the FPGA board wiring connections and secured the wiring for the first drive. I built a plywood board for the auxiliary 12V circuitry, with an aluminum box cover and a steering-wheel mounted power switch to turn on the fields and motor controller via automotive relays:

This is mounted on studs with a bungee holding it in place for easy removal during development.

For the past week I had been fighting a weird behavior where the motor would stop drawing current for sometimes several commutation phases in a row before returning to normal. You could hear it hesitating when the motor was controlled under PWM control at about 20% PWM. Jon and Matt stopped by and helped me diagnose this as due to having connected all of the gate drive connections backwards. I had swapped high-side and low side on each phase. This caused the motor to be seeing the wrong polarity at the phases. For example at 20% pwm, the motor was driving one side constant 36V and the other leg 20% 0V and 80% 36V. That shouldn't theoretically cause any trouble, but it wasn't what was intended.

I swapped those. To not have trouble I also had to swap the counter direction for the angle sensor, swap two phase legs, and recalibrate the angle sensor position (which still requires an FPGA rebuild.) The hesitation cleared right up. It turns out that since the high side FET is being powered by a higher voltage generated by the PWM signal from the 36V, it's not okay at certain slow commutation rates when the phase legs spend a lot of time at 36V, because the high side FETs turn off.

I then fired up the throttle and… click… nothing. In the morning I captured this…

That's showing the throttle going up, PWM going up to the rail, and the current going down. I had not flipped the polarity of the current sense, so the current loop was driving with positive feedback. This is a testament to the wisdom of our safety circuit that throws the car into neutral any time it samples the motor current above a set limit. The safety circuit is reset by bringing the throttle to full throttle and then back to zero throttle.

Once inverting the phase current inputs in the VHDL and rebuilding it was ready to drive. But I didn't drive yet. More sleep needed.

On the evening of December 6th, the feast of St Nicholas, 2016: I successfully drove ICT on the ground around to the front of the house and back. It was wet, cold, dark and there were leaves on the sidewalk. But it was an exciting moment to be under power with our custom controller again!

The car had only has one wheel driven, because this was my 'bench top' controller being used for this testing. So the car would only accelerate slowly without either drawing too much current and tripping the safety to neutral, or spinning the tire on the wet leaves. The controller limits clearly needed tweaking. However with careful throttle control the car was able to spin up to a pretty good speed before I put it away. Wheee!

Returning from the inaugural drive. No body, because it's been at Area Man's farm since the Milwaukee race.

As of December 10th the car does drive, but it frequently trips the safety limit that I have put on the current sensors. The current sensor can nominally sense -200 to 200 Amps, and the full range is about -250 to 250 Amps before it maxes out on the rail.

The safety limit is very nice to have in place because it can see a single sample above the limit and put the motor into neutral.

Unfortunately it seems that even if we set a current limit at 200Amps and above, we're frequently 'nuisance trip' causing the car to go into neutral. This requires the driver to reset the circuit by cycling the throttle up to full throttle and back to no throttle before continuing. It seems that the cause is that the fluctuations on the current when the average current is 100Amps or so is sometimes above 200Amps. That means that although our current sensors are rated to 200Amps, they can't handle our 100Amp average current if we want to use them without clipping.

Eventually we're going to build a bigger motor controller. But for now the plan is to scale up the range of the current motor controllers to handle up to 400Amps of current. This will be accomplished by putting a copper wire across the current sensors of an appropriate diameter (resistance) to carry half of the current. Unless somebody suggests otherwise, I'm going to put a piece of 12 gauge solid copper wire across one of the two sensors. I'll then use the controller in PWM control mode and compare the reading with the other sensor and trim or add to the wire as needed to get about 50% of the current reading. I'll then put the same sized copper across the other sensor and check again and adjust until that one matches the first one.

Current Divider Configuration

As a step to this end, I have rebuilt the FPGA with code to pre-load our data-capture FIFO to 75%, because I need to confirm that the nuisance tripping is actually due to the high peak-to-average ratio of the current, and not due to other issues like capacitive spikes, intermittent sensors, control loop parameter problems, etc. Without the preload the data I capture is either too early to see the trip, like this:

This shows a nice capture of acceleration followed by regen (blue is the motor current, red is the current target, green is the pwm). But doesn't show the nuisance trip, which happened a few seconds later.

Or, if I trigger on the trip condition, too late and only shows the current falling off after the trip. Like this:

With a preload I should be able to see exactly what's going on.

I learned you should not try to use two calipers with only one disk hooked up and the other caliper stuffed with the plastic shim it ships with. The plastic shim is too squishy, and the braking force is compromised. I learned this by running into a wall after the straight on my first lap in Milwaukee.

It's darn-near impossible to remove precising-fit aluminum brake hubs from aluminum axles in the hot sun. Much easier in the shade.

I adjusted the motor controller code to prevent nuisance tripping of the over-current protection. Basically I dropped the amount of current I was trying to draw, and bumped up the point at which I trip the over-current protection.

Maybe more important though is I adjusted the calculation of current from the sinusoidal waveforms. The angle used as the reference for driving the motors is now different in forward vs reverse and the current measurement offset is also in the opposite direction in forward and reverse. I'm not an expert on this, but it does seem important, as the current to voltage relationship of the wavefroms varies depending on which direction you are going and weather you are driving forward or in regen, but it seems the current you care about is only really at one angle. Anybody care to explain this to me, I'm all ears.

To make this happen I spent some time connecting the ESP8266 wifi module to replace USB serial port. That allowed wireless telemetry. I set up a WRT54G Linksys access point mounted in the car to relay the data to my phone, and then from there to a log file on the phone that can be sent to my email via the app.

After adding the FPGA pre-load capture feature, I was able to capture the current over-current trip and see what's going on to cause the misbehavior. Nothing suprising, just transients in the load causing the current to go up more quickly than the loop could correct them.

I completed the angle sensor bracket for the other side. Unfortunately I still only have one motor controller working, so I just swapped for testing and once I saw that it worked I took off the extra parts to save weight.

We brought Phantom 48 and Phantom ICT both out to Detroit. This was the inauguration of the speed changing music. It seems like it would be difficult, but it's not so bad, written as an Android App that takes the speed from GPS and adjusts the playback rate of the music. The output is simply a set of Bluetooth motorcycle speakers from Amazon.

Leading up to Milwaukee 2017 I created a ice cream cone helmet, added hydraulic brakes, and adjusted pulley ratios and current limits to provide for reliable driving.

Due entirely to Moxie, Phantom ICT achieved third place over-all for the Milwaukee Weekend! Points Spreadsheet

• Rework the steering.
• Retire from racing to focus on the electric Civic?
• Create a new motor controller or fix the old one to got both sides going.
• Aluminum version of 3D printed angle sensor.
• Maybe change the setup of ICT so you can sit on top of the motors rather than way down low. That would shorten the kart significantly.
• Hydraulic front brakes? All four brakes? Brake bias adjustment?
• GAN controller