Can HUDIY work on other Linux SBC?
Can HUDIY work on other Linux SBC?
Just curious if HUDIY can run on other Linux SBC with higher performance?
Re: Can HUDIY work on other Linux SBC?
It should be doable if the Linux on that SBC uses standard kernel mechanisms (such as DRM, V4L2, NM). Which SBC do you have in mind exactly?
Hudiy Team
Re: Can HUDIY work on other Linux SBC?
I'm thinking something like Jetson Orin and Lattepanda Sigma that have stronger compute system. LattePanda Sigma that runs Ubuntu and has build in Arduino Leonardo MCU for various control.
https://www.electromaker.io/blog/articl ... AM%20specs.
https://www.electromaker.io/blog/articl ... AM%20specs.
-
RockyHarder22
- Posts: 6
- Joined: Mon Sep 15, 2025 1:43 am
Re: Can HUDIY work on other Linux SBC?
I've been playing around with the Radxa Zero3W3E. The minimal Armbian Debian 12 image works well on that board with a desktop added. The main issue I'm running into is hudiy wants a specific version of libboost (and the config file is different). I did get slash screen to display, but have to play with getting labwc on 12.
Re: Can HUDIY work on other Linux SBC?
Orange Pi 5 and above. Very cool offering and I'm going to test it out after I get mine working with custom teensy controller board.
Re: Can HUDIY work on other Linux SBC?
Anyone wanting to try it on x86 might want to try installing the Raspberry PI Desktop image: https://www.raspberrypi.com/software/operating-systems/
It's older Debian 11, but can be updated to Debian 12. Might provide a similar environment to on an actual raspberry pi.
It's older Debian 11, but can be updated to Debian 12. Might provide a similar environment to on an actual raspberry pi.
-
RockyHarder22
- Posts: 6
- Joined: Mon Sep 15, 2025 1:43 am
Re: Can HUDIY work on other Linux SBC?
Popping back in with a small update -- I started messing around with this in earnest around May, but got sidetracked, so I'm currently trying to retrace my steps and take notes, but I did successfully get HUDIY running on a Radxa zero3W, building onto the Armbian vendor kernel cli image with help from GPT.
The image uses a wayland/labwc environment instead of a full desktop to minimize resource usage.
It loads, uses RTLSDR (I have the v4 version which is no longer being produced fyi), and Android Auto connects via wireless and USB and plays smoothly. I believe there's some difference in how the gpio works on this board, but I haven't gotten around to that yet.
It is using hardware acceleration, and with active cooling the board never really gets above 50c. It uses around 1/2GB of RAM.
The board I used to do this was a 4GB version. Unfortunately I took terrible notes getting this set up and then walked away for a bit, so my current mission is to recreate this image from scratch and test my findings. I have this board on 4GB, 2GB, and 1GB variations, and given the RAM usage seen, I would speculate it should work on all three.
My known caveats at this point would be - - the board has a USB 3.0 port, but it seems like images that are not the official radxa ones lack this support. I'm trying to figure that out as well, but most of what I'm using isn't or doesn't need 3.0 speeds. That said, both the radxa official and Armbian images can be run with boot on SD and root on a separate device like an SSD, so that would be a benefit to it working properly.
Radxa's official images seem fine when they work, but they can be a pita to get setup. And updating the system outside of their rsetup program can break things. Some of the things going on with their boards are tied specifically to the pre-created users the images come with, so there's also that. All that being said, once I get it going on Armbian, I am going to give an attempt at setting it up on the official image, which uses a kde desktop.
The other caveat is, unfortunately, availability- with the RAM shortage and everything going on, these boards have become very difficult to find. Arace has occasionally had moments where they have 1 or 2GB in stock at a more reasonable-for-the-time price. Currently Amazon has some in stock, but they want like $80. I bought the 1 GB version that I have from Arace a couple months ago for $30, probably 40 with shipping.
The final caveat might be camera connection - obviously a USB camera would be fine, but getting a pi 1 or 2 camera working on this board is trying with the radxa official image and a nightmare to do on the Armbian image (those are the only two supported cameras, although radxa has their own version of the pi2 camera and I believe a 4k camera). Id managed to get it working when the board first came out, long before hudiy, but I'd have to dust off my druthers to try and tackle that again.
I also have a dragon q6a that i haven't even opened yet. To some degree that might be overkill for this, but I guess we'll see.
The image uses a wayland/labwc environment instead of a full desktop to minimize resource usage.
It loads, uses RTLSDR (I have the v4 version which is no longer being produced fyi), and Android Auto connects via wireless and USB and plays smoothly. I believe there's some difference in how the gpio works on this board, but I haven't gotten around to that yet.
It is using hardware acceleration, and with active cooling the board never really gets above 50c. It uses around 1/2GB of RAM.
The board I used to do this was a 4GB version. Unfortunately I took terrible notes getting this set up and then walked away for a bit, so my current mission is to recreate this image from scratch and test my findings. I have this board on 4GB, 2GB, and 1GB variations, and given the RAM usage seen, I would speculate it should work on all three.
My known caveats at this point would be - - the board has a USB 3.0 port, but it seems like images that are not the official radxa ones lack this support. I'm trying to figure that out as well, but most of what I'm using isn't or doesn't need 3.0 speeds. That said, both the radxa official and Armbian images can be run with boot on SD and root on a separate device like an SSD, so that would be a benefit to it working properly.
Radxa's official images seem fine when they work, but they can be a pita to get setup. And updating the system outside of their rsetup program can break things. Some of the things going on with their boards are tied specifically to the pre-created users the images come with, so there's also that. All that being said, once I get it going on Armbian, I am going to give an attempt at setting it up on the official image, which uses a kde desktop.
The other caveat is, unfortunately, availability- with the RAM shortage and everything going on, these boards have become very difficult to find. Arace has occasionally had moments where they have 1 or 2GB in stock at a more reasonable-for-the-time price. Currently Amazon has some in stock, but they want like $80. I bought the 1 GB version that I have from Arace a couple months ago for $30, probably 40 with shipping.
The final caveat might be camera connection - obviously a USB camera would be fine, but getting a pi 1 or 2 camera working on this board is trying with the radxa official image and a nightmare to do on the Armbian image (those are the only two supported cameras, although radxa has their own version of the pi2 camera and I believe a 4k camera). Id managed to get it working when the board first came out, long before hudiy, but I'd have to dust off my druthers to try and tackle that again.
I also have a dragon q6a that i haven't even opened yet. To some degree that might be overkill for this, but I guess we'll see.
Re: Can HUDIY work on other Linux SBC?
Thanks for the update. Keep it up! I want to use Intel based SBC one day
-
RockyHarder22
- Posts: 6
- Joined: Mon Sep 15, 2025 1:43 am
Re: Can HUDIY work on other Linux SBC?
Update - -
I will need to retest the vendor kernel for this board later; my focus shifted toward giving it a shot on Armbian current kernel since it now has the GPU support that was lacking when the board was introduced. I still have my working copy on armbian vendor kernel backed up for the time being.
The possible benefit to vendor kernel would be that the pi cameras v1 and v2 could theoretically be used for the backup camera source on vendor, but the mainline support just isn't there yet outside of the proper rpi realm. On vendor kernel, a custom ffmpeg can be compiled to support the use of the camera via v4l2, but for current kernel USB or netwok cameras would be the way to go with the least amount of headache.
I've expanded my testing to the OrangePi 3B, and will be getting a Radxa Rock 3C later this week -- Both boards use the same processor as the Radxa Zero3W and have the same GPU. TBH I'd kind of forgotten about the OrangePi board because there were some issues around board version numbers and kernel changes that would cause on-board ethernet to fail unless it was speed-limited, and intermittent issues with the bluetooth/wifi not working or not surviving reboot, so it's kind of been a paperweight for a bit, to the point that during my testing I realized I have an 8GB version.
My hope is the Radxa 3B will ultimatel be the most stable of the bunch -- not that the zero3w isn't, but the issues with the usb3.0 cable orientation is a bit frustrating. although the obvious advange would be board size.
Testing with Orange Pi 3B - I have a full working Hudiy 2.20
I'm using the same setup scripts I used on legacy kernel with current kernel -- Armbian only offers current kernel images for this board. As I mentioned before, I have a basic lawbc / wayland desktop which is installed on top of Armbian's debian trixie cli image.
Because of the issues with Opi 3B I decided the best best would be to use both an external Blutooth ada+pter and an external wifi adapter via USB. The bluetooth adapter is used all around instead of the on-board, while the USB wifi is configured as the hotspot for HUDIY. Onboard wifi is configured for my home network and phone hotspot -- both of these are configured in NetworkManager; with the hudiy main config hotspot settings matching the hotspot conf, HUDIY uses the USB wifi to communicate with the phone. This also allows me to ssh /vnc (via wayvnc) into the board to watch btop/htop/etc while the HUDIY is running.
The main benefit of the external wifi - When I was trying to actually road test this setup, the audio would stutter soemthing awful when the hotspot created with the on-board adapter, specifically when Android Auto was running. Using the external wifi elimated that issue.
We're still using around a half-gig of ram when things are running full-tilt. On the Zero3W 1GB of course the cache is a factor but it still runs smoothly. 8GB might be overkill for this setup overall (except sometimes, as they say) but this is the most love I've given Orange Pi so that's something.
On both of these, with heatsinks and active cooling the tempeature really never gets above 50. CPUs are working hardest when Android Auto is active and FM radio is playing, and they average about 50% at that point. for AA the setting I'm using are 720p / 30 fps. 1080p crashes it. 720 /60 fps works, with CPU popping up to 55-65. With 720/60 AA displayed while fm radio is playing the CPU are jumping up into 70-90% territory but temp is stable at about 45 degrees.
OrangePi3B and Radxa Rock 3C both have nvme slots and an spi which will allow boot from spi with system on NVME, and with Armbian, their 'armbian-config' setup can switch a system from fully sd card to spi/nvme or sdcard/nvme. The Zero3w doesn't have this option, so it would need to be done manually with the edid settings, and of course you'd be limited to USB3.0 bottlenecks with NVME-to-USB.
Opi3B on NVME goes from power-on to loaded in 30 seconds, with another 10-15 before wirless Android Auto connects.
The last piece of the puzzle was in fact AA naviation -- "Searching For GPS" pretty much never went away. with the GSPD setting set to "none" AA would struggle to start, struggle to find or severely lag in directions to an unusable level. I use AA in my work truck and used it on my OpenAutoPro setup fine, so I know it's not
the phone. After reading through the forum for solutions I ended getting the "VK-162 USB GPS Dongle - Remote Mount USB - External GPS Navigation Dongle" from Amazon (mentioned in viewtopic.php?p=1065#p1065).
I'm finding -- and to be clear, I'm just kind of assuming this issue might be specific to these boards as I've done no road-testing with on rpi -- that you have to give google maps full location permissions while denying the android auto app of all location permissions, with Hudiy config set to use GSPD. Navigation works mostly correctly (speed monitoring). If you're navigating and change paths it might take a second to catch up or get lost here and there, but overall it's a great improvement to how things were without the dongle.
I'll be happy to share the scripts (Claude co-writes), but I have notes everywhere and want to make sure what I share is as complete as possible. It's basicaly a script to set the enviroment up, another to set up the networking (assumes 2 wifi devices), and then install hudiy and modify the hudiy_startup script for the environment. I've been running RTLSDR v4 setup after HUDIY setup, but I have observed it mostly works out out of the box.
I will need to retest the vendor kernel for this board later; my focus shifted toward giving it a shot on Armbian current kernel since it now has the GPU support that was lacking when the board was introduced. I still have my working copy on armbian vendor kernel backed up for the time being.
The possible benefit to vendor kernel would be that the pi cameras v1 and v2 could theoretically be used for the backup camera source on vendor, but the mainline support just isn't there yet outside of the proper rpi realm. On vendor kernel, a custom ffmpeg can be compiled to support the use of the camera via v4l2, but for current kernel USB or netwok cameras would be the way to go with the least amount of headache.
I've expanded my testing to the OrangePi 3B, and will be getting a Radxa Rock 3C later this week -- Both boards use the same processor as the Radxa Zero3W and have the same GPU. TBH I'd kind of forgotten about the OrangePi board because there were some issues around board version numbers and kernel changes that would cause on-board ethernet to fail unless it was speed-limited, and intermittent issues with the bluetooth/wifi not working or not surviving reboot, so it's kind of been a paperweight for a bit, to the point that during my testing I realized I have an 8GB version.
My hope is the Radxa 3B will ultimatel be the most stable of the bunch -- not that the zero3w isn't, but the issues with the usb3.0 cable orientation is a bit frustrating. although the obvious advange would be board size.
Testing with Orange Pi 3B - I have a full working Hudiy 2.20
I'm using the same setup scripts I used on legacy kernel with current kernel -- Armbian only offers current kernel images for this board. As I mentioned before, I have a basic lawbc / wayland desktop which is installed on top of Armbian's debian trixie cli image.
Because of the issues with Opi 3B I decided the best best would be to use both an external Blutooth ada+pter and an external wifi adapter via USB. The bluetooth adapter is used all around instead of the on-board, while the USB wifi is configured as the hotspot for HUDIY. Onboard wifi is configured for my home network and phone hotspot -- both of these are configured in NetworkManager; with the hudiy main config hotspot settings matching the hotspot conf, HUDIY uses the USB wifi to communicate with the phone. This also allows me to ssh /vnc (via wayvnc) into the board to watch btop/htop/etc while the HUDIY is running.
The main benefit of the external wifi - When I was trying to actually road test this setup, the audio would stutter soemthing awful when the hotspot created with the on-board adapter, specifically when Android Auto was running. Using the external wifi elimated that issue.
We're still using around a half-gig of ram when things are running full-tilt. On the Zero3W 1GB of course the cache is a factor but it still runs smoothly. 8GB might be overkill for this setup overall (except sometimes, as they say) but this is the most love I've given Orange Pi so that's something.
On both of these, with heatsinks and active cooling the tempeature really never gets above 50. CPUs are working hardest when Android Auto is active and FM radio is playing, and they average about 50% at that point. for AA the setting I'm using are 720p / 30 fps. 1080p crashes it. 720 /60 fps works, with CPU popping up to 55-65. With 720/60 AA displayed while fm radio is playing the CPU are jumping up into 70-90% territory but temp is stable at about 45 degrees.
OrangePi3B and Radxa Rock 3C both have nvme slots and an spi which will allow boot from spi with system on NVME, and with Armbian, their 'armbian-config' setup can switch a system from fully sd card to spi/nvme or sdcard/nvme. The Zero3w doesn't have this option, so it would need to be done manually with the edid settings, and of course you'd be limited to USB3.0 bottlenecks with NVME-to-USB.
Opi3B on NVME goes from power-on to loaded in 30 seconds, with another 10-15 before wirless Android Auto connects.
The last piece of the puzzle was in fact AA naviation -- "Searching For GPS" pretty much never went away. with the GSPD setting set to "none" AA would struggle to start, struggle to find or severely lag in directions to an unusable level. I use AA in my work truck and used it on my OpenAutoPro setup fine, so I know it's not
the phone. After reading through the forum for solutions I ended getting the "VK-162 USB GPS Dongle - Remote Mount USB - External GPS Navigation Dongle" from Amazon (mentioned in viewtopic.php?p=1065#p1065).
I'm finding -- and to be clear, I'm just kind of assuming this issue might be specific to these boards as I've done no road-testing with on rpi -- that you have to give google maps full location permissions while denying the android auto app of all location permissions, with Hudiy config set to use GSPD. Navigation works mostly correctly (speed monitoring). If you're navigating and change paths it might take a second to catch up or get lost here and there, but overall it's a great improvement to how things were without the dongle.
I'll be happy to share the scripts (Claude co-writes), but I have notes everywhere and want to make sure what I share is as complete as possible. It's basicaly a script to set the enviroment up, another to set up the networking (assumes 2 wifi devices), and then install hudiy and modify the hudiy_startup script for the environment. I've been running RTLSDR v4 setup after HUDIY setup, but I have observed it mostly works out out of the box.