Wednesday, February 11, 2015

Turning Used Car Parts into Silly Vehicles 2: Prius Brick

Previously we (really just Nick) had managed to mount up the rotor and stator from a Ford hybrid and turn it into a working motor. The next step was to find a suitable controller for the motor, and what better place to look than the guts of a Toyota Prius?

There has been some previous work done on the Prius inverter; this fellow here has a fairly extensive teardown of the assembly, complete with glamour shots of the gooey innards of the brick. I'll supplement his information with the following:
  • The brick has significant internal propagation delays. At 20KHz, anything under 20% duty cycle is clamped to zero, and anything over 80% duty cycle is clamped to 100%.
  • The internal power supplies expect a fairly low-impedance source; if your brick doesn't want to turn on check your power connections.
  • The logic going into the brick is inverting; enable needs to be pulled low to turn on the phases, and the phases are HIGH when the inputs are low.
  • The current sensors are 400A and 200A, respectively.
The first step was to build a board to interface with the module. A bit of Eagle layout work gave the following board and schematic:


The board is Arduino-shaped, but is actually meant to mount atop one of these:


An STM32F4 Nucleo, part of ST's latest attempt to push their high-performance ARM microcontrollers and actually a pretty good one at that. The hardware pins are Arduino-compatible, and the board can be programmed via the Mbed online IDE. Sure, their libraries are as slow as balls, but even with the overhead of the Mbed libraries the Nucleo still has about 10x the performance of an Arduino, not to mention all-important hardware floating-point support.

The board should be self-evident - X5 is a throttle input, X2 is hall sensors, X1 is 12V power, X3 and X4 control the two halves of the Prius brick (remember, there are two controllers in the brick!) in parallel, and X6 is a quick-and-dirty resistor-divider based input for the current sensors.

We have a board - firmware was next. You can download the firmware package here. A quick code walkthrough follows.

Motor commutation is interrupt-based, with throttle polling and (in the future) the current loop runnin in the main loop. Math is done in floating point thanks to the STM32F4's hardware FPU.



The commutate routine is called once every sensor change. It converts the hall sensor reading to a position estimate (in intervals of 60 degrees) and stores it. It also zeroes the ticker that is used for position interpolation, and updates the motor speed estimate (motor->last_time). In addition, the code also tries to detect and prevent jitter at the hall sensor transitions by maintaining forwards rotation of the motor when possible, which is crucial in preventing commutation misses.



The dtc_update routine is called at regular intervals (in the default firmware, 5KHz). It does two things: measure the time elapsed since the last commutation (motor->ticks += 1.0f) and update the duty cycle via a table lookup.

In its current state the firmware isn't really production-ready; the lack of current control makes it too unwieldy for use on large vehicle, but it should at least get us off the ground for further testing.

Tuesday, December 2, 2014

Ford Fusion Motor

Part of an ongoing series of shenanigans to turn used car parts into EV's. See Nick Kirkby's blog post about it here.

Monday, October 27, 2014

RY40511: a few notes

Stuff to note for other tinkerers out there:

  • The entire controller gets extremely hot at 50A with the stock transistors, probably too hot for continuous duty without a fan. However, the limit is probably purely thermal - I did most of my initial testing with a 50A max current setpoint with the motor coupled to a second chainsaw motor driving a dead short, and both the current loop and short-term behavior of the controller seemed reasonable.
  • Likewise, the motor is not good for 50A under stall or near-stall conditions; everything gets rather hot. However, at reasonable RPM it is probably actually a 2KW motor thanks to the integrated fan.
  • Without some further connection on the blue "COMM" wire coming out of the battery, the integrated BMS shuts off at 25A. Charles has gotten 65A out of the battery, so presumably reconnecting this wire will enable high current operation; given the lack of thermal protection on both controller and motor some adaptive current limiting will probably be necessary to keep temperatures down.
  • If you want to upgrade the MOSFETs, go for the lowest Rds,on FETs you can afford - gate charge doesn't really matter given the 10nF parallel capacitor on the gate. Furthermore, only 1/6 of the FETs are switching at any one time, and only at 8KHz, so switching losses are negligible. In fact, switching too fast will result in nasty transients and FET failures (don't use logic level FETs!).
  • The 40V voltage limit is pretty hard with the board in its stock state; the high-side gate drive BJTs see 55V and are rated to 65V. Likewise, the LVPS assembly is not going to appreciate any sort of significant overdrive. Replacing the BJTs with 100V parts might allow it to operate at a 48V nominal pack voltage.

Frozen Chainsaw Massacre Part 2: New firmware

So previously I had briefly mentioned a scooter built out of a brushless chainsaw; remarkably enough, it worked well enough so that we (Peter and I) decided to write new firmware for the chainsaw to make it behave more like a vehicle and less like a power tool.

The first step was to trace out the schematic for the board. After a couple hours of rooting around the board we came up with this:


The PNP transistors are BC856B'; the NPN transistors are BC846's. The MOSFETS are Alpha Omega AOT470's - pretty generic 100V 10mOhm FETs with 130nC of gate charge; not high performance by any means but they work.

Next we needed to set up the PWMs and interrupts to get the motor turning. The following snippet of code initializes the timers to do block commutation with high-side PWM:



This configures the high side PWM's to be enabled, and leaves the low side pins free for GPIO use.

The actual commutation is done by the following function, which is called every time the hall sensors change:



htable[] and ltable[] are lookup tables for the states of the high and low side FETs in each phase.

This was enough to get the motor turning; the next step was to read the current shunt and add some overcurrent detection. Unfortunately, the current surge during motor startup in open-loop mode was enough to trip even a 300A current limit.

We added a current loop, which ran in a main() to avoid conflicting with commutation:



After dealing with a bunch of minor-but-deadly bugs with the current loop (and in the process killing a couple dozen transistors), the motor seemed to more or less turn smoothly.

Next we added stall protection - the firmware would compute the speed of the motor and limit the duty cycle to 10% if the speed was too low. This inevitably resulted in a few more dead transistors due to integral windup, but worked pretty effectively after the bugs were fixed, giving just enough startup torque to move the scooter without pushing dangerous amounts of phase current.

At this point we were a couple weekends and ~50 dead MOSFETs (and about a hundred little BJT's) into the project and it was getting to be pretty late. We figured that before we plugged it into the battery we should investigate the startup transient of the micrcontroller. This resulted in the removal of a bug that caused a brief shoot-through event on startup (the timer duty cycles and complementary modes were not being initialized before the PWM channels were enabled) and the loss of another bridge.

We couldn't figure out what was up with the damaged bridge - no amount of replacing shorted MOSFETs could restore it to functionality. Eventually we replaced all of the transistors, and it worked again. Lesson learned: zombie-FETs are a thing.

Get the code here. To flash it, solder a 4-pin header to the "P0" pads on the board and connect a STM8 programmer, notch side in, to the header. You'll also need to configure the option bytes to set the correct alternate functions for the timer pins, which is pretty trivial in ST Visual Programmer. Code tested to work in IAR studio, definitely will not compile in other environments without some tweaking.
The default settings (constants.h) set the max current limit to ~25A (controller gets real hot above that) and UVLO to 20V (gate drives brown out below that).

Monday, October 6, 2014

Frozen Chainsaw Massacre: Ryobi RY40511 Cordless 40V Chainsaw on a scooter

Following up on Charles' blog post here I decided to snag one of these chainsaws for myself and see how it faired in vehicle duty.

The end result:
Chainsaw on a Disney Princess scooter - hence the name
The scooter turned out remarkably rideable, except for the extremely annoying motor controller cut-in behavior, which gave the motor the start-up behavior of a gas engine- if throttle was applied from a standstill too quickly, the motor would cut out, requiring a controller reset. The motor had to be ramped up to speed over the course of several seconds to work properly.

The only way to fix this was to reflash the controller with new firmware. Conveniently enough, there was an unpopulated programming/debug header on the board. We rooted around the board for a while and came up with this schematic:


Next up: port my sinewave controller firmware to the STM8S micro that the board uses.

Sunday, October 5, 2014

Greenlight HPS Part 3: Planning an Attack

(Warning, wall of text!)

So we had this laser which probably not only had more interlocks than a nuclear reactor, but also actively prevented us from defeating those interlocks. What we wanted in the end was to be able to dial in a diode current, and have the diode driver run the diodes at that current. We also needed the crystal temperatures, water temperatures, and Q-switch settings to automatically adjust themselves according to the user current setting.

From the service information AMS had leaked on their website (the AMS Technical Services site is riddled with holes), we knew the following:

  • The service fix [Check CAN bus cables between LCB and LPS] to problem 130 in the HPS Problem Codes indicated that the subassemblies communicated via CAN (an automotive bus).
  • The description of problem 209, [A voltage supply is out of spec. on the Laser Power Supply/Vuemetrix board] indicated that the diode driver was manufactured by Vuemetrix. The output power suggested that it was a variant of the VueHV stack driver.
  • The following screenshot from an instructional document shows the current vs. power for a typical laser:
XPS but you get the idea
Knowing this, we had several approaches to turning on the laser.

  1. Disassemble the laser into constituent subcomponents, turn on those subcomponents, and reassemble into a laser. This meant figuring out how to turn on the chiller, diode driver, and Q-switch driver. We knew the Vuemetrix driver could probably be persuaded to connect to the VueHV software, and the Q-switch driver was a stock NEOS part.
  2. Spoof a surgical smartcard. We were able to get a smartcard off of eBay. The card had "Atmel" written on it, which meant it used an Atmel Cryptomemory secure IC. The cryptomemory had several known exploits, including a brute-force approach which would have taken ~70 days on my fastest machine, and a power analysis approach which was more involved, but would have only taken a few minutes.
  3. Exploit the unencrypted nature of the CAN bus to figure out what messages did what, and build a new controller that played the appropriate messages over the bus.
(1) had the advantage of being guaranteed to work; however, it meant we would lose the self-protection that the stock Laserscope controller provided, and we figured that having things like underflow and overtemp were good. (2) was also known to work, and was pretty much a standard power analysis attack; unfortunately, neither of us had much experience in such techniques. (2) would have also given us a completely turn-key way to turn on the laser, one that did not involve any extra hardware.

We decided to go with #3 because we had access to a borrowed CAN transceiver, and we figured it was a good middle ground between keeping enough of the internal firmware to protect the laser, while allowing us to hopefully build a custom user interface that did not look like a medical interface (as cute as the touchscreen was, being able to monitor critical laser parameters and set power in something other than 10W increments would have been real useful!)

Greenlight HPS Part 2: First Light

So we had this beautiful laser, and no clue how to turn it on...

The first step was to plug it in and see what happened. We knew it had a chiller error, and indeed, after a few minutes warming up, it threw an "error 611", which was a flow error.

After some fiddling with the internal valves we were able to clear the flow error - it turned out that one of the flow restrictors was set improperly, which resulted in the diodes receiving too little flow. At this point, the laser booted, and, as expected, we could do nothing without a fiber and a smart card.

However, at some point during the weekend, one of us decided to pull the lid off of the resonator before booting the laser, at which point we saw this:

Green?!
It turned out that part of the boot process was to check actual power against the internal open-loop P/I (power/current) table, and that involved turning on the laser.

Unfortunately, somewhere during the process the laser threw an error 210, "Diode Stack Overvoltage". This sounded ominous, and indeed, after we disassembled the head it turned out one of the diodes had shat itself and failed open circuit. Undaunted, we replaced the open diode with a blob of solder paste and reassembled the stack, and the laser kept going. Little did we know...

With the diode stack fixed, it was simple to put a turning mirror in the resonator and get a beam out of the head:

Really ass photo
This self-test mode would prove critical to getting the laser to turn on under our control, as you will soon see.