CSC Pi-Innovo OpenECU

From Mindworks
Jump to navigation Jump to search
Left to Right: Hayden, Colin, Zac, Alex
Sponsors UICSC & Pi-Innovo
Team Name Have Your Pi & Eat It Too (HYPEIT)
Duration Summer, 2020
Faculty Adviser
  • Steven Beyerlein
  • Vibhav Durgesh
Client
  • Daniel Cordon / UICSC
Team Members
  • Alex Kiss
  • Colin Parke
  • Zac Avelar
  • Hayden Hulse

The purpose of this project is to develop and implement connectivity between sensor inputs and a control system using a Pi Innovo OpenECU for future use controlling a two-stroke snowmobile engine. The goal for the summer team is to evaluate functionality of the engine control unit (ECU) using a simulated engine.

Problem Definition[edit | edit source]

The University of Idaho Clean Snowmobile Challenge team (UICSC) is in need of a more advanced engine control platform to support advancements in combustion strategies and auxiliary components directly in the ECU (such as an experimental exhaust baffle for variable back-pressure, or catalytic converter light-off control).

Background[edit | edit source]

The current ECU used for the UICSC team’s two stroke snowmobile engine is functional, but limiting in light of the CSC’s experimental nature. Implementing more sophisticated engine controls could improve efficiency, emissions, and performance. One example of this is using closed-loop-feedback fueling to reach desired engine operating conditions more reliably than with open-loop fueling. With the power of the Pi Innovo ECU, future powertrain projects developed by the team will be more easily coupled with engine control. Examples include projects previously attempted such as turbocharging and controlling backpressure with a butterfly valve. To complete this project, the senior design team must manage the ECU’s input signals and use a Simulink based controller to compute the appropriate outputs.

The image below shows the basic flow of an engine. Physical real time information about the engines operating conditions and environment are collected using sensors. These range anywhere from sensors used to detect knock to temperature sensors (internal and external). This information is then sent to the ECU which uses the numbers given from the sensors and matches them to a table of known values called lookup tables, MAPs, or calibration tables. This information is interpolated on the tables determines the best way to operate in the given circumstance and sends it off to actuators which change these variables of the engines then the loop restarts. Our project can be visually represented by the yellow arrows. We are trying to bridge the gap between the physical and virtual world by programming each device to talk to one another in order to get what they need to get done, done.
Control Loop.png

Deliverables[edit | edit source]

Summer 2020
  1. Complete base control systems
  • Ability to control spark timing, fuel injection timing and quantity, ratio of fuel injected by injectors in series, stratified vs homogeneous injection based on engine speed and throttle position (n-alpha)
  • Ability to manipulate compensation maps for measurements such as piston head temperature, ambient pressure, ethanol percentage, etc.
  • Ability to drive E-TEC injectors
  1. Complete base wiring
  • An organized, plug-and-play wiring harness that reaches functional parity with the wiring system for a Rotax 850cc two-stroke engine
  • An intuitive wiring diagram

Future Work[edit | edit source]

  1. Testing the ECU on a running engine at idle
  2. Develop new engine control strategies, including more elaborate injection control
  3. Integrate auxiliary component controls into ECU
  4. Integrate chassis functions and implement on chassis
  5. Research and initial implementation of advanced controls
  • Catalyst temperature management/compensations research
  • Speed-density fueling with model-based feedback
i. Spark plug ionization research for in-cylinder air-to-fuel ratio (AFR) measurement
ii. Ability to switch between n-alpha and speed-density fueling on the fly
a. Framework for defining control regimes based on sensor validity; n-alpha is fallback
b. Kahlman filter research

Specifications[edit | edit source]

Engine

The team will control a 2017 Rotax 850cc two stroke engine with the following specifications:

  • Two cylinders
  • Gasoline Direct Injection (GDI)
  • In-cylinder injection capable of producing homogeneous and stratified air-fuel mixtures
  • Throttle-body injection
  • Rotax Adjustable Variable Exhaust valves (RAVE valves)
  • Adjusts exhaust port timing
  • N-alpha fueling
  • Engine operating parameters such as spark timing and fuel quantity are predominantly determined in open-loop using lookup tables with axes of engine speed and throttle position.

OpenECU

Key specifications of the Pi Innovo M670 OpenECU that are advantageous to the team’s application include the following:

  • Support for two stroke operation
  • Injector support
  • Gasoline Direct Injection control strategies
  • H-bridge outputs
  • Programmable injector output signals
  • Space for extra signals and actuators with 54 input pins and 49 outputs

For complete specifications of the Pi Innovo M670 OpenECU, please refer to https://www.pi-innovo.com/product/m670/

File:M670TechSpecs.pdf
File:M670BlockDiagram.pdf
File:PI-IOSchematics.pdf

Design Considerations[edit | edit source]

The engine controls should be flexible enough to allow for future experimentation and add-ons. For example, building the fueling logic such that a speed-density model could be switched to at steady state operation.

The primary users of the in-progress ECU will be undergraduate students on the CSC team. Code should be structured and documented such that a beginner could understand and modify existing code easily.

Validation[edit | edit source]

Process

Each signal’s functionality is validated through the process below:

  1. Input and output signals are connected and communicating to each other
  2. Input signal reads as expected
  3. Output signal reads as expected
  4. Signal processing properly converts input signal to usable output signal
  5. Input and output signals properly resolve to crank timing when applicable
  6. Run signal(s) in virtual engine/JimStim to ensure functionality under realistic conditions

Signals

Signals are validated in the following order of importance:

  1. Throttle Position Sensor
  2. Injector Actuation
  3. Coil Pack Actuation (spark)
  4. Crank Position Sensor
  5. RAVE Actuation
  6. RAVE Position
  7. Manifold Absolute Pressure and Temperature Sensor (MAPTS)
  8. Lambda (O2)
  9. Knock
  10. Exhaust Gas Temperatures
  11. Coolant Temperature
  12. Oil Pump
  13. Oil Temperature
  14. Magneto Power Input


Below are two images of the JimStim MegaSquirt device used for simulation. The image on the left is the actual device and the image on the right is a basic layout of the board. The JimStim is a micro controller often used in engine simulation because it is already wired with potentiometers and LEDs, as well as other functional buttons and knobs which correlate to the functions of an engine, such as RPM.

Image010102202.png
2020 HYPEIT JimStimLayout.png

Virtual Simulation[edit | edit source]

Virtual Simulation allows us to view what the program will do without the use of any hardware. We can manually input information into the system in order to test that it is functioning properly. This gives us a good starting point in determining whether or not it will work with the actual system hardware. The image below is just a few of our simulation monitors in Simulink which allows us to see and record the output information.
2020 HYPEIT SimMonitor.png

The two images below are snippets of a few sensor inputs in the program. The left image is of the crank signal and the photo on the right is of the throttle position.

2020 HYPEIT CrankSignal.png
2020 HYPEIT ThrottlePosition.png

Project Learning[edit | edit source]

Expected Outcomes

  • An in-depth understanding on how the ECU’s inputs and outputs function in relation to the operation of an engine.
  • The ability to effectively and efficiently generate and modify code through different builds.
  • The ability to rapidly test different code builds to determine the effectiveness and reliability of each build.
  • The ability to diagnose sources of error in the code and rectify them

Final Design[edit | edit source]

2020 HYPEIT DesignMain.png



This is the final design layout and structure of our program in Simulink. For organization purposes, we used a waterfall method which means that in each box or section is another layer which goes into more specifics the deeper it goes.

Team Members[edit | edit source]

HYPEIT Hayden.jpg

Name: Hayden Hulse
Major: Mechanical Engineering
Hometown: Buhl, ID
Responsibility: Documentation Specialist
Email: huls0072@vandals.uidaho.edu

HYPEIT Alex.jpg

Name: Alex Kiss
Major: MechanicalEngineering
Hometown: Banks, OR
Responsibility: Simulation Expert
Email: kiss8000@vandals.uidaho.edu

HYPEIT Zac.jpg

Name: Zac Avelar
Major: Mechanical Engineering
Hometown: Buhl, ID
Responsibility: Researcher
Email: avel0059@vandals.uidaho.edu

HYPEIT Colin.jpg

Name: Colin Parke
Major: Mechanical Engineering
Hometown: Boise, ID
Responsibility: Lead Programmer
Email: park7435@vandals.uidaho.edu

Additional Documentation[edit | edit source]

Abbreviations
AFR – Air-to-Fuel Ratio
CSC – Clean Snowmobile Challenge
ECU – Engine Control Unit
GDI – Gasoline Direct Injection
RAVE – Rotax Adjustable Variable Exhaust
UICSC – University of Idaho Clean Snowmobile Challenge

Project Schedule

File:2020 HYPEIT Schedule.pdf

Meeting Minutes

File:2020 HYPEIT MeetingMinutes(all).pdf

Presentations

File:2020 HYPEIT DesignReview.pdf
File:2020 HYPEIT TechnicalPresentation.pdf

Client Interview

File:Pi-Innovo Client Interview.pdf

Budget

File:2020 HYPEIT Budget.pdf