Power Racing Series Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Phantom ICT is Phantom Power Racing's second car.
It was slotted to race in Milwaukee 2016, but has yet to race, due to a rapid unscheduled disassembly of the electrical system just before race weekend.
As of Thanksgiving 2016 the car was almost back to the point where it could drive.


====== Phantom ICT ======

{{:builds:ict:ICT_2016-09-03.jpg?direct&450|}}\\

//"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\\

{{https://www.dropbox.com/sc/4jknt3g04i7nlol/AACWWv4BJWbzHBPw5bJhPZCNa|ECU Wiring Diagram}}

{{http://a360.co/2fC4Ylq|Fusion 360 3D model}} This may take a while to load.

{{https://www.dropbox.com/sc/h2vga610ib66uo5/AAC_PNrmXuaHFUwsu10ZpQkha|Raw Images}} 

===== History =====

==== Initial Build ==== 
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.)

==== Rapid Unscheduled Electrical Disassembly (Days before Milwaukee 2016)====
Not enough sleep. Destroyed practically everything electrical except the fuses... go figure.

==== Slow and Steady rebuild ====
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 {{:builds:ict:fpga_board_250.pdf|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:

{{:builds:aux_circuits.jpg?200|aux circuits}}

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.

{{:builds:wrong_polarity.jpg?200|the wrong polarity}}

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...

{{:builds:screenshot_2016-12-05_08.13.52.png?200|positive feedback}}

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!

{{:builds:inaugural_drive.jpg?200|Inaugural Drive}}

Returning from the inaugural drive. No body, because it's been at [[http://www.theonion.com/search?q=area+man|Area Man's]] farm since the Milwaukee race.

==== Nuisance Tripping ====
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.

[[http://www.allegromicro.com/ja-JP/Design-Center/Technical-Documents/Hall-Effect-Sensor-IC-Publications/Current-Sensor-ICs-In-Current-Divider-Configurations.aspx|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:

{{:builds:too_early.png?500|}}

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:

{{:builds:missed_capture.png?500|}}


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

==== Next Steps ====

  * New bolt-together aluminum motor controller design... why not, right?
  * Duplicate angle sensor bracket and mount for other side
  * Aluminum version of 3D printed angle sensor.
  * Adjust motor controller code to prevent nuisance tripping of the over-current protection.
    * To this end, connect [[https://en.wikipedia.org/wiki/ESP8266|ESP8266]] wifi module to replace USB serial port.
    * Capture the current over-current trip and see what's going on to cause the misbehavior.
    * Rebuild FPGA with new settings and test some more.
Power Racing Series Wiki

User Tools

Site Tools

Page Tools
