Smart motorcykel HUD-prototype (turn-by-turn navigation og så meget mere): 9 trin

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:25

Hej !

Denne instruktion er historien om, hvordan jeg designede og byggede en HUD-platform (Heads-Up Display) designet til at blive monteret på motorcykelhjelme. Det blev skrevet i forbindelse med "maps" -konkurrencen. Desværre var jeg ikke i stand til fuldstændigt at afslutte dette projekt i tide til konkurrencens deadline, men jeg ville stadig dele mine fremskridt med det samt dokumentere alt det forsøg og fejl, jeg fik ved at lave det.

Ideen til dette projekt kom først til mig for et par år siden, da jeg satte mig ind i motorcykler, og jeg begyndte at undersøge, hvilket gear jeg skulle købe for at gøre mine ture sjovere. På det tidspunkt forvirrede det mig, at den bedste måde at få noget grundlæggende GPS -navigation under ridning var i bund og grund at vedhæfte din smartphone til din cykels styr. Jeg tænker for mig selv, at der helt sikkert kunne være en bedre måde at få den slags information på farten.

Det var da det kom til mig: et head-up display kunne være måden at få navigation på, mens du kører, uden at tømme telefonens batteri og udsætte det for elementerne.

Med tiden modnet denne idé i mit sind, og jeg tænkte dog på, at hvis jeg altid havde et HUD foran mig, ville der være mulighed for mange flere anvendelser end simpel navigation. Det er derfor, min plan er at gøre platformen offentlig og modulær, så alle kan oprette et modul, der viser de oplysninger, de har brug for på deres eget HUD

Selvom der er kommercielt tilgængelige produkter, der opfylder denne opgave, er der ikke nogen, der er så modulære som min platform, og de har også en tendens til at være lidt dyre. Under alle omstændigheder, velkommen til dette projekt.

Hvad virker fra nu af

Som nævnt er dette projekt stadig meget i udviklingstilstand, og det er det, der i øjeblikket fungerer.

- Kommunikation mellem en smartphone og et ESP32 -baseret kort (telefon vågen)

- Optisk design udført (muligvis brug for små justeringer i det lange løb)

- Android navigation app ved hjælp af Mapbox navigation SDK:

- I stand til at beregne og vise brugerens position på et kort, samt en rute fra den til destinationen

- Kan oprette forbindelse til en Bluetooth -enhed (enhedens MAC -adresse er hardkodet fra nu)

- Kan navigere i realtid, herunder udtrækning og afsendelse af den kommende manøvres oplysninger via seriel Bluetooth (understøtter kun sving i øjeblikket)

Hvad har brug for arbejde

Denne liste indeholder elementer, der er absolut nødvendige for HUD's tilsigtede brug, men som ikke er klar til at blive implementeret endnu.

- Overordnet design (hjelmfastgørelse, reflektorens vinkeljusteringsmekanisme,..)

- Android app:

- Implementering og korrektion uden for ruten

- Mulighed for brugeren til at indtaste destinationsadressen

- Vejpunkter?

- Ergonomi / æstetik

Tilbehør:

Væsentlige

- Et esp32 baseret udviklingsbord

- Enhver noget nyere android smartphone (Bluetooth aktiveret)

- En SSD1306 eller anden aktiveret 96 "OLED -skærm (min var 128x64 pixel, se afsnittet" Hjernen: Mikrocontroller og skærm ")

- En reflektor (ethvert stykke akryl/glas/plexiglas gør)

- En Fresnel linse (min havde en F. længde på ca. 13 cm, se "Lens valg" del)

Værktøjer

- Loddekolbe

- Brødbræt

- Et par springkabler

- 3d printer / 3d print service

Trin 1: Sådan fungerer det hele: Designvalg forklaret

Grundidéen med en Heads Up Display er at vise et billede foran en persons vision, så de ikke behøver at se væk fra det, de laver (det være sig at styre et fly eller køre en motorcykel, hvilket bliver vores eksempel case).

Optik

Teknisk set kan dette opnås ved lige at sætte en skærm foran brugerens øjne. En skærm er imidlertid ikke gennemsigtig og vil derfor hindre brugerens syn. Du kan derefter placere skærmen foran en reflekterende overflade, som afspejler skærmens indhold og samtidig er gennemsigtig nok til, at brugeren kan se, hvad der er foran ham.

Denne fremgangsmåde har imidlertid en enorm fejl: den faktiske skærm er normalt tættere på brugerens øjne, end hvad brugeren faktisk skal fokusere på (f.eks. Vejen foran ham). Det betyder, at for at kunne læse, hvad der er på den reflekterende overflade, skal brugerens øjne tilpasse sig displayets afstand til øjnene (lad os sige 20 cm) og derefter skulle tilpasse sig igen for at fokusere på vejen forude (~ 2/5 meter). Den tid, hele denne operation tager, er dyrebar tid, der skal bruges på at se på vejen, og tilpasning ofte kan være ubehagelig for brugeren efter bare et par minutter.

Derfor besluttede jeg at tilføje et objektiv mellem skærmen og reflektoren. Dette objektiv bør, hvis det vælges omhyggeligt, muliggøre oprettelse af et virtuelt billede af skærmen (se skematisk oversigt ovenfor), som derefter ser ud til at være længere væk fra brugerens øjne, som det faktisk er, hvilket kræver mindre abrupte tilpasninger (eller slet ingen i et perfekt scenario). Dette design gør det muligt for brugeren hurtigt at kigge på reflektoren, få de oplysninger, han har brug for, og øjeblikkeligt kigge tilbage på vejen.

Smartphoneens rolle

Fordi det var urealistisk at prøve at implementere et helt navigationsprogram på ESP32 alene, besluttede jeg at lave en Android -app, der ville tage sig af dette. App'en skal derefter bare fortælle ESP32, hvad brugeren skal gøre for at komme til sin destination, og ESP32 videresender disse oplysninger via HUD (se figuren "Sådan fungerer modulet").

Trin 2: Dele - Brains: Microcontroller & Screen

Som anført ovenfor planlagde jeg at få mit modul til at vise navigationsoplysninger, mens jeg faktisk ikke fik det til at beregne den faktiske positionering, sporing og navigation i realtid. brugerens telefon ville i stedet kommunikere med modulet og sende den informationen for derefter at blive vist på HUD.

For at lette kommunikationen mellem brugerens telefon og modulet valgte jeg at bruge et ESP32 -baseret kort til dette projekt. Dette valg skyldtes, at dette specifikke modul havde integrerede Bluetooth-funktioner samt et par andre interessante specifikationer (let at bruge ikke-flygtig opbevaring, dual-core CPU, nok RAM til faktisk at køre OLED-skærmen via I2C, …). Det er relativt enkelt at designe PCB baseret på ESP32, hvilket jeg tog i betragtning. Jeg har også professionel erfaring med at bruge og designe kredsløb med ESP32, hvilket bestemt påvirkede mit valg.

Valget af skærmen kom stort set ned på, hvad jeg end kunne finde ud af, at jeg dog ville være lys nok til y -brug, samtidig med at den var så lille som muligt. Jeg var ikke særlig bekymret for antallet af pixels på skærmen, da mit mål var at have et meget minimalistisk og enkelt brugergrænseflade.

Det skal bemærkes, at skærmdriveren skal understøttes af et bibliotek, der giver mulighed for billedspejling. Det skyldes, at det viste billede bliver vendt, når det kommer gennem linsen og vises på reflektoren, og det ikke er nødvendigt manuelt at vende det, der vises, er en enorm vægt fra vores skuldre som bygherrer.

Trin 3: Dele - Optik: Find et kompromis

Optikken til dette projekt var ret svær at tilgå, da jeg ikke anede, hvad jeg selv ledte efter, da jeg første gang startede dette projekt. Efter nogle undersøgelser forstod jeg, at det, jeg ville gøre, var at skabe et "virtuelt billede" af min OLED -skærm, der ser ud til at være længere væk fra øjet, end det faktisk er. Den ideelle afstand for dette virtuelle billede, der skal dannes, ville være på omkring 2-5 meter foran føreren, a det ser ud til at være afstanden til de objekter, vi fokuserer på, når vi kører (andre biler, buler på vejen osv …).

For at nå dette mål valgte jeg at bruge et Fresnel -objektiv, da disse er ret store, billige, de syntes at tilbyde en god nok brændvidde til mit projekt, og de kan klippes med en simpel saks (hvilket ikke er tilfældet for mere raffinerede runde glaslinser). Fresnel -linser kan findes navne som "lommeforstørrelsesglas" eller "læsekort -lup", da de er meget passende til at hjælpe mennesker med dårligt syn med at læse.

Grundlæggende handlede tricket her om at finde det rigtige kompromis mellem:

- At have en rimelig virtuel billedafstand (det vil sige, hvor langt HUD ser ud til at være for brugeren, eller hvor langt brugeren skal justere øjnene for at se, hvad der er på HUD)

- At have teksten på skærmen ikke forstørres for meget af linsen (som i bund og grund er en forstørrelsesglas)

- At have en rimelig afstand mellem OLED -skærmen og objektivet, hvilket ellers ville føre til et meget omfangsrigt modul

Jeg bestilte personligt et par forskellige objektiver på amazon og bestemte deres respektive brændvidder, inden jeg valgte en med en F.længde på cirka 13 cm. Jeg fandt denne F. længde, med en OLED-linse afstand på 9 cm, gav mig et tilfredsstillende billede på min reflektor (se de sidste par billeder ovenfor).

Som du vil se på mine illustrationer, for at kunne fokusere korrekt på den viste tekst, skal kameraet, der bruges til at tage disse billeder, justeres, som om det fokuserede på et fjernt objekt, hvilket får alt på samme plan som reflektoren til at virke sløret. Det er præcis det, vi ønsker for vores HUD.

Du kan finde 3d -filerne til linseholderen her.

Trin 4: Dele - en beholder til at holde dem alle

Mens jeg skriver denne Instructables, er den egentlige beholder, der vil indeholde hvert stykke af heads-up-displayet, ikke helt designet. Jeg har dog et par ideer om dens generelle form og om hvordan man griber visse problemer an (f.eks. Hvordan man holder en reflektor stille og får den til at modstå 100+ km/t vind). Dette er stadig meget i gang.

Trin 5: Oprettelse af en protokol til vores modul

For at sende navigationsinstruktionerne fra telefonen til udviklingskortet, var jeg nødt til at komme med en egen kommunikationsprotokol, der ville gøre det muligt for mig let at sende de nødvendige data fra telefonen, samtidig med at det blev lettere at behandle den, når den var modtaget.

På tidspunktet for skrivningen af denne instruks var de oplysninger, der skulle transmitteres fra telefonen for at navigere med modulet:

- Den kommende manøvres type (enkel drejning, rundkørsel, fusionering på en anden vej, …)

- Den kommende manøvres præcise instruktioner (afhængig af manøvertypen: højre/venstre for et sving; hvilken afkørsel der skal tages til en rundkørsel, …)

- Den resterende afstand før den kommende manøvre (i meter for nu)

Jeg besluttede at organisere disse data ved hjælp af følgende rammestruktur:

: type.instruktioner, afstand;

Selvom den ikke er en smuk løsning, giver denne os mulighed for let at adskille og skelne hvert felt i vores protokol, hvilket letter kodningen på ESP32 -siden.

Det er vigtigt at huske på, at for fremtidige funktioner kan det være nødvendigt at tilføje andre oplysninger til denne protokol (f.eks. Den nøjagtige dag og tid eller den musik, der afspilles på brugerens telefon), hvilket let ville være muligt at bruge den samme bygningslogik som nu.

Trin 6: Koden: ESP32 Side

Koden til ESP32 er i øjeblikket ganske enkel. Det bruger U8g2lib -biblioteket, som gør det let at styre OLED -skærmen (samtidig med at det viste billede kan spejles).

Grundlæggende er alt, hvad ESP32 gør, at modtage serielle data via Bluetooth, når appen sender dem, analyserer dem og viser disse data eller billeder baseret på disse data (dvs. viser en pil i stedet for sætningen "drej til venstre/højre"). Her er koden:

/*Program til at styre en HUD fra en Android -app via seriel bluetooth*/#inkluderer "BluetoothSerial.h" // Header File til Serial Bluetooth, tilføjes som standard til Arduino#include #include #ifdef U8X8_HAVE_HW_SPI#include#endif# ifdef U8X8_HAVE_HW_I2C #include #endif // OLED bibliotekskonstruktør, skal ændres i overensstemmelse hermed til din skærmU8G2_SSD1306_128X64_ALT0_F_HW_I2C u8g2 (U8G2_MIRROR,/* reset =*/U8X8_PIN_NONE;) // Statens maskine detekterede_feltværdier + variabel#definere manøvreFelt 1#definere instruktionerFelt 2#definere distanceFelt 3#definere endOfFrame 4int detekteret_felt = endOfFrame; BluetoothSerial serialBT; // Objekt til Bluetoothchar inkoming_char; char manøvre [10]; char instruktioner [10]; char distance [10]; char tempManeuver [10]; char tempInstructions [10]; char tempDistance [10]; int nbr_char_maneuver = 0; int nbr_char_instructions = 0; int nbr_char_distance = 0; boolsk fuldsendelse = falsk; ugyldig opsætning () {Serial.begin (9600); // Start seriel skærm i 9600 bauds u8g2.begin (); // Init OLED -kontrol serialBT.begin ("ESP32_BT"); // Navn på forsinkelsen af Bluetooth -signal (20); Serial.println ("Bluetooth -enhed er klar til parring");} void loop () {if (serialBT.available () &&! Fullsentence) // Tegn modtages via Bluetooth seriel {incoming_char = serialBT.read (); Serial.print ("Modtaget:"); Serial.println (indgående_char); } switch (opdaget_felt) {case maneuverField: Serial.println ("Detekteret felt: manøvre"); hvis (indgående_char == '.') // Næste felt opdaget {detect_field = instructionField; } ellers {// Fyld manøvretypen info array manøvre [nbr_char_maneuver] = indgående_char; nbr_char_maneuver ++; } pause; sag instruktionerFelt: Serial.println ("Detekteret felt: vejledning"); hvis (indgående_char == ',') // Næste felt registreret {detekteret_felt = distanceFelt; } ellers {// Udfyld instruktionerne info array -instruktioner [nbr_char_instructions] = indgående_char; nbr_char_instructions ++; } pause; case distanceField: Serial.println ("Detekteret felt: afstand"); hvis (indgående_char == ';') // Slut på ramme fundet {detect_field = endOfFrame; Serial.print ("manøvre:"); Serial.println (manøvre); Serial.print ("vejledning:"); Serial.println (vejledning); Serial.print ("afstand:"); Serial.println (afstand); fuldstændighed = sand; update_Display (); // Fuld ramme modtaget, analyser det og vis recever data} ellers {// Fyld afstandsoplysnings array afstand [nbr_char_distance] = indkommende_char; nbr_char_distance ++; } pause; case endOfFrame: if (incoming_char == ':') detect_field = maneuverField; // Ny ramme opdaget brud; standard: // Gør ingenting i stykker; } forsinkelse (20);} ugyldig update_Display () {// Cache hvert char -array for at undgå mulige konflikter memcpy (tempManeuver, maneuver, nbr_char_maneuver); memcpy (tempInstruktioner, instruktioner, nbr_char_instructions); memcpy (tempDistance, distance, nbr_char_distance); parseCache (); // Parse og behandle char -arrays fullsens = false; // Sætning behandlet, klar til den næste} void parseCache () {u8g2.clearBuffer (); // ryd den interne hukommelse u8g2.setFont (u8g2_font_ncenB10_tr); // vælg en passende skrifttype // char arrays -> streng obligatorisk for at bruge substring () funktion String maneuverString = tempManeuver; String instructionsString = tempInstructions; // Implementering af protokol her. Understøtter kun sving i øjeblikket. if (maneuverString.substring (0, 4) == "turn") {// Check for maneuver type Serial.print ("TURN DETECTED"); if (instructionsString.substring (0, 5) == "right") {// Kontroller specifikke instruktioner og vis u8g2.drawStr (5, 15, "-") i overensstemmelse hermed; } ellers hvis (instructionString.substring (0, 4) == "venstre") {// Kontroller specifikke instruktioner og vis i overensstemmelse hermed u8g2.drawStr (5, 15, "<---"); } ellers u8g2.drawStr (5, 15, "Err."); // Ugyldigt instruktionsfelt}/ * Implementer andre manøvrtyper (rundkørsler osv.) * Else if (tempManeuver == "rdbt") { * *] */ u8g2.drawStr (5, 30, tempDistance); // Vis resterende afstand u8g2.sendBuffer (); // overfør intern hukommelse til displayet // Nulstil alle char -arrays før næste læsning memset (manøvre, 0, 10); memset (vejledning, 0, 10); memset (afstand, 0, 10); memset (tempManeuver, 0, 10); memset (tempInstructions, 0, 10); memset (tempDistance, 0, 10); // Nulstil antal elementer i arrays nbr_char_distance = 0; nbr_char_instructions = 0; nbr_char_maneuver = 0;}

Trin 7: Koden: Android Side

Til smartphone -appen besluttede jeg at bruge Mapbox's navigations -SDK, da det tilbyder en masse nyttige funktioner, når det kommer til at bygge et navigationskort fra bunden. Det tillader også brug af mange nyttige lyttere, hvilket helt sikkert hjælper med at få dette modul til at fungere. Jeg brugte også harry1453s android-bluetooth-serielle bibliotek til android, da det gjorde Bluetooth seriel kommunikation meget lettere at sammensætte.

Hvis du vil bygge denne app derhjemme, skal du få et Mapbox -adgangstoken, som er gratis op til et bestemt antal anmodninger om måneden. Du bliver nødt til at sætte dette token i koden og bygge appen på din side. Du skal også kode i din egen ESP32s Bluetooth MAC -adresse.

Som det ser ud, kan appen guide dig fra din nuværende placering til enhver placering, du kan klikke på på kortet. Som nævnt i introen understøtter den dog ikke anden manøvre end sving og håndterer ikke off-ruter endnu.

Du kan finde hele kildekoden på min github.

Trin 8: Hvad er det næste?

Nu hvor appen er funktionel nok til faktisk at guide sin bruger på en bestemt rute (hvis der ikke er afvigelser fra den indstillede rute), vil mit hovedfokus være at forbedre smartphone -appen og implementere de få muligheder, der ville gøre modulet til en levedygtig navigationsenhed. Dette inkluderer aktivering af Bluetooth -kommunikation fra telefonen, selv når skærmen er slukket, samt understøttelse af andre former for manøvrer (rundkørsler, fusion, …). Jeg vil også implementere en omdirigeringsfunktion, hvis brugeren afviger fra den oprindelige rute.

Når alt dette er gjort, vil jeg forbedre beholderen og dens fastgørelsesmekanisme, 3D -udskrive den og prøve at tage modulet til et første løb.

Hvis alt går godt, er mit langsigtede mål at designe et brugerdefineret printkort til den integrerede elektronik i dette projekt, hvilket ville spare meget plads på det endelige produkt.

Jeg kan også tilføje nogle andre funktioner til dette modul i fremtiden, herunder en tidsvisning, samt en telefonmeddelelsesalarm, som kan få et ikon til at vises, når brugeren modtager en tekstbesked eller et opkald. Endelig vil jeg meget gerne tilføje Spotify -muligheder til dette modul som en stor musikfan. På dette tidspunkt er dette dog kun rart at have.

Trin 9: Konklusion og særlig tak

Som nævnt i introen, selvom dette projekt langt fra er færdigt, ville jeg virkelig dele det med verden, i håb om at det kunne inspirere en anden. Jeg ville også dokumentere min forskning om dette emne, da der egentlig ikke er særlig stor hobbyinteresse for AR og HUD, hvilket jeg synes er ærgerligt.

Jeg vil gerne sige en kæmpe tak til Awall99 og Danel Quintana, hvis respektive augmented reality -projekt inspirerede mig meget ved udarbejdelsen af dette modul.

Tak alle for jeres opmærksomhed, jeg vil helt sikkert sende en opdatering, når dette projekt bliver forbedret i den nærmeste fremtid. I mellemtiden ses vi alle senere!