Smart motorsykkel HUD-prototype (sving-for-sving-navigasjon og så mye mer): 9 trinn

2024 Forfatter: John Day | [email protected]. Sist endret: 2024-01-30 11:20

Hei!

Denne instruksen er historien om hvordan jeg designet og bygde en HUD-plattform (Heads-Up Display) designet for montering på motorsykkelhjelmer. Den ble skrevet i sammenheng med "kart" -konkurransen. Dessverre var jeg ikke i stand til å fullføre dette prosjektet i tide til konkurransens frist, men jeg ønsket fortsatt å dele fremgangen min med det, samt dokumentere alt prøving og feiling jeg fikk gjennom det.

Ideen til dette prosjektet kom først til meg for noen år siden, da jeg satte meg inn i motorsykler, og jeg begynte å se på hvilket utstyr jeg måtte kjøpe for å gjøre turene mine morsommere. På det tidspunktet forvirret det meg at den beste måten å få grunnleggende GPS -navigasjon mens du sykler, var å i utgangspunktet feste smarttelefonen til sykkelens styre. Jeg tenker for meg selv at det sikkert kan være en bedre måte å få den slags informasjon på farten.

Det var da det kom til meg: En head-up-skjerm kan være måten å få navigasjon mens du sykler, uten å tømme telefonens batteri og eksponere den for elementene.

Over tid modnet denne ideen i tankene mine, og jeg skjønte at det å ha en HUD foran meg hele tiden ville tillate mange flere bruksområder enn enkel navigering. Det er derfor min plan er å gjøre plattformen offentlig og modulær, slik at alle kan lage en modul som viser informasjonen de trenger på sin egen HUD

Selv om det er kommersielt tilgjengelige produkter som oppfyller denne oppgaven, er det ikke noen som er like modulære som min plattform, og de pleier også å være litt dyre. Uansett, velkommen til dette prosjektet.

Det som fungerer nå

Som sagt er dette prosjektet fremdeles veldig i utviklingstilstand, og det er det som jobber for tiden.

- Kommunikasjon mellom en smarttelefon og et ESP32 -basert kort (telefon våken)

- Optikkdesign gjort (kan trenge små justeringer på sikt)

- Android -navigasjonsapp som bruker Mapbox -navigasjons -SDK:

- Kan beregne og vise brukerens posisjon på et kart, samt en rute fra den til destinasjonen

- Kan koble til en Bluetooth -enhet (enhetens MAC -adresse er hardkodet fra nå)

- Kan navigere i sanntid, inkludert å trekke ut og sende informasjon om den kommende manøveren via seriell Bluetooth (støtter bare svinger for øyeblikket)

Hva trenger arbeid

Denne listen inneholder elementer som er absolutt nødvendige for HUDs tiltenkte bruk, men som ikke er klare til å bli implementert ennå.

- Overordnet design (hjelmfeste, reflektorens vinkeljusteringsmekanisme,..)

- Android -app:

- Implementere oppdagelse og korrigering utenfor ruten

- Mulighet for brukeren å skrive inn destinasjonsadressen

- Veipunkter?

- Ergonomi / estetikk

Rekvisita:

Essentials

- Et esp32 -basert utviklingstavle

- Enhver nylig Android -smarttelefon (Bluetooth -aktivert)

- En SSD1306 eller en annen aktivert 96 "OLED -skjerm (min var 128x64 piksler, se delen" Hjernen: mikrokontroller og skjerm ")

- En reflektor (ethvert stykke akryl/glass/plexiglass vil gjøre)

- Et Fresnel -objektiv (mitt hadde en F.lengde på ca 13 cm, se delen "Lens valg")

Verktøy

- Loddejern

- Brødbrett

- Noen hoppekabler

- 3d -skriver / 3d -utskriftstjeneste

Trinn 1: Hvordan det hele fungerer: Designvalg forklart

Den grunnleggende ideen med en Heads Up Display er å vise et bilde foran noens visjon, slik at de ikke trenger å se bort fra det de gjør (det være seg å styre et fly eller kjøre en motorsykkel, som blir vår eksempel tilfelle).

Optikk

Teknisk sett kan dette oppnås ved å sette opp en skjerm rett foran brukerens øyne. Imidlertid er en skjerm ikke gjennomsiktig, og vil derfor hindre brukerens syn. Du kan deretter plassere skjermen foran en reflekterende overflate, som speiler skjermens innhold samtidig som den er gjennomsiktig nok til at brukeren kan se hva som er foran ham.

Imidlertid har denne tilnærmingen en stor feil: den faktiske skjermen er vanligvis nærmere brukerens øyne enn det brukeren faktisk må fokusere på (f.eks. Veien foran ham). Dette betyr at for å lese hva som er på den reflekterende overflaten, må brukerens øyne tilpasse seg skjermens avstand til øynene (la oss si 20 cm), og deretter måtte tilpasse seg igjen for å fokusere på veien videre (~ 2/5 meter). Tiden hele denne operasjonen tar er dyrebar tid som bør brukes på å se på veien, og tilpasning ofte kan være ubehagelig for brukeren etter bare noen minutter.

Derfor bestemte jeg meg for å legge til et objektiv mellom skjermen og reflektoren. Dette objektivet, hvis det er valgt med omhu, bør tillate å lage et virtuelt bilde av skjermen (se skjemaet ovenfor), som da ser ut til å være lenger borte fra brukerens øyne som det faktisk er, og krever dermed mindre brå tilpasninger (eller ingen i det hele tatt, i et perfekt scenario). Denne designen gjør at brukeren raskt kan se på reflektoren, få informasjonen han trenger og umiddelbart se tilbake på veien.

Smarttelefonens rolle

Fordi det var urealistisk å prøve å implementere en hel navigasjonsapplikasjon på ESP32 alene, bestemte jeg meg for å lage en Android -app som skulle ta seg av dette. Appen trenger da bare å fortelle ESP32 hva brukeren må gjøre for å komme til målet, og ESP32 videresender denne informasjonen til HUD (se figuren "Hvordan modulen fungerer").

Trinn 2: Deler - Brains: Microcontroller & Screen

Som nevnt ovenfor, planla jeg å få modulen min til å vise navigasjonsinformasjon, mens jeg faktisk ikke lot den beregne den faktiske posisjoneringen, sporing og sanntidsnavigasjon. brukerens telefon ville i stedet kommunisere med modulen, og sende den informasjonen for deretter å bli vist på HUD.

For å lette kommunikasjonen mellom brukerens telefon og modulen, valgte jeg å bruke et ESP32 -basert kort for dette prosjektet. Dette valget skyldtes at denne spesifikke modulen hadde integrerte Bluetooth-muligheter, i tillegg til noen andre interessante spesifikasjoner (enkel å bruke ikke-flyktig lagring, dual-core CPU, nok RAM til å faktisk kjøre OLED-skjermen via I2C, …). Det er relativt enkelt å designe PCB basert på ESP32, som jeg tok i betraktning. Jeg har også profesjonell erfaring med å bruke og designe kretser med ESP32, noe som definitivt påvirket valget mitt.

Valget av skjermen kom i utgangspunktet til det jeg kunne finne på at jeg skjønt ville være lys nok til å bruke, samtidig som den var så liten som mulig. Jeg var ikke veldig bekymret for antall piksler på skjermen, ettersom målet mitt var å ha et veldig minimalistisk og enkelt brukergrensesnitt.

Det bør bemerkes at skjermdriveren bør støttes av et bibliotek som gir mulighet for bildespeiling. Det er fordi det viste bildet blir snudd når det kommer gjennom linsen og vises på reflektoren, og det å ikke måtte manuelt reversere det som vises, er en stor vekt på skuldrene våre som byggherrer.

Trinn 3: Deler - Optikk: Å finne et kompromiss

Optikken for dette prosjektet var ganske vanskelig å nærme seg, ettersom jeg ikke ante hva jeg så etter da jeg først startet dette prosjektet. Etter litt undersøkelse forsto jeg at det jeg ønsket å gjøre var å lage et "virtuelt bilde" av OLED -skjermen min, som ser ut til å være lenger borte fra øyet enn det faktisk er. Den ideelle avstanden for dette virtuelle bildet som skal dannes, vil være på rundt 2-5 meter foran sjåføren, a dette ser ut til å være avstanden til objektene vi fokuserer på når vi kjører (andre biler, støt på veien osv …).

For å nå det målet valgte jeg å bruke et Fresnel -objektiv, ettersom disse er ganske store, billige, de syntes å tilby en god nok brennvidde for prosjektet mitt, og de kan klippes med en enkel saks (noe som ikke er tilfelle for mer raffinerte runde glasslinser). Fresnel -objektiver kan finnes navn som "lommeforstørrelsesglass" eller "lesekortforstørrelse", ettersom de er veldig passende for å hjelpe mennesker med dårlig syn å lese.

I utgangspunktet handlet trikset her om å finne det riktige kompromisset mellom:

- Å ha en rimelig virtuell bildeavstand (det vil si hvor langt HUD ser ut til å være for brukeren, eller hvor langt brukeren må justere øynene for å se hva som er på HUD)

- Å ha teksten på skjermen ikke bli for forstørret av linsen (som i utgangspunktet er en forstørrelsesglass)

- Å ha en rimelig avstand mellom OLED -skjermen og objektivet, noe som ellers ville føre til en veldig klumpete modul

Jeg bestilte personlig et par forskjellige objektiver på amazon, og bestemte de respektive brennvidder, før jeg valgte et med en F.lengde på ca 13 cm. Jeg fant denne F.lengden, med en OLED-linse avstand på 9 cm, ga meg et tilfredsstillende bilde på reflektoren min (se de siste bildene ovenfor).

Som du vil se på illustrasjonene mine, må kameraet som brukes til å ta disse bildene for å kunne fokusere på teksten som vises, justeres som om det fokuserer på et fjernt objekt, noe som gjør at alt på samme plan som reflektoren virker uklart. Dette er akkurat det vi ønsker for vår HUD.

Du finner 3d -filene for objektivholderen her.

Trinn 4: Deler - en beholder for å holde dem alle

Mens jeg skriver denne instruksen, er ikke selve beholderen som vil inneholde hvert stykke av heads-up-skjermen, helt designet. Jeg har imidlertid noen ideer om den generelle formen og hvordan jeg skal nærme meg visse problemer (for eksempel hvordan du holder en reflektor i ro og får den til å motstå 100+ km/t vind). Dette er fremdeles et pågående arbeid.

Trinn 5: Opprette en protokoll for modulen vår

For å sende navigasjonsinstruksjonene fra telefonen til utviklingsbordet, måtte jeg komme med en egen kommunikasjonsprotokoll som ville tillate meg å enkelt sende de nødvendige dataene fra telefonen, samtidig som jeg lettere kunne behandle den en gang mottatt.

Da jeg skrev denne instruksen, var informasjonen som måtte overføres fra telefonen for å navigere med modulen:

- Den kommende manøverens type (enkel sving, rundkjøring, sammenslåing til en annen vei, …)

- Den kommende manøverens presise instruksjoner (avhengig av manøvertype: høyre/venstre for en sving; hvilken avkjørsel for å ta en rundkjøring, …)

- Avstanden som gjenstår før den kommende manøveren (i meter for nå)

Jeg bestemte meg for å organisere disse dataene ved å bruke følgende rammestruktur:

: type.instruksjoner, avstand;

Selv om det ikke er en vakker løsning, lar denne oss enkelt skille og skille hvert felt i protokollen vår, noe som muliggjorde kodingen på ESP32 -siden.

Det er viktig å huske på at for fremtidige funksjoner kan det hende at annen informasjon må legges til i denne protokollen (for eksempel nøyaktig dag og klokkeslett, eller musikken som spilles av på brukerens telefon), noe som lett kan gjennomføres med den samme bygge logikk som nå.

Trinn 6: Koden: ESP32 Side

Koden for ESP32 er for tiden ganske enkel. Den bruker U8g2lib -biblioteket, som gjør det enkelt å kontrollere OLED -skjermen (samtidig som det muliggjør speiling av det viste bildet).

I utgangspunktet er alt ESP32 gjør å motta serielle data via Bluetooth når appen sender den, analyserer den og viser disse dataene eller bildene basert på disse dataene (dvs. viser en pil i stedet for setningen "sving til venstre/høyre"). Her er koden:

/*Program for å kontrollere en HUD fra en Android -app via seriell bluetooth*/#inkluderer "BluetoothSerial.h" // Header File for Serial Bluetooth, blir som standard lagt til i Arduino#include #include #ifdef U8X8_HAVE_HW_SPI#include#endif# ifdef U8X8_HAVE_HW_I2C #include #endif // OLED bibliotekskonstruktør, må endres tilsvarende til skjermen U8G2_SSD1306_128X64_ALT0_F_HW_I2C u8g2 (U8G2_MIRROR,/* reset =*/U8X8_PIN_NONE;) // Statemaskin detekterte_feltverdier + variabel#definere manøvreFelt 1#definere instruksjonerFelt 2#definere avstandFelt 3#definere endOfFrame 4int detect_field = endOfFrame; BluetoothSerial serialBT; // Objekt for Bluetoothchar incoming_char; røye manøver [10]; røyeinstruksjoner [10]; røyeavstand [10]; røyte tempManeuver [10]; røyke tempInstruksjoner [10]; røyke tempDistans [10]; int nbr_char_maneuver = 0; int nbr_char_instructions = 0; int nbr_char_distance = 0; boolsk fullsyn = feil; ugyldig oppsett () {Serial.begin (9600); // Start seriell skjerm i 9600 bauds u8g2.begin (); // Init OLED -kontroll serialBT.begin ("ESP32_BT"); // Navn på forsinkelse av Bluetooth -signal (20); Serial.println ("Bluetooth Device is Ready to Pair");} void loop () {if (serialBT.available () &&! Fullsentence) // Characters being received via Bluetooth serial {incoming_char = serialBT.read (); Serial.print ("Mottatt:"); Serial.println (innkommende_char); } switch (detect_field) {case maneuverField: Serial.println ("Detected field: maneuver"); if (incoming_char == '.') // Neste felt oppdaget {detect_field = instructionField; } annet {// Fyll manøvretypen info array maneuver [nbr_char_maneuver] = incoming_char; nbr_char_maneuver ++; } gå i stykker; case instructionsField: Serial.println ("Oppdaget felt: instruksjoner"); if (incoming_char == ',') // Neste felt oppdaget {detect_field = distanceField; } annet {// Fyll instruksjonene info array -instruksjoner [nbr_char_instructions] = innkommende_char; nbr_char_instructions ++; } gå i stykker; case distanceField: Serial.println ("Oppdaget felt: avstand"); if (innkommende_char == ';') // Slutt på ramme oppdaget {detect_field = endOfFrame; Serial.print ("manøver:"); Serial.println (manøver); Serial.print ("instruksjoner:"); Serial.println (instruksjoner); Serial.print ("avstand:"); Serial.println (avstand); fullsyn = sant; update_Display (); // Full ramme mottatt, analyser den og vis gjenopprettende data} annet {// Fyll avstanden info array array distance [nbr_char_distance] = incoming_char; nbr_char_distance ++; } gå i stykker; case endOfFrame: if (incoming_char == ':') detect_field = maneuverField; // Ny ramme oppdaget brudd; standard: // Ikke bryt noe; } forsinkelse (20);} ugyldig oppdaterings_Display () {// Bufrer hvert char -array for å unngå mulige konflikter memcpy (tempManeuver, maneuver, nbr_char_maneuver); memcpy (tempInstruksjoner, instruksjoner, nbr_char_instructions); memcpy (tempDistance, distance, nbr_char_distance); parseCache (); // Analyse og prosessering av char -arrays fullsentence = false; // Setning behandlet, klar for neste}} void parseCache () {u8g2.clearBuffer (); // tøm det interne minnet u8g2.setFont (u8g2_font_ncenB10_tr); // velg en passende skrift // char -matriser -> streng obligatorisk for å bruke substring () -funksjon String maneuverString = tempManeuver; String instructionsString = tempInstructions; // Implementere protokoll her. Støtter bare svinger foreløpig. if (maneuverString.substring (0, 4) == "turn") {// Se etter manøvertype Serial.print ("TURN DETECTED"); if (instructionsString.substring (0, 5) == "right") {// Sjekk spesifikke instruksjoner og vis deretter u8g2.drawStr (5, 15, "-"); } annet hvis (instructionString.substring (0, 4) == "venstre") {// Sjekk spesifikke instruksjoner og vis deretter u8g2.drawStr (5, 15, "<---"); } annet u8g2.drawStr (5, 15, "Err."); // Ugyldig instruksjonsfelt}/ * Implementere andre manøvretyper (rundkjøringer osv.) * Else if (tempManeuver == "rdbt") { * *] */ u8g2.drawStr (5, 30, tempDistance); // Vis gjenværende avstand u8g2.sendBuffer (); // overfør internminnet til displayet // Tilbakestill alle ble -matriser før neste leseminne (manøver, 0, 10); memset (instruksjoner, 0, 10); memset (avstand, 0, 10); memset (tempManeuver, 0, 10); memset (tempInstructions, 0, 10); memset (tempDistance, 0, 10); // Tilbakestill antall elementer i matriser nbr_char_distance = 0; nbr_char_instructions = 0; nbr_char_maneuver = 0;}

Trinn 7: Koden: Android Side

For smarttelefonappen bestemte jeg meg for å bruke Mapbox navigasjons -SDK, ettersom den tilbyr mange nyttige funksjoner når det gjelder å bygge et navigasjonskart fra bunnen av. Det tillater også bruk av mange nyttige lyttere, noe som definitivt hjelper til med å få denne modulen til å fungere. Jeg brukte også harry1453s android-bluetooth-serielle bibliotek for android, da det gjorde Bluetooth seriell kommunikasjon mye enklere å sette sammen.

Hvis du vil bygge denne appen hjemme, må du få et Mapbox -tilgangstoken, som er gratis opp til et visst antall forespørsler per måned. Du må sette dette tokenet i koden og bygge appen på din side. Du må også kode i din egen ESP32s Bluetooth MAC -adresse.

Slik den er, kan appen lede deg fra din nåværende posisjon til hvilken som helst plassering du kan klikke på på kartet. Som nevnt i introen, støtter den imidlertid ingen annen manøver enn svinger, og håndterer ikke off-ruter ennå.

Du finner hele kildekoden på min github.

Trinn 8: Hva er neste?

Nå som appen er funksjonell nok til å faktisk veilede brukeren på en bestemt rute (hvis det ikke er noen avvik fra den angitte ruten), vil hovedfokuset mitt være å forbedre smarttelefonappen og implementere de få mulighetene som ville gjøre modulen til en levedyktig navigasjonsenhet. Dette inkluderer å aktivere Bluetooth -kommunikasjon fra telefonen selv når skjermen er slått av, samt støtte for andre typer manøvrer (rundkjøringer, sammenslåing, …). Jeg vil også implementere en omdirigeringsfunksjon hvis brukeren avviker fra den opprinnelige ruten.

Når alt dette er gjort, vil jeg forbedre beholderen og festemekanismen, 3d -skrive den ut og prøve å ta modulen for en første runde.

Hvis alt går bra, er mitt langsiktige mål å designe en tilpasset PCB for den innebygde elektronikken i dette prosjektet, noe som vil spare mye plass på sluttproduktet.

Jeg kan også legge til noen andre funksjoner i denne modulen i fremtiden, inkludert en tidsvisning, samt en telefonvarselalarm, som kan få et ikon til å vises når brukeren mottar en tekstmelding eller et anrop. Til slutt vil jeg gjerne legge til Spotify -evner til denne modulen, som en stor musikkfan. På dette tidspunktet er dette imidlertid bare hyggelig å ha.

Trinn 9: Konklusjon og spesiell takk

Som nevnt i introen, selv om dette prosjektet langt fra er ferdig, ønsket jeg virkelig å dele det med verden, i håp om at det kan inspirere noen andre. Jeg ønsket også å dokumentere forskningen min om dette emnet, da det egentlig ikke er mye hobbyinteresse for AR og HUD, noe jeg synes er synd.

Jeg vil rette en stor takk til Awall99 og Danel Quintana, hvis respektive augmented reality -prosjekt inspirerte meg mye i utformingen av denne modulen.

Takk alle for oppmerksomheten, jeg kommer til å legge ut en oppdatering når dette prosjektet blir forbedret i nær fremtid. I mellomtiden sees vi alle senere!