Sterownik silnika Diesla opartego o pompę wtryskową VP37

[jaszczurtd]

Chciałbym przedstawić mój projekt, który traktuję jako hobbystyczny, będący w rozwoju od kilku dobrych lat, w zależności od tego na co pozwala mi tzw. "normalne życie", i wszelakie ograniczenia z nim związane.  

Jestem pasjonatem motoryzacji wszelakiej. Odkąd zrobiłem prawo jazdy, i zderzyłem się z przykrą rzeczywistością polskich warsztatów, i tego jak one traktują klienta, i swoją pracę, zacząłem się interesować kwestiami serwisu, budowy silników, i wszystkiego co z tym związane.

Zaczynałem od etapu "otwieram maskę, i nie do końca wiem na co patrzę". Obecnie własnoręcznie buduję silniki, wraz z elektroniką sterującą.

Moim pierwszym autem był Ford Escort z silnikiem 1.8D. Stara, wolnossąca jednostka, która nie miała żadnej elektroniki sterującej. Czysta mechanika. Przejechałem tym autem dziesiątki tysięcy kilometrów. Mam zarówno do tego auta jak i tego konkretnego silnika sentyment, pomimo że był wolny, stosunkowo głośny, i problematyczny w zimie.

Kilkanaście lat temu wpadłem na pomysł, by "dla sportu" rozebrać ten silnik (kiedy miałem już inne auto oczywiście), i zobaczyć jak to wszystko jest zbudowane od wewnątrz. Miałem wtedy już jakieś doświadczenie z mechaniką silnikową - nie sprawiało mi problemu np. by wymienić rozrząd, itp.

Ale jak to ja, stwierdziłem że to za mało - jak już rozbiorę ten silnik, to spróbuję go złożyć na nowo... ulepszając. I tak narodził się mój projekt - zbudowałem sobie hybrydę 1.8D/TD/TDDI (dla fordziarzy dieslowców te skróty coś faktycznie oznaczają!  ), a wchodząc głębiej w szczegóły - był to silnik który zachowując zelety pancerności starego 1.8D, wprowadzał jedną, podstawową modyfikację - zmianę sposobu wtrysku paliwa z tzw. "pośredniego" na "bezpośredni". Z tym wiązało się mnóstwo innych rzeczy które trzeba było ogarnąć - np. pompa wtryskowa, wtryskiwacze, turbo, ustawienie tego wszystkiego... No ale zaraz zaraz. Co to ma wszystko wspólnego z tym portalem (bynajmniej nie motoryzacyjnym)?

Bo w międzyczasie narodził się pomysł, by do tego silnika (który finalnie wylądował w starej, ale odnowionej blacharsko Fieście), zbudować coś na kształt ECU.

Na początku plany były skromne - ot, chciałem mieć ładną wizualizację parametrów silnika. Temperatura, ciśnienie doładowania... Zamiast kilku wskaźników montowanych nie wiadomo gdzie, nie pasujących do auta (miłośnicy tunningu wiedzą o czym piszę), fajnie by było mieć to wszystko na jednym wyświetlaczu.

I tak narodziło się to:

 

Na początku był to stosunkowo prosty układ, który głównie odpowiedzialny był za monitorowanie temperatury (chłodziwa/oleju), dolotu, ciśnienia doładowania, temperatury spalin, obrotów silnika, i obciążenia, które w późniejszym etapie wykorzystałem do sterowania turbiną o zmiennej geometrii.

Projekt powoli się rozrastał. Pozwolił mi na zestrojenie auta tak, że uzyskałem ok. 170KM.

Niestety, z czasem zaczęły mi przeszkadzać ograniczenia - mały rozmiar wyświetlacza, dodatkowo zacząłem myśleć o rezygnacji z mechanicznej pompy wtryskowej, która jest ograniczona w temacie regulacji dawki paliwa, czy kąta wtrysku (przy takiej mocy niestety nieuniknione było dymienie w pewnych sytuacjach).

I o ile implementacja nowego wyświetlacza to szczegół praktycznie nie warty wspominania, tak migracja w stronę pompy sterowanej elektronicznie to już wyższy poziom.

Pierwsza wersja mojego "ECU" pracowała w oparciu o płytkę ItsyBitsy M0 (z mikrokontrolerem ATSAMD21). To fajna płytka do małych projektów.

Jednakże docelowo użyłem tutaj Raspberry pi pico - względem ItsyBitsy jest to spory upgrade - wiecej CPU (dwa rdzenie), więcej pamięci, więcej wszystkiego.

Całość pracuje niby pod kontrolą Arduino - piszę niby, bo korzystam raptem z kilku bibliotek (CAN, wyświetlacz), ale powoli tworzę swoistego HALa który umożliwi mi uruchomienie tego kodu pod dowolną platformą.

Wyświetlacz był do niedawna częścią sterownika, jednak w momencie rozpoczęcia implementacji pompy VP37, kod odpowiedzialny za wyświetlanie zmigrowałem do osobnego moduły, który czyta wartości wystawiane przez ECU za pomocą magistrali CAN. Być może opowiem o tym module za jakiś czas, bo po niewielkiej modyfikacji można by go zaadoptować w zasadzie do każdego auta z magistralą CAN które wystawia na niej odpowiednie ramki.

Co do samego tematu sterowania pompą VP37, to jest to coś, co może zainteresować tutaj więcej osób niż tylko te związane z motoryzacją.

Oto ogólny widok na pompę, tak by było wiadomo o czym w ogóle mowa (normalnie są brudne, w kolorze aluminiowym.  )

Pod tym czerwonym kapturkiem znajduje się część pompy, która nas najbardziej interesuje. Jest to tzw. elektromagnetyczny nastawnik (ilości paliwa). W praktyce jest to masywna cewka, którą steruje ECU za pomocą PWM. Ogólny koncept wydaje się prosty, ale diabeł, jak to mówią, tkwi w szczegółach.

W internecie dostępnych jest sporo filmów które pokazują jak sterować takim nastawnikiem, ja osobiście również coś tam nagrałem:

W teorii wydaje się to być proste - ot, generujemy falę prostokątną o określonych parametrach, lub dobranych doświadczalnie, i tyle. Jednak jest to znacznie bardziej skomplikowane w praktyce.

Po pierwsze, nastawnik jest elementem bardzo nieliniowym, skłonnym do generowania oscylacji, z racji posiadania sprężyn, których podstawową funkcją jest sprowadzenie nastawnika do pozycji spoczynkowej w momencie gdy np. zostanie odłączone napięcie zasilania (zgaszenie auta).

Po drugie - jest to element pracujący w dosyć skrajnym środowisku - jest wypełniony paliwem, pracujący ze zmieniającą się temperaturą w sporych zakresach, narażony na wibracje wszelkiego rodzaju. Do tego dochodzą jeszcze fluktuacje napięcia zasilającego cewkę.

No i po trzecie - nie wystarczy go sobie ot tak ustawić "na pałę" i liczyć na to że będzie dobrze. ECU musi wiedzieć w jakim położeniu znajduje się nastawnik, bo na tej podstawie regulowana jest dawka paliwa, co związane jest z przyśpieszeniem, mocą, obrotami jałowymi, itp.

Już nie brzmi aż tak prosto.

Co przychodzi na myśl w kwestii sterowania? Samą cewką nastawnika steruje się prosto - wystarczy driver na jakimś porządnym mosfecie, z driverem na bramce, którym steruje mikrokontroler. Elementem niezbędnym jest tu mocna dioda Schottky’ego, która służy tutaj do tłumienia przepięć indukowanych w uzwojeniu cewki podczas pracy układu. W przypadku tej cewki ma ona naprawdę sporo do roboty.

A od strony programowej? Wiadomo, pierwsze co przychodzi do głowy to nieśmiertelny PID. Oczywiście nie jest to taka "najprostsza" implementacja, u siebie mam np. implementacje różniczkowania z filtrem dolnoprzepustowym o stałej czasowej Tf, metody wykrywające oscylacje, ustawianie parametrów P I D w czasie rzeczywistym, itp.

Ale jak wiadomo, regulator PID działa w oparciu o sprzężenie zwrotne, dążąc do minimalizacji wartości błędu między sygnałem zadanym a rzeczywistym. Tylko skąd wziąć w tym przypadku informację o położeniu nastawnika, niezbędną do wyliczenia wartości błędu dla PID?

Z jakiegoś powodu Bosch w tych pompach nie zastosował potencjometru, który można by wykorzystać do tego celu (może kwestia trwałości), tylko zastosował zupełnie inny mechanizm. Wygląda on tak:

Jest to pierścień z dwoma cewkami. Jak to działa? Wbrew pozorom bardzo prosto: ruch ramienia nastawnika powoduje zmianę indukcyjności cewek. Taki mechanizm jest genialny pod kątem trwałości, coś co w dzisiejszych czasach nie ma zastosowania... Jak to jednak wykorzystać w pratyce, razem z mikrokontrolerem? Z laborek ze szkoły (wow, szkoła się przydała...) przypomniałem sobie że istnieje coś takiego jak generator Hartleya:

Układ ten to generator sinusoidy. W połączeniu z cewkami z pompy, generuje on sinusoidę o różnej częstotliwości, oraz amplitudzie. Czyli po wyprostowaniu i odfiltrowaniu przebiegu, mamy już coś co może użyć mikrokontroler (ADC) jako sygnał zwrotny.

Oczywiście jest to schemat przykładowy, w praktyce wartości elementów są inne, oraz sam układ jest trochę bardziej skomplikowany.

Ogólnie zmodyfikowany lekko PID radzi sobie całkiem nieźle z dryftem napięciowym, temperaturowym, i jest w stanie utrzymać stabilnie nastawnik w zadanym położeniu.

Jeszcze odnośnie samego sterownika - bo napisałem o nim parę słów, a w sumie nawet go nie pokazałem

Zanim zacznie się krytyka co do wyglądu - jest to cały czas układ rozwojowy, docelowo zaprojektuję porządne PCB i zlecę wykonanie jakiejś firmie.

Układ jest wbrew pozorom bardzo stabilny, zarówno od strony mechanicznej, jak i software. W chwili obecnej, by zwiększyć jego stabilność mechaniczną, jest zalany żywicą. Wygląda on w tak:

Zbudowałem 2 takie jednostki, jedną do developmentu w domu (części softu które nie wymagają silnika do pracy), i drugą do testów w garażu, gdzie stoi silnik testowy:

...i teraz przystopuję trochę, bo nie wiem czy ten temat jest w ogóle dla was jakkolwiek interesujący, i czy jest sens by o nim pisać dalej, być może bardziej szczegółowo.

Ostatecznie jest to również sterowanie silnikiem za pomocą Arduino, tylko takim trochę większym i mocniejszym.  Dajcie znać co sądzicie o temacie, jestem otwarty na krytykę, pomysły, pytania, cokolwiek.

[roz]

Dalej, dalej!

[farmaceuta]

Pierwszy silnik jaki rozbierałem to silnik popularnego komara "okrąglaka" w wieku 13 lat...(brat mi wysypał dwójkę (kto jeździł ten wie)) z dwa lata później już naprawiałem motorki wszystkim kolegom z wiochy...nawet mi to szło no ale Ty widzę że wszedłeś na dużo wyższy poziom gratuluję zapału, tym bardziej że wiem jak żmudną pracą jest mechanika

[Sylba]

Nie często pojawiają się opisy realizacji projektów w skali "makro". Częściej zdarzają się opisów projektów w skali laboratoryjnej.

3 godziny temu, jaszczurtd napisał:

Na początku był to stosunkowo prosty układ, który głównie odpowiedzialny był za monitorowanie temperatury (chłodziwa/oleju), dolotu, ciśnienia doładowania, temperatury spalin, obrotów silnika, i obciążenia, które w późniejszym etapie wykorzystałem do sterowania turbiną o zmiennej geometrii.

Może dla zachęty na początku mógłbyś opisać ten pierwszy prosty układ? Pokazać co i z czego zbudowałeś i jak oprogramowałeś? Jakie problemy napotkałeś i jak je rozwiązałeś?

 

[jaszczurtd]

1 godzinę temu, farmaceuta napisał:

  gratuluję zapału, tym bardziej że wiem jak żmudną pracą jest mechanika

Noo, zapału tu potrzeba dużo, zwłaszcza że projekt ciągnie się już parę dobrych lat. Ale ja to traktuję jako miłą (no... w większości) odskocznię od swojej normalnej pracy (też embedded), no i trudów dnia codziennego. Ten projekt też sam z siebie mi czasem daje popalić, jak np. fragment związany z PIDem kontrolującym nastawnik...

50 minut temu, Sylba napisał:

Może dla zachęty na początku mógłbyś opisać ten pierwszy prosty układ? Pokazać co i z czego zbudowałeś i jak oprogramowałeś? Jakie problemy napotkałeś i jak je rozwiązałeś?

Właściwie to nie pamiętam żadnych poważnych problemów z tym związanych (co nie znaczy że ich w ogóle nie było!). Były bardziej ograniczenia niż problemy. ItsyBitsy z którym startowałem było stosunkowo wolne (ale do tamtego projektu jednak wystarczająco szybkie), i głównym ograniczeniem jakie napotkałem to ilość pinów PIO do sterowania różnymi rzeczami, oraz ilość pinów ADC. Oczywiście to było proste do rozwiązania - pierwsze rozwiązałem ekspanderem, drugie - multipleksowaniem jednego PINu ADC. Oczywiście wiadomo że można było po prostu dołożyć jakiegoś ADS1115 czy coś podobnego, ale to nie miało wtedy większego znaczenia, multipleksowanie spokojnie ogarniało sytuację.

Migracja na Raspberry pi pico nie była więc spowodowana jakimiś tragicznymi problemami związanymi z tym etapem, ot - po prostu pojawiła się fajna płytka z dwoma rdzeniami na horyzoncie, którą się trochę pobawiłem, i na tyle mi się spodobała, że po prostu została do dziś.

Ten projekt w zasadzie działałby równie dobrze na jakimś ESP32 czy dowolnym innym mikrokontrolerze.

Bezpośrednim "sukcesorem" tego projektu jest ten prosty, wcześniej wspomniany przeze mnie moduł, który zajmuje się jedynie odczytem parametrów silnika przez magistralę CAN, i wyświetla je na ekranie:

 

 

Jak słychać na filmie, moduł ma buzzer, który ma funkcję informowania o ewentualnych problemach, typu brak komunikacji, albo przegrzewanie się silnika. 

Sama płytka zbudowana jest w oparciu o płytkę RP2040 - zero, która przez swoje małe rozmiary idealnie nadaje się do takich zastosowań.

A co do projektu w skali "makro"... Mam nadzieję że to nie jest żaden wielki problem, generalnie uważam że każdy projekt zasługuje na uwagę, niezależnie od jego "wielkości" - dzielenie się nawet prostymi układami może być fajne. Mam nadzieję że i dla takiego projektu jak mój jest tutaj miejsce, i nikt nie czuje się nieswojo kiedy na niego patrzy.

[Sylba]

Możesz podać trochę szczegółów:

- jakie przetworniki są podłączone do magistrali CAN

- jaki wyświetlacz zastosowałeś

- program do przetwarzania i wizualizacji danych

[jaszczurtd]

25 minut temu, Sylba napisał:

Możesz podać trochę szczegółów:

Magistralę CAN oraz interfejs OBD obsługują moduły oparte o MCP2515 / TJA1050. Siedzi to na magistrali SPI, obsługiwane jest przez bibliotekę MCP_CAN,

Wyświetlacz to TFT 240x320 oparty o ILI9341, również na SPI. Do jego obsługi korzystam z bibliotek Adafruit (+ Adafruit_GFX). Nie korzystam z touchscreena.

Program do przetwarzania i wizualizacji danych? Hmm, prócz wspomnianych wyżej bibliotek Adafruit, wszystkie grafiki i wizualizacja to moja skromna twórczość - każdy z wskaźników to osobny obiekt klasy C++, który odpowiedzialny jest za wyświetlenie grafiki, oraz ewentualnego napisu/wartości. Grafiki wyświetlane są raz, wartości są cyklicznie odświeżane za pomocą timerów (programowych). Odświeżanie jest różne, w zależności od tego czy wartości są "real-time", czy mogą być odświeżane np. co sekundę, lub co zmianę wartości. 

Do przygotowania grafik używałem Gimpa + konwertery do odpowiedniego formatu, używałem fajnego toola z tego linka:

https://www.instructables.com/Converting-Images-to-Flash-Memory-Iconsimages-for-/

Same dane z czujników są również odczytywane z różnymi interwałami, w zależności od tego czy są wartościami wymagającymi natychmiastowego przetworzenia (np. czujnik doładowania, czujnik pedału przyśpieszenia), czy nie (np. czujniki temperatur).

Czujniki temperatur to czujniki rezystancyjne, stosowane w tunningu, do odczytu używam własnych algorytmów opartych o równanie Steinharta, reszta polega na mapowaniu wartości z czujników odczytywanych przez ADC, na szczęście większość z nich jest liniowa.

To chyba wyczerpuje temat odpowiedzi na Twoje pytania

[jaszczurtd]

Jeszcze z bajerów, wspomnianych wyżej, to sterownik obsługuje podstawową komunikację po OBD (JOBD / OBD-II), oraz tzw. "live data", czyli po podłączeniu interfejsu diagnostycznego, można monitorować dane "w locie". Na chwilę obecną funkcjonalność jest raczej uproszczona, ale w przyszłości będę to rozbudowywał.

 

[Treker (Damian Szymański)]

Informacyjnie: projekt trafił na naszego Facebooka i zbiera tam bardzo dobre opinie