Shifting conversion for a Toyota MR2
Sample Blog Post 1
Here is some sample text.
PiFace Thermostat Server
I wanted to remotely control the temperature at an off-site facility. I wanted to use a raspberry pi and a piface interface shield.
I found an awesome example program from David Comp:
https://github.com/adcomp/piface-python-websocket-server/blob/master/server.py
I modified the server to add variables for the ambient temperature and the set temperature of the thermostat. I reworked the front-end to include buttons that increment and decrement the thermostat:
Before:
After:
I then wired in the temperature sensor. The unit I chose was sourced from Sparkfun:
https://github.com/adcomp/piface-python-websocket-server/blob/master/server.py
I followed adafruit’s guide to get the one-wire interface working:
https://github.com/adcomp/piface-python-websocket-server/blob/master/server.py
I then added the necessary code to get the server to periodically check the temperature reading from the sensor. I was excited to try multi-threading in Python for the first time, so I added a separate thread to handle the updating of the temperature reading. Coming from a low level background, it was pretty cool to see how Python made this a much easier task.
The thermostat code that I added checks the current ambient temp and compares it to the set temp. If the ambient temp is .7 degrees F below the set temp, the heater output is energized. The heater remains energized until the ambient temp is .7 degrees above the set temp. This included hysteresis algorithm reduces unnecessary cycling of the heater.
The final bit I needed to do was write a launch script to fire off the server on boot/reboot of the pi. Otherwise when I closed out my remote session the server would stop too. Also upon power failure the system comes back on seamlessly. I have had this project working dutifully for over over a year now with no problems!
Here is the server code:
https://github.com/adcomp/piface-python-websocket-server/blob/master/server.py
Wavelet DSP Knock Project
I’ve been hacking in the automotive domain for over a decade now. I have done a few engine swaps, but my MR2 was the first time I ditched the factory engine control unit (ECU) in favor of an aftermarket standalone unit. The stock Toyota ECU makes no provisions for tuning or calibration tweaks. The aftermarket ECU I chose from Haltech would allow me completely define the spark and fuel parameters, along with a host of auxiliary features. It came with a flying lead harness, so I had create the entire engine loom; routing and connecting every wire.
When tuning an aftermarket ECU, special tools can help monitor the engines health. Historically tuners and modders relied on reading the condition of the spark plugs, and a good ear to listen for any audible anamlolies. Today there are a number of more sophisticated technologies avialable. One tuning aid that I sought was a knock detection system. With a background in electrical engineering and signal processing, I began to scour the market for suitable devices. After an exhaustive search, I was not impressed with the available options and decided to tune my car without the aid of knock detection device.
Not long after my car was finished, I enrolled in a senior level signal processing course at NIU. There were two projects for the course: one midterm project which was constrained, and one final project which was completely open ended. I chose to tackle the knock detection system as my final course project.
I set up the standalone ECU to give me two maps: one that would run the engine normally, and one that would make the engine combustion detonate.
I recorded the signal from the knock sensor for a preliminary analysis. Here is what the recorded signal sounds like:
Using Goldwave software I performed a time-frequency plot. You can see the signal of interest shifts a bit higher in frequency when detonation is occuring.
I deceided then to dig deeper and isolate the combustion events. Here is the knock signal slowed down:
The waveform of a single combustion event looks like this:
I fed an example of the knock waveform onto the Matlab wavelet toolbox:
Post in progress…
MR2 Paddle-Shift Conversion
TL;DR Just watch this video:
This project began when I completed the CAN-BUS data extraction from my ECU as a part of a separate project. With the engine operational data now onboard an Arduino microcontroller; I thought of all the cool things I could do with it. Spawning from that was the plan that I could replace my shift cables with pneumatic actuators and have an Arduino automate the shifting process. Here is a picture of some early ECU analysis:
The design started with a force analysis for the pneumatic actuators. I built a test rig to measure the force needed to change gears. After I had the force data, I calculated the bore size of the pneumatic actuators I could achieve at a range of pressures. I aimed for target shift force at a median pressure, so I could always increase or decrease system air pressure to adjust shift force for optimal real world operation. I sourced the Speedaire actuators from Grainger with part number 5MMF7. (If you are looking to replicate this project; read on to see why these may be undersized) The solenoids are from STC, part number: 4v110–1/8.
After receiving the components I welded the brackets and built the mechanical system. After a few bench test sessions I arrived at a mechanical configuration for shifting that seemed to work the best.
The next step was to integrate the electronics. I designed and wired a small amplifier sub-circuit to allow the arduino’s digital output signals to energize the higher power pneumatic solenoids. I then wired a joystick to be read by the aduino analog inputs to provide a shift signal. After this wiring was completed, I began to build out the embedded software to control the system. The software keeps track of the current gear selected and the desired shift operation. Incompatible requests are ignored. (shift to a gear higher than 5th, etc.) The software handles all of the pneumatic actuation to engage any gear and shift sequentially through them.
Early Attempts: Lessons Learned
I originally attempted to actuate the shift rods directly by modifying the transmission case. This allowed any gear change to be completed in two transitions instead of three transitions if using the factory gating method. I was concerned about the shift speed from the added lateral movement, but once I observed how fast the pneumatics were, I decided to use the factory gating system. So I went from an original prototype of this:
I built my second prototype to use the stock gating and actuate the stock H-pattern:
I had to modify the length of the actuating arm to get the system working well. The pneumatic cycliders were sized for the proper force needed for the original protype. Once I decided to actuate the stock H-pattern they were slightly undersized.
The above photos show just once axis completed. Once I had the longitudinal axis working, I built out the lateral axis actuation.
This brought me to the final stage of prototype development that I needed before road testing. Now I am waiting for the rest of the car to be finished to try the system out.
The faster shifting also mean thats the system will benefit form a clutch disc with a lower moment of inertia. The lower inertia dish will help save the syncros when attempting to shift rapidly. Below is the 4 puck unsprung unit I chose compared to the old 6 puck sprung hub disc.
Pulsejet Control System
http://www.derekseaton.com/projects.html
My senior design project at NIU was a collaboration between myself and a Joshua Ott. Joshua is a mechanical engineer who had been designing a unique pulsejet engine design. The unique features included a twin combustion chamber design and a self starting mode. To accomplish his mission, Joshua needed a digital control system designed and implemented for this pulsejet engine. The result of our efforts were a really cool engine, new skills, and Second place senior desing awards from our college in both the mechanical and electrical departments.
http://www.derekseaton.com/projects.html
https://instagram.com/p/nJgERFB044/
This system uses an Adruino Mega interfaced with some other peripherals:
- LCD Screen
- Rotary 10k potentiometer input knobs
- momentary push button
- injectors drivers
- ignition drivers
- fuel pump relay
The control system is interrupt driven and makes use of three of the arduino mega’s timers. The pulsejet contiains no moving parts: presesnting an intersting challenge for determining the phase of the combustion cycle. I decided to overcome this problem using the following method: the timing of the system is referenced to a reoccurring portion of the combustion cycle. The pressure sensors trigger the arduino interupts upon crossing their zero refernce point. This is the begining of the control sequence for each cycle.
Control Sequnce Overview:
- Determine operation frequency of the engine and resolve the fuel delay (specified in degrees) and spark delay (also in degrees) into a time delay. This has to be done each cycle because the engine may change its operational frequncy and the spark/fuel time delays need to be dynamically recalculated.
- Set the fuel timer to interrupt the proccessor when it’s time to begin injecting fuel (based on the previously calculated delay time)and set the spark timer to interrupt the proccessor when it’s time to begin charging the coil (a static amount of time before it needs to fire; also based on the previously calculated delay time)
- The fuel delay timer has elapsed and the processor begins its fuel interrupt routine. The injector signal is asserted and a software semaphore is set to track that the injector is on. The timer is set with a new value for when the injector needs to turn off. This is based upon the amount of fuel desired.
- The fuel timer elapses again and the fuel interrupt routine checks the semaphore flag. The logic specifies that the injector now needs to close, and the injector signal is de-asserted.
- The spark delay timer elapses and the the processor begins its fuel interrupt routine. The spark signal is asserted and a software semaphore is set to track that the coil is charging.
- The spark timer elapses again and the spark interrupt routine checks the semaphore flag. The logic specifies that the coil is done charging and now needs to fire, and the spark signal is de-asserted.
That is an overview of the realtime control logic. Note that those steps are occuring for two separate combusitons chambers concurrently. Some other house keeping functions are running periodically to poll the A/D convertor to get the input positions of the knobs, update the LCD screen, and send logging data out over the USB cable.
Enclosure
I was looking for some way to make a sturdy aesthetically pleasing enclosure. Plastic project boxes didn’t appeal to me and I wanted somthing metal. I decided to repurpose an airbag computer module from a Toyota MR2. I stripped out the original pcb and made room for my components.
