H, I’m thinking of purchasing a galaxy rvr. As far as I understand, it comes with an arduino r3 compatible controller.
As far as I can see from the arduino R4 specifications, the R4 is compatible with R3 hats. I therefore wondered if I could swap the included r3 with an r4?
I’d like to write a dumb ros node into the r4, then use a 2nd computer to do the hard lifting to make the rvr do more complex stuff.
I can see no way to add micro ros to an r3, but it seems possible with an r4.
I don’t expect anyone to have necessarily tried this, but I’d just like to know if anyone can spot any glaring obstacles?
We haven’t tried this approach, but your idea is excellent.
The Arduino R4 is compatible with the R3 in terms of pins, power supply, and interfaces, allowing it to physically replace the R3 controller in the Galaxy RVR.
However, please check whether the raised pins on the R4 might come into contact with the rover expansion board when connected. It’s important to prevent any potential short circuits.
The core tasks involve migrating the RVR control code and configuring Micro ROS, which is natively supported by the R4.
Thank you, even without micro ros, the R4 should allow me to do more than the R3. I’ll purchase an R4 and have a play around, then maybe grab an rvr later if i get confidence in the R4. Again thanks for the reply.
I only have a rpi400 as my main desktop. Only v1.8.x of the arduino ide, will run on this, not the newer v2.x variants. Unfortunately v1.8.x is slow and awkward to run on the 400, and I cant afford a PC or MAC just for this trial. There is a 3rd party v2.2.1 for arm64 out there, but it did not run for me, simply freezing on startup.
Arduino IDE v1.8.x is a desktop application developed based on Java Swing. Java Swing has inherent hardware overhead and is poorly optimized for the arm64 architecture. The Raspberry Pi 400’s CPU performance (BCM2711, 4-core Cortex-A72) is limited, and the Java Runtime Environment (JRE) runs less efficiently on the arm64 platform. Combined with the rendering overhead of the Swing interface, this results in sluggish operation and slow response times.
The official Arduino IDE v2.x has been rebuilt using Electron + TypeScript, which introduces more complex runtime dependencies (requiring a full Electron runtime, Node.js environment, and specific system libraries). Third-party ports often only perform a simple architectural compilation without completing dependencies, optimizing performance, or fixing bugs for the Raspberry Pi 400’s system (likely Raspberry Pi OS). Common causes of freezing include:
Missing key arm64 system dependency libraries (such as libxcb, libnss, etc., required by Electron).
Memory leaks or permission issues not resolved during the porting process.
Compatibility conflicts with Raspberry Pi OS’s desktop environment (LXDE/LXQt).
Lack of adaptation to the Raspberry Pi 400’s graphics driver, causing interface rendering to freeze.
It is recommended to close unnecessary background processes and desktop visual effects to see if this improves lag and other issues. However, we still advise using a PC as the main host for development.
Thank you for spending the time on this detailed explanation. Coupled with analysing my error messages somewhat more carefully this time! I now have arduino ide 2.2.x running perfectly on my rpi4 Bookworm, far better than 1.8.x ide
