ArduinoMania

If you’ve ever built a robot with ROS 2, you know the classic architectural split: a powerful computer running Linux handles high-level navigation, mapping, and planning, while an external microcontroller handles the deterministic, real-time job of toggling GPIOs, reading sensors, and driving motors. 

Getting those two worlds to talk to each other usually means wrestling with custom serial protocols, dedicated drivers, or heavy middleware wrappers. The Arduino® VENTUNO Q board was designed to make that boundary disappear.

Because VENTUNO Q is structured to combine a Linux-capable MPU and a real-time microcontroller on the exact same board, you get a true dual-brain architecture. A few weeks ago at ROSCon Global 2026 in Toronto, and again on November 3rd live at ROScon Italy, Giovanni Bruno from our R&D team shared a new open-source tool built specifically to connect those two brains to ROS 2: the Arduino_RouterBridge_ROS library. 

Here is a look at how it works and how you can start using it in your next robotics build.

How it works: under the hood of Arduino RouterBridge

To understand how Arduino_RouterBridge_ROS operates, we first have to look at Arduino_RouterBridge. 

At its core, Arduino_RouterBridge uses an RPC (Remote Procedure Call) protocol built on top of MsgPackRPC. It lets the Linux side (running Python) and the real-time microcontroller side (running a Zephyr-based Arduino sketch) execute code on each other using two straightforward methods: 

• Bridge.provide() to register a callable function on one side. 
• Bridge.call() to trigger that function from the other side.

Instead of writing custom serial parsing code, you simply call functions across the MPU and MCU boundary as if they were running in the same thread.

Bringing ROS 2 nodes directly into your Arduino sketch

Building on top of Arduino_RouterBridge, the new Arduino_RouterBridge_ROS library introduces a lightweight ROS 2 proxy that bridges microcontroller firmware directly to your ROS graph. 

Using the familiar ros2ino namespace, you can write ROS 2 nodes directly inside your Arduino sketch: 

• Full node capabilities: Instantiate ROS 2 nodes, publishers, subscribers, services, and actions right from the MCU. 
• RMW agnostic: Because it relies on the lightweight RouterBridge transport, it works independently of whichever ROS Middleware (RMW) vendor you run on Linux. 
• Native C++ interface: The API syntax mirrors standard ROS 2 C++ (rclcpp) patterns, keeping the learning curve virtually flat. 

Now, your real-time microcontroller code can interact directly with ROS 2 without requiring you to set up additional bridge nodes, helping simplify development for robotics applications. For example, you can stream IMU telemetry straight into a /imu/data topic or listen to motor velocity commands on /cmd_vel.

Ready to build your next robot?

Are you engineering an autonomous mobile rover, designing a precision robotic arm, or wiring up your very first ROS-powered creation? Strip away the old serial communication headaches and focus on what matters most: building smart, capable machines.

Head over to our documentation to explore the new guides, including Getting Started with ROS 2 on UNO Q and First ROS 2 Project on UNO Q. Grab your VENTUNO Q, check out the repository, and show us what you build!

^{Giovanni Bruno, Robotics and Solutions Architect, presented VENTUNO Q, ROS 2, and the huge potential of Arduino ROS Bridge at ROSCON Italia.}

The post Unveiled at ROSCon: the easiest way to bring Arduino I/O into ROS 2 appeared first on Arduino Blog.

As global adoption of solar energy continues to accelerate, researchers and engineers face a fundamental spatial challenge: how do you generate more electricity without consuming more land?

Cosimo Borrello and Ferdinando Gioia – co-founders of the Italian photovoltaic technology startup A.M.P.S. – together with a team of researchers from the “Mediterranea” University of Reggio Calabria developed and field-tested a dynamic double-layer photovoltaic prototype designed to maximize solar power output per square meter of ground area. 

The challenge: overcoming land constraints

Conventional single-layer solar farms require significant spacing between rows to avoid mutual shading during solar tracking. While tracking raises energy yields per module, the extra space reduces overall energy production per unit of land. 

To solve this, the innovators at A.M.P.S. and the university stacked two vertically aligned layers of bifacial solar mini-modules within the exact same ground footprint as a single-layer setup. Rather than accepting the inevitable shadows cast by the top layer onto the bottom layer, the team implemented independent solar tracking for the stacked panels. By dynamically controlling panel rotation, the system is built to actively manages mutual shading while harvesting direct, diffuse, and reflected sunlight across both active surfaces. 

The brain behind the setup: GIGA R1 WiFi

At the core of the experimental testbed in Reggio Calabria, Italy, is a GIGA R1 WiFi. Installed on a custom-designed control PCB, it acts as the central embedded manager for the entire installation: 

• Automated motion control: It is structured to coordinate twelve Nema23 stepper motors via dedicated DM542T drivers to independently adjust the rotation angles of twelve bifacial mini-modules across both layers. 
• Independent current sensing: It is engineered to acquire real-time current measurements from twelve INA260 sensors attached to each module to track energy performance. 
• Remote data logging: It is constructed to process the synchronized current sweeps and uploads the experimental data directly to a remote server for analysis. 

“We chose the GIGA R1 WiFi because it brings together everything a prototype like ours needs, with lots of I/O, a fast dual-core microcontroller and built-in Wi-Fi on a single board,” Cosimo told us. “We had to drive twelve stepper motors independently, read twelve limit switches and twelve current sensors, and send the data to a remote server, and very few boards can handle all of that on their own. Having used an Arduino Mega board in many past projects, GIGA R1 was the natural next step, with the same familiar format and far more power and connectivity. It gave us a reliable control platform quickly, so we could focus on the photovoltaic research rather than on the electronics.”

Real-world results and future applications

In field testing under clear-sky conditions, with the top layer tracking the sun and the bottom layer fixed, the researchers reported the following increases in short-circuit current, a test measurement that is not the same as total energy production, compared with a fixed single-layer installation occupying the same ground area:

• About +42% relative to a monofacial single-layer installation.
• About +27% relative to a bifacial single-layer installation.
• About +39% and +25% respectively with a simplified open-loop tracking model based on a five-parameter sigmoid function, which the researchers reported were close to the results obtained using closed-loop control.

The researchers identify potential applications ranging from compact rooftop modules for space-constrained urban environments to utility-scale plants and agrivoltaics. In agricultural settings, the dynamic rotation of both layers may also allow operators to adjust the amount of natural sunlight reaching crops, although these applications were not evaluated in the reported field test.

By serving as a reliable control platform, GIGA R1 WiFi helped enable the team to move rapidly from concept to field validation – demonstrating how accessible open-source hardware can support advanced research in clean energy and land-use efficiency. 

Want to explore the mathematical models, control algorithms, and complete test data? Read the coverage on PV Magazine or dive into the full published paper in Renewable Energy.

Arduino, Arduino Mega, GIGA R1 are trademarks or registered trademarks of Arduino S.r.l.

The post Doubling down on solar power density with the Arduino® GIGA R1™ WiFi board appeared first on Arduino Blog.

The Smart Mirror turns a mirror into a style consultant. With a tap on Scan your look, a USB camera frames the garment being worn and the system recognises its colour and type, then suggests how to complete the outfit. The example runs on the Arduino VENTUNO Q board and shows how local visual AI can become part of a context-aware retail experience. Here the inference happens on the board, not on a remote server: images never leave the device, so privacy and latency stay under control.

The flow is linear and reads well from start to finish. A USB camera provides a live video stream, and the most recent frame is saved into a shared buffer. When Scan your look is tapped, the last frame is analysed locally on the VENTUNO Q board by the Qwen3-VL model, accessible through the Arduino VLM Brick. The model identifies the main garment and its colour and returns two short sentences: a description of the outfit and a style suggestion.

Two App Lab Bricks and an MJPEG stream to the browser

The result is sent to the browser and shown over the live camera view. The browser displays the live feed through an MJPEG stream exposed by the backend. The application therefore uses two App Lab Bricks: the Vision Language Model Brick and the Web Interface Brick. The first handles frame analysis, the second the page and the stream. The prompt behaviour can also be customised through a single configuration file, prompt.py.

Arduino VENTUNO Q as the compute board

• USB camera for the live video stream
• Arduino VLM Brick to access the model
• Vision Language Model Brick for frame analysis
• Web Interface Brick for the page and MJPEG stream
• prompt.py to customise the prompt

Anyone who wants to rebuild the project will find the parts list here is fairly short overall. The VENTUNO Q board is the heart of the system, while the USB camera is the only sensor required. The Qwen3-VL model does not need training: it is used as it is, through the Arduino VLM Brick.

The physical assembly is not described in the example: the system relies on a USB camera connected to the VENTUNO Q board and on a backend that exposes the MJPEG stream. The rest, from the framing to the physical mirror, depends on how you want to build the mount. The software side, on the other hand, is all inside the two Bricks and the prompt.py file.

What changes with visual AI inference running locally

The interesting point is not the individual style suggestion, but where it is computed. The Qwen3-VL model runs on the VENTUNO Q board, so no image of the garment being worn is sent to a cloud service. As a result, latency stays low and privacy is simpler to guarantee: what the camera sees does not leave the mirror. The system also works without an internet connection, because inference is local.

The complete flow can be summed up like this: the camera produces the frames, the shared buffer holds the most recent one, the model analyses it on request and the browser shows the result over the live video. Every step stays on the board or on the local network, and the tap on Scan your look is the only trigger for the analysis. If you want to see how the project is built and which files it uses, the post on the Arduino blog is the place to start.

For those working in retail or in the maker world, this Smart Mirror is a concrete example of how local visual AI can power a complete, real-time user experience. No cloud is needed, no fast connection is needed, no images travelling outside the home are needed. A USB camera, a VENTUNO Q board and two well-chosen Bricks are enough.

Source: https://blog.arduino.cc/2026/09/23/making-retail-smarter-build-context-aware-experiences-with-the-arduino-ventuno-q-board/

The post Smart Mirror: local visual AI turns a mirror into a style consultant appeared first on Open Electronics.

• Read more about He Built a PC Hardware Monitor That Looks Like a Four-Gauge Aircraft Instrument Panel
• Add new comment

You have an idea. Maybe it’s a smart home device that solves an everyday annoyance, a robot you’ve been sketching for months, or an experiment that becomes something bigger. Now comes your first major decision: what hardware will you use to bring it to life?

With so many development boards available, choosing the right one isn’t always straightforward. But there’s more to the decision than specifications or price. The hardware is only the beginning. What truly makes a difference is the community and resources behind it.

And with the holiday season bringing discounts of up to 50% on selected Arduino^® boards, there’s an added incentive to explore what the original Arduino has to offer.

The original Arduino advantage is more than the hardware

An Arduino board may be small enough to fit in your hand, but what comes with it extends far beyond the hardware.  Choosing a genuine Arduino means having access to an ecosystem built to help you turn ideas into working projects. Official documentation, ready-to-use libraries, tutorials, projects, demos, and development tools take much of the guesswork out of the process — whether you’re writing your first lines of code or tackling a sophisticated prototype.

And let’s not forget about the community. Millions of makers, educators, and developers around the world share their knowledge, troubleshoot challenges, and inspire one another through projects that push the boundaries of innovation.

That’s the advantage of the original Arduino. You’re not just purchasing a board. You’re tapping into years of engineering expertise, trusted resources, and a global community that helps you make the best of it.

A board for every ambition — a few favorites to explore

How you bring your projects to life often depends on the tools you choose. Whether you’re experimenting with electronics, connecting devices, or developing a sophisticated prototype, Arduino has a board to match your ambitions. Here are six solid options for the makers, developers, and builders in your life.

Start building. Keep exploring

There’s a reason the Arduino^® UNO Rev3 board continues to be a favorite among makers and educators. Its reliability, approachable design, and extensive learning resources make it an excellent tool for exploring electronics, coding, and interactive projects. 

Ready for more processing power? The UNO R4 Minima brings 32-bit performance to the familiar UNO form factor, opening up new opportunities for experimentation.

Build your own retro-style MP3 player with the UNO R4 Minima, perfect for music lovers and makers.

Give your projects a smarter edge

Want to make your projects smarter and more connected? The UNO R4 WiFi combines 32-bit processing with WiFi and Bluetooth^® wireless connectivity, along with a 12×8 LED matrix, making it a compelling choice for connected devices, automation, and interactive builds. 

For projects where space matters, the compact Arduino^® Nano ESP32 board delivers wireless connectivity and support for MicroPython, giving developers plenty of flexibility for IoT applications.

Build a keypad password lock system with the UNO R4 WiFi, which replaces the physical key with a secure digital interface.

Think bigger. Build bolder

Some ideas demand more room to grow. With a generous selection of input/output pins, the Arduino^® Mega 2560 board is well suited for projects involving multiple sensors, motors and other components. 

And for developers tackling more computationally demanding applications, the Arduino^® GIGA R1 WiFi board brings dual-core processing, wireless connectivity, and advanced peripherals to the workbench.

Keep an eye on the ever changing cryptocurrency value on this cryptocurrency tracker with the GIGA R1 and GIGA Display Shield.

Six boards. Different strengths, and one shared purpose: give makers and developers the freedom to experiment, solve problems, and bring ambitious ideas to life.

Big ideas deserve great hardware. And a great deal!

Whether it’s your first experiment or you’re building more sophisticated prototypes, Arduino hardware opens the gates to all kinds of creative and innovative possibilities. And this holiday season, there’s an added reason to explore them. 

If you’ve been waiting to get started with Arduino, expand your collection, or tackle a project that’s been in the planning stages for a while, we’ve got the perfect incentive for you; selected hardware available at discounts up to 50% during our holiday promotion. So what will you build next?

Explore the holiday deals.

Arduino, UNO, Nano, Mega, and GIGA are trademarks or registered trademarks of Arduino S.r.l.

The post What will you build next? Arduino Black Friday deals are here appeared first on Arduino Blog.

• Read more about Stuff Made Here Built an Arduino-Run Car Wash for His Muddy Dog, and the Dog Said No
• Add new comment

• Read more about This 3D-Printed Robot Duck Learned to Walk With a Neural Network, and Now It Kicks a Ball
• Add new comment

• Read more about A $300 Robot That Plays Fetch: It Finds the Ball, Picks It Up and Brings It Back on Its Own
• Add new comment

XGO Duck is an open source, 3D-printable robot duck that Luwu Dynamics built starting from Pollen Robotics’ Microduck. From the original project it keeps the body, the layout of the 15 servos and the joint order, but replaces all of the electronics. In place of the Pollen Robotics board there is an Arduino UNO Q, which runs neural policies for walking, getting up from the ground and picking. So there is no need to wait for a commercial robot: anyone with a 3D printer can build one.

The heart of the system is the Arduino UNO Q itself, which hosts two computers on a single board. On one side there is a host with a Qualcomm processor running Linux, on the other an STM32U585 MCU running Zephyr. This division of tasks is the most interesting architectural choice in the project. The host handles the neural policies, the MCU handles real-time motor control. On top of that, the link between the two is a 2 Mbps Bridge, so the two worlds stay synchronised without Linux ever having to wait on the servo bus.

Two computers, two loops: 50 Hz for the policies and 100 Hz for the bus

The host runs the ONNX policies at 50 Hz on a dedicated thread, with the web UI listening on port 9527. The MCU, on the other hand, runs a 100 Hz bus loop and does not wait for Linux. It publishes a 240-byte duck_state snapshot at 100 Hz; the host filters every snapshot on arrival and the 50 Hz thread reads the latest available one, skipping late cycles. That way the robot does not stall if the host is busy.

The servo bus always addresses all 15 servos in the order ID 10-14, 20-24, 30-34. The order in action 14-D of the policy is instead 10-14, 30-33, 20-24. The servo bus is on Serial1 at 1 Mbps, while the QMI8658 IMU is on Wire at 400 kHz, with I2C address 0x6A then 0x6B. Servo positions are saturated to the encoder range 0-4095, with a raw centre position of 2047.

• 15 FeeTech 1910 servos on a serial bus
• Arduino UNO Q with Qualcomm host and STM32U585 MCU
• QMI8658 IMU on the Wire bus at 400 kHz
• Bridge host-MCU link at 2 Mbps
• servo bus on Serial1 at 1 Mbps

The neural policies: observation [1, 61], action [1, 14] and automatic get-up

The policies expect an observation [1, 61] and output an action [1, 14]. There are three: xgoduck_walk.onnx for walking, xgoduck_getup.onnx for getting up from the ground and xgoduck_pick.onnx for the pick, which lasts 4 s. A tilt above 55° for 0.15 s triggers the get-up model, then the action is forced to 0 for 1 s. When the tilt drops below 15° for 1 s, the robot goes back to walking.

The home pose has hip and ankle at ±24°, knee at 0°, hip roll at ±5°, neck and head pitch at 20°, mouth at 0°. The action_scale is 1. The walking commands are vx ±0.4, vy ±0.3 and ωz ±1.0, with a joystick dead zone of 0.1. The four head channels sit within ±1 radian. The mouth is driven from the web UI from 0° to 30°, and in the pick cycle it opens to 30° and closes when φ ≥ 0.4.

Action smoothing uses α = 0.45 on the slices [0:5], [5:10] and [10:14], yaw smoothing uses α = 0.5 and joint speed smoothing uses α = 0.4. The gravity complementary filter uses τ = 0.3 s, with accelerometer correction dropping when the norm deviates from 1 g by more than about 20%. Position control stops if commands are missing for 250 ms or if the IMU is missing for 100 ms; a host feedback older than 150 ms disarms it.

The Zephyr firmware, servo calibration and the web UI on port 9527

The firmware is a CLI app built with Arduino Zephyr core 1.0.0, on top of RouterBridge 0.4.3, RPClite 0.3.1 and MsgPack 0.4.2. A patch to RouterBridge 0.4.3 raises the RPC thread stack from 500 to 4096 bytes, and the serial router is set to 2 Mbps. Calibration and servo setup use a 2 s heartbeat. The temporary gains for the centring movement are KP = 6 and KD = 20, with a temporary KP = 10 for the servo with ID 34. During calibration the gains become KP = 3 and KD = 0, and every servo is commanded to 2047.

The servo setup page starts with default values KP = 5 and KD = 20. Writing the ID unlocks register 0x37 and then writes 0x05; writing KP/KD unlocks 0x37 and stores both bytes at 0x15. The duck_command sent by the host is 80 bytes. Closing the page or leaving it in the background for more than 1 s disables position control, so the web UI is not just a convenience panel.

The Luwu Dynamics repository collects the project code: sketch, configurations, ONNX models and support scripts. Among the tools are tools/prepare-bridge.py, tools/router-2m.sh, tools/reuse-toolchain.py, tools/verify-elf.py and tools/measure.py, which measures for 60 seconds. There are also python/rl_core.py, python/requirements.txt, sketch/sketch.yaml, app.yaml, data/zero_pos.json and sketch/duck_config.h. Anyone who wants to rebuild it will find everything needed to get started there.

The host needs a Linux environment with ONNX Runtime and Python, while the MCU runs on Zephyr. The UNO Q loader error in case of a tail-call is ENOEXEC (−8), a detail familiar to anyone who compiles firmware. The default rate of Bridge.begin() in another app is 115200, so it has to be raised to 2 Mbps to run the bus as needed. If you want to start with the right hardware, an Arduino UNO Q with a complete accessory kit covers the host and MCU side on a single board.

Source: https://github.com/LuwuDynamics/xgoduck_runtime_arduino

Related products

• Arduino UNO Q 4GB – Complete kit with accessories

The post XGO Duck: the open source robot duck that walks with neural policies appeared first on Open Electronics.

Driving a 6-colour e-paper display is not like driving a monochrome panel. Seeed Studio’s reTerminal E1002 carries a 7.3-inch ACeP with 800×480 resolution, and a XIAO ESP32-S3 runs underneath it. Mariusz Jurgielewicz has put together a set of Arduino examples tested on exactly this combination, so newcomers don’t have to reinvent pinout, polarity and refresh sequences.

The practical value of the collection lies in the details the official drivers don’t tell you. The GDEP073E01 panel uses the ED2208 controller and is wired to the carrier through an internal FPC. So the pins are not the ones you’d expect from a breakout module: SCK is on GPIO 7, MOSI on GPIO 9, CS on GPIO 10, DC on GPIO 11, RST on GPIO 12 and BUSY on GPIO 13. Logging is also duplicated across two serials, Serial1 on GPIO 43 and GPIO 44 through the USB-UART bridge, plus the XIAO ESP32-S3’s native USB CDC Serial.

BUSY active-low and SPI clock at 2 MHz

Trap number one is the BUSY polarity. On the ED2208 the signal is active-low: 0 means refresh in progress, 1 means ready. Inverting it locks up the driver or corrupts subsequent writes, and the symptom isn’t a clear error but a panel that stays half-drawn.

The second trap is the clock. The SPI bus runs reliably at 2 MHz, and this also applies to the upload speed set in the Arduino IDE, fixed at 115200. The log serial runs at 115200 baud. Higher frequencies on the internal flex risk clock distortion, with pixel dropouts or corrupted command bytes. Finally there’s the watchdog: during a cold refresh the 40-second timeout can fire, so the sequence has to be handled accordingly.

• SCK on GPIO 7, MOSI on GPIO 9, CS on GPIO 10
• DC on GPIO 11, RST on GPIO 12, BUSY on GPIO 13
• BUSY active-low: 0 refresh in progress, 1 ready
• Reliable SPI clock at 2 MHz
• Serial1 on GPIO 43 (TX) and GPIO 44 (RX), plus native USB CDC
• 192,000 bytes of frame buffer in OPI PSRAM

A full frame buffer of 800×480 pixels at 4 bits per pixel, two pixels per byte, requires 192,000 bytes. It doesn’t fit in the ESP32-S3’s internal RAM, so it has to be buffered in OPI PSRAM. The panel exposes 6 native solid colour fields: black, white, red, green, blue and yellow. So each pixel is not a grey value but a colour index, and dithering has to be planned accordingly.

On the software side the collection covers three driver stacks. The first is Jean-Marc Zingg’s GxEPD2, the upstream one you get from the Library Manager. The second is the Good Display vendor driver. The third is Waveshare’s GUI_Paint graphics framework, sitting on top of Adafruit_GFX. Watch out for one detail: the Seeed_GxEPD2 fork should not be installed, because it conflicts with the upstream GxEPD2.

Besides the display, the examples cover the carrier board’s onboard peripherals. There’s the PCF8563 real time clock and the SHT4x environmental sensor, so a complete project can show the time plus temperature and humidity data without adding external modules. Anyone who wants to rebuild everything from scratch will find Mariusz Jurgielewicz’s repository with the sketches ready to upload.

To work on it you need the Arduino IDE with XIAO ESP32-S3 support, the GxEPD2 library from the Library Manager, and the panel connected to the carrier.

Source: https://github.com/melastmohican/reTerminal-E1002-arduino-examples

The post Arduino examples for the 6-colour e-paper display on the reTerminal E1002 appeared first on Open Electronics.