Part 2 of car Raspberry pi 4 GPS project
Part 2 of car Raspberry pi 4 GPS project
Hello everyone!
I already posted a first time here a while ago: https://lemmy.world/post/30549957
My goal was to replace my Android Auto + phone setup for satnav in car with a dedicated Raspberry Pi.
Here's a status update of the project so far!
Choosing the parts and getting them here was obviously fairly easy even though it took quite bit of research to find a way to power the Pi4 in car reliably.
It's a pi4 with an adafruit ultimate gps dongle, an SD card and a 2.5 SSD. The SD for OS installs, and then I clone them to SSD for better stability and performances.
I first tried to go Pi OS route. I figured Linux might open more possibilities and I'm more comfortable with Linux. I tried a few options in Pi OS, namely Navit. I banged my head quite hard on that one, trying to figure out how to make it work, but I never managed to get a good navit.xml config file. After hours upon hours of trials, I gave up.
Tried Organic Maps then, but it was a flatpak which introduced a lot of permission issues and I never got the GPS dongle to talk to the app.
After a few failed attempts, I decided to try Emteria OS, an android spin available in the Pi Imager. It doesn't boot without SD card as opposed to PiOS, so I was glad I spent the 5€ for the SD card. It booted easily, SSH was harder to enable than on Linux but it's likely because I just know Linux better. Installing apps was easy, but I stopped there and didn't even try to get the GPS working because 90% of my RAM was used idling at boot, which makes the whole project impossible on Emteria. Not sure if there's a bug in the current version or what, but I simply moved on.
Then I went to LineageOS. Similarly to Emteria, installing apps was very easy. Getting the GPS from Adafruit to talk to Android was fairly easy if you read the docs carefully. I needed to install android dev tools on my main PC and connect to the Pi using ADB as root to edit some config files. That's it, the GPS worked and I had a working GPS unit.
Now I'm at the point where I need to introduce the package into the car. For now , the pi still doesn't have a case because I didn't want to limit my options in the car. I still haven't found a good way to bring the pi with me and have it being safely transported without breaking or even becoming a deadly cannonball in case of crash.
My current idea that I'm exploring and checking is getting a Pelican Case, not sure if any of their cases has vent holes. The pi would go inside the case, and the case would be attached to a strong anchor point like the seat rails. Not sure how, yet. I'm thinking maybe about carabiners from Petzl since they would be much stronger than needed, I'm just not sure the anchor point on the case would be strong enough.
So there you have it, I've made good progress on the project and I'm confident it will work out reasonably well.
I'm currently doing the same project.
To get gps to work on linux, you configure gpsd to get the data from your gps module and setup geoclue to get its data from gpsd. I lost the config files but I remember that I did the gpsd geoclue connection by echoing the gps data of gpsd into a netcat socket and connecting geoclue to it. Organic maps then automaticly gets its position from geoclue.
Im also working on a organic maps fork, which shows onscreen directions on linux.
I had GPSD working nicely, confirmed both by cgps -s and mongps, but I was stuck on geoclue. Whatever I did, the GPS wouldn't send data to Organic Maps. I kept having this error: "Error: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/org/freedesktop/GeoClue2/Client/1”" despite being 100% sure client1 was the right one.
Going to Lineage OS was much easier for me and I just needed a working GPS. Linux GPS will stay in the "challenge todo list", because I'd like to figure it out eventually. I most likely was doing something stupid.
If you ever want to try it, here are the config files and commands from my bash history.
https://codeberg.org/KaninchenSpeed/c5-car/src/branch/main/gps
The geoclue file is set up for organic maps.
You can also run organic maps without flatpak, but you might need to compile it yourself.
I was considering something similar for my Volvo 940 about around 2010. The idea was that I'd install a touch screen as an infotainment system where I could see stuff like OBD2 data and navigation.
While not having a functioning speedometer for a little bit (later fixed), I used my phone to see the GPS speed with the screen flipped so I could get the speed on the windshield like a HUD in some modern cars. The plan was to do something similar integrated with the home brewed infotainment.
It annoys me that I never went through with it, because so much stuff of what I'd drawn up became standard for "fancy" cars later.
I'm currently doing this to a Citroën C5 III (2015). The hdd in the old infotainment system broke, so I had a reason to do it, and adding a few features couldn't hurt.
It's a huge pain to get to find information about anything in this car and to get anything to work properly, but I hope it'll be worth it.
For offline navigation on Linux, have you looked at osmin? It was pretty decent on a PinePhone.
How do you handle power-off? Does Raspberry Pi just shut down? My thoughts were to use Alpine or some RAM-based OS that would not corrupt SD card or the hard drive.
I have been messing around with building an in-car navigation from e-waste for a while now. Right now, I settled on an old smartphone with OsmAnd and wrote my own app to view the reverse camera.
I didn't know about osmin! I might try it out.
For the poweroff, I'll just poweroff the Pi from the UI and wait a sec for it to go down. Initial testing has me waiting 10 seconds on the "shutting down" screen. That's short enough, meanwhile I can put my jacket on or something. Once off, I just unplug it. It's also running on SSD because I don't trust SD cards to endure constant read/write from satnav so I installed from SD card and cloned the OS to an SSD, it should be more resilient this way.
What material are you using to print your enclosures? I know abs is pretty bad for car type heat...
(I haven't really used them a lot in the heat yet) Last enclosure was ASA, but AFAIK, black ABS is OK too because black pigment absorbs most of the light/UV, preventing plastic from degrading as fast
Curious question: have you looked into something like this https://a.co/d/b6tSJDI ? Sorry for the amazon link there, use it as inspiration. Maybe some cheap stereo box with power supply, etc? This might fit better in a car than a pelican case and may allow you to stuff components, fan etc
Hey, thanks for the link. I haven't looked at that type of parts because I'm not confident tinkering with the car, especially since it's still fairly new and I'm too afraid to damage some plastic. And I also don'"t have any spare room available on the dashboard anywhere.
There's a little nook to empty your pocket between the gear shifter (manual car) and the dashboard but it's wide open, fairly hot, and probably still too small even to fit a raspberry pi in a case with the cooling I'll need.
That's why I've been looking at external solutions. If wires weren't an issue, I'd put a trunk/boot organizer at the back and store the pi unit there during drives but it's not practical with the wiring. Still routing cables in my head in case I'd get an idea.
Here's a photo I found of the front of the car: https://www.ouestfrance-auto.com/sites/default/files/sandero_stepway_1_0.jpg
Why not 3D print something for it? I printed this to make a digital photo frame with a Pi 4 and the official 7" Pi touch display. https://www.printables.com/model/44218-7-touchscreen-case-for-raspberry-pi-4-internal-fan
Printing it with something strong should help keep it safe in an accident though you'll need to create a mounting solution.
How do you plan to get audio in? Bluetooth? Wired audio input?
In your first post you were calling it a head unit, which would replace everything. Given the picture, you have a more fully integrated android auto compatible system rather than a traditional head unit, so I understand why the other commenter pointed to that - its similar to what I would have suggested, which would be to get a din cover appropriately sized, then cut out for a screen.
So the question becomes how do you want to hear and/or see? That would decide placement requirements. For example, I have a nice spot in the passenger seat I could easily hide it behind a panel under the dash, but the audio input I'd have to bring over to the armrest. So I'd run a cable under the carpet to the aux input, bring it up the side of the armrest and plug it in.
FWIW, your phone may work nicely by rebooting into recovery and wiping the cache partition. That resolved things for my wife and her car, no issues or trouble since.
