Posts with «robotics and drones» label

Nuvi: an Arduino UNO Q Desktop Companion

Nuvi is a small, expressive desktop companion, less than 30 cm tall. It wakes up when someone comes close, answers when it is called by name and holds a conversation with the user. It also searches the web, controls smart home devices by voice or with a hand gesture, and reads the room’s temperature and humidity. It was designed by Luca Di Lorenzo, and the board that brings it to life is the Arduino UNO Q.

What stands out is not the conversation itself, but where it runs. The Linux side of the UNO Q runs the artificial intelligence pipeline, the voice engine and the application logic, all on the board itself rather than on a connected PC. So Nuvi is self-contained: you switch it on and it is there.

Two souls on one board: microcontroller and Linux

Arduino UNO Q splits the work in two. The real-time microcontroller side handles the physical control: four servos for the arms and ears, two serial servos for the neck, the display, the sensors and the touch inputs. The Linux side, on the other hand, takes care of the heavy part, that is the artificial intelligence and the voice.

This separation makes practical sense. Movements have to respond immediately, without waiting, and that is why they live on the microcontroller. The conversation can take a few moments longer, so it lives on the processor running Linux. As a result, the arms, ears and head move smoothly while the brain works out the sentence.

  • Four servos for the arms and ears
  • Two serial servos for neck rotation and tilt
  • Display for the animated eyes
  • Temperature and humidity sensors
  • Touch inputs on the head and belly

Gemini to understand, Piper to speak without the cloud

The conversation is based on Gemini, which handles both speech understanding and response generation in a single pass. There is therefore no separate speech-to-text stage: the model does everything at once, and the pipeline stays leaner.

For the outgoing voice, on the other hand, Nuvi uses Piper, a voice engine that runs entirely on the board. So the synthesis does not go through the cloud: the sentence is spoken locally. In particular, it is this choice that makes the robot usable even when the network is poor, at least for the sound side of things.

The animated eyes express different moods. The ears and arms move, the head rotates and tilts, and touching the head and belly triggers a reaction. Finally, purely for fun, there is also a little dance.

What you need to rebuild it: 3D files, electronics and code

Anyone who wants to build a Nuvi starts from the Arduino UNO Q, the heart of the project. The complete kit with accessories includes the board and what you need to start working with it. To drive traditional three-pin RC servos, with power, ground and PWM signal, you then need a dedicated driver stage.

On the sensor side, Nuvi reads the room’s temperature and humidity. Nuvi uses a Modulino Thermo module for the room’s temperature and humidity, while two Modulino Distance modules take care of noticing who is approaching.

The rest is assembly: 3D printing for the body, wiring the servos, connecting the display and the touch inputs. Luca Di Lorenzo’s video shows the project in action, and from it you can see how much work lies behind every single gesture Nuvi makes.

The most interesting part remains the amount of personality you can put into a project based on the UNO Q. 3D files, electronics, code and a step-by-step tutorial are available for anyone who wants to build one. And the result, under 30 cm tall, sits comfortably on a desk.

Source: https://projecthub.arduino.cc/lucadilo/nuvi-ai-desk-companion-bdd30c

The post Nuvi: an Arduino UNO Q Desktop Companion appeared first on Open Electronics.

XGO Duck: the open source robot duck that walks with neural policies

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

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

JBR-001: the open source desktop robot that recognizes objects

JBR-001 is an open source desktop robot that sees and recognizes the objects in front of it, then reacts with movements, sounds and animations. It was created by syntheticAIdata and built around the Arduino UNO Q 2GB. Inside there are three servos, a camera, a distance sensor, a buzzer and an animated display. So it is not yet another blinking ornament: it is a platform for experimenting with robotics, computer vision and edge AI on a workbench.

Assembly starts from a body of 3D-printable parts that house the board and the rest of the electronics. The head contains the camera, mounted so that it looks straight ahead of the robot. On the back of the same head sits a Modulino Distance, which continuously measures the distance to nearby objects. The arms and the rotation of the head, on the other hand, come from three servos. The mechanics are therefore easy to replicate for anyone who already has a 3D printer at home.

Overview of the hardware project

Servo pins and distance thresholds in the code

The three servos split the tasks: one rotates the head, the other two control the arms. In the code the pins are HEAD_SERVO_PIN = 9, LEFT_ARM_SERVO_PIN = 10 and RIGHT_ARM_SERVO_PIN = 11. The rest positions are all at 90 degrees, so HEAD_CENTER = 90, LEFT_ARM_CENTER = 90 and RIGHT_ARM_CENTER = 90. The servos also use a separate external power supply instead of drawing power from the UNO Q: a forced choice when three motors start at the same time.

The distance sensor decides when the robot should notice someone. In the code the detection threshold is DETECTION_DISTANCE = 200.0, while the reset one is RESET_DISTANCE = 250.0. The units are not specified in the project material, so they should be checked on the bench before trusting them. The margin between the two thresholds prevents the robot from switching on and off continuously when someone stays right on the boundary.

Heartbeat on the display, a greeting in notes and the vision model

The robot’s responses go through three different channels. The LED matrix display is driven with bitmaps of 8 rows by 13 columns, the two used for the small and large heart. In the heartbeat animation the delays are 120, 100, 160 and 700 milliseconds, and the last long gap gives the sense of the pause between one beat and the next. The sound greeting playHello instead uses the notes 523 Hz (C5), 659 Hz (E5), 784 Hz (G5) and 1047 Hz (C6), that is a C major arpeggio rising by one octave.

The most interesting part comes from the camera mounted in the head. It connects through a USB-C hub and gives the robot a front view of its surroundings. The captured images can be processed on the UNO Q with a trained computer vision model: this way JBR-001 does not just understand that something is nearby, but identifies the object and uses the result to decide how to react. Consequently the same hardware can turn its head, move its arms, change the image on the display or play a short sequence.

  • Arduino UNO Q 2GB as the robot’s brain
  • Modulino Distance for continuous distance measurement
  • Modulino Motors for motion control
  • Modulino Buzzer for sound sequences
  • Arduino USB-C Hub (8 in 1) to connect the camera
  • Three servos for head and arms
  • Camera mounted in the head
  • 3D printer for the body parts

On the software side you need Arduino App Lab and the JBR-001 source code, plus a trained computer vision model for object recognition. The project has 1805 views and 2 respects. Anyone who wants to rebuild it starts here: the maker syntheticAIdata’s site, where the code and the instructions to replicate the build are. For the servos, an RC servo control module simplifies the wiring when the channels to drive grow. The project’s distance sensor is a Modulino, and as an alternative you can consider a ToF laser sensor for close-range measurement. The board everything runs on is the 2GB version, while the catalogue also lists the Arduino UNO Q 4GB in a complete kit: same family, more memory for vision models.

Source: https://projecthub.arduino.cc/syntheticaidata/jbr-001-a-desktop-companion-robot-powered-by-arduino-uno-q-b11c96

Related products

The post JBR-001: the open source desktop robot that recognizes objects appeared first on Open Electronics.

3D-Printed Tactile Zoo: Young Makers Show Off Their Mistakes

A group of children aged 7 to 13 is building a tactile zoo with 3D-printed robotic animals. The creatures, more than 20 in total, are equipped with LEDs, motors, buttons, and gears. At Maker Faire Bay Area, the group will also display their printing errors and failed prototypes. The goal is to show the iteration process that leads from an idea to a working object.

The project turns 3D printing into an educational and interactive activity. Mistakes are not hidden but become an integral part of the exhibition. Visitors can thus understand that making errors is a normal step in the work, not a failure. The maker’s website details how the children faced technical difficulties and what solutions they found.

From choosing the animal to the first print

Each young maker chooses an animal, real, mythological, or completely invented. Then they decide what behavior the creature should have. Some design the animals from scratch, others start from existing 3D models and modify them, cutting or redesigning sections to make room for the electronics. Once the body is ready, they add a function such as an LED, a servo, a motor, a button, or a set of gears.

The group includes eight creatures, among them Em. To make Plate the Armadillo roll into a ball, 11 prints were needed. Each failed attempt taught something new: a joint too tight, a motor off-axis, a wall too thin. The children learned to observe the error and correct it in the next print.

An exhibition you can touch and open

The zoo is not a simple showcase. Visitors can press buttons, flip switches, and open the animals to see the wires, gears, and electronics inside. This choice makes the electronics transparent and understandable even to those who have never opened a device. Next to the finished animals, broken prints, melted parts, and earlier versions are displayed, so visitors can ask what went wrong and how it was fixed.

For those who want to recreate the project, the electronic part can be built with simple, modular components. For example, a servo motor with metal gears can move an animal’s legs, while a shield for controlling RC servos allows managing multiple movements with an Arduino board. For light effects, a WS2812 LED matrix offers endless color possibilities. Finally, a compact board like the Arduino Nano Matter can handle logic and connectivity in a small space.

Mistakes on display: the educational value of failure

The choice to display printing errors is the heart of the project. In a world that shows only perfect results, these children reveal the behind-the-scenes. The broken prints tell the real difficulties of 3D printing: material shrinkage, parts detaching from the bed, motors that don’t find space. Visitors to Maker Faire will be able to talk with the young makers and discover how each problem was tackled.

This approach also changes the way the children work. They learn that a failed prototype is not wasted time, but a step forward. Each error provides valuable information for the next version. The iteration process thus becomes a mental habit, useful not only in 3D printing but in every design activity.

Source: https://view.protectedpdf.com/portal/AMR/LogIn

Related products

The post 3D-Printed Tactile Zoo: Young Makers Show Off Their Mistakes appeared first on Open Electronics.

SO-101 Robot Arm Meets Arduino VENTUNO Q: Local-AI Pick-and-Place

An SO-101 robot arm, originally a desktop toy, now picks and places rubber ducks by reasoning with a vision-language-action model. Dmitry Maslov’s project swaps the original brain for an Arduino VENTUNO Q board, which runs Hugging Face’s SmolVLA model locally. The result shows that robotics tasks combining vision and language, once confined to costly labs, now fit on a 299-dollar board.

Hardware: two processors on one board

The Arduino VENTUNO Q board has a dual nature. On one side sits an SBC system with a Qualcomm Dragonwing IQ8 processor, equipped with an Adreno 623 GPU and a Hexagon Tensor NPU, built for AI processing. On the other side is an STM32H5F5 microcontroller with an Arm Cortex-M33 core running at 250 MHz, which handles real-time servo control. The board offers 16 GB of LPDDR5 RAM and 64 GB of integrated eMMC storage.

The original SO-101 arm carries gearmotors on every joint and two cameras: one fixed overhead and one on the gripper. The images and joint position data go to the Dragonwing IQ8 processor, where the SmolVLA model interprets them. The model was trained with 50 demonstrations of the task of grabbing and moving the rubber ducks.

The SmolVLA model and the system’s numbers

SmolVLA is an open source vision-language-action model from Hugging Face. It processes the camera images and joint data, then produces the commands for the servo motors. All the processing happens locally on the VENTUNO Q board, with no connection to external services. The board costs 299 dollars, against 399 dollars for the Jetson Orin Nano Super Developer Kit, cited as a competitor.

Dmitry Maslov’s system points the way to accessible robotics. What’s more, the fact that the model runs on a commercial board costing less than 300 dollars opens up new scenarios for makers. For anyone who wants to see the project in action, Dmitry Maslov’s video shows the arm grabbing and moving the rubber ducks.

  • Arduino VENTUNO Q board with Qualcomm Dragonwing IQ8 processor and STM32H5F5
  • Hugging Face SmolVLA model running locally
  • 50 demonstrations to train the pick-and-place task
  • Two cameras: one overhead and one on the gripper
  • 16 GB of LPDDR5 RAM and 64 GB of eMMC storage

For anyone wanting to rebuild the project, the trickiest part is the integration between the SBC side and the microcontroller side of the board. The Dragonwing IQ8 processor runs the model, while the STM32H5F5 controls the servos. Communication between the two sides is essential to synchronise vision with movement.

Source: https://youtu.be/T0frBNASr3M?si=Wf1VPI8SoJ6tr18p

The post SO-101 Robot Arm Meets Arduino VENTUNO Q: Local-AI Pick-and-Place appeared first on Open Electronics.

Face-tracking robot with Arduino UNO Q

An inexpensive robot kit with Arduino UNO Rev3, obstacle-avoidance sensors, and line-following capability becomes a face-tracking robot. The trick is in the control board: just replace the UNO Rev3 with an Arduino UNO Q, which has the same headers and mounts an STM32U585 microcontroller alongside a Linux microprocessor. Iulia Feroli’s project shows how local artificial intelligence can be added to a low-cost robot without touching the mechanics.

The robot starts from the Elegoo kit, with its motor shield and sensors for obstacle avoidance and line following. The UNO Q slots in place of the original board, and the shield moves over without any modification. Thanks to the STM32 microcontroller and the Linux microprocessor, the new board runs machine learning models locally, with no cloud connection. A standard USB webcam is connected to the UNO Q to provide vision.

Video stream and face tracking

The webcam video stream is processed with the face tracking Brick from Arduino App Lab. The code converts the face position in the frame into movement commands for the robot. The robot rotates to center the face and moves toward it, always staying in front of the person. The result is a responsive face tracker that requires no external servers or Wi-Fi connections.

Iulia Feroli’s project is documented in a video showing the robot in action, with an explanation of the assembly and the code. Swapping the board is the core of the intervention: the UNO Q maintains electrical and mechanical compatibility with the UNO Rev3 but adds the computing power needed for AI. In addition, the face tracking Brick in Arduino App Lab simplifies managing the machine learning model, making the code accessible even to those without neural network experience.

What you need to rebuild the project

To replicate the robot you need only a few components, all easily available. The list includes the Elegoo kit, a USB webcam, and the control board. Here are the main steps:

  • Remove the Arduino UNO Rev3 from the Elegoo kit and keep the motor shield.
  • Mount the Arduino UNO Q in its place, checking that the headers align.
  • Connect the USB webcam to the UNO Q port.
  • Upload the sketch with the face tracking Brick from Arduino App Lab.
  • Power the robot and test it in front of a face.

The UNO Q is the heart of the system: it combines the simplicity of the STM32U585 microcontroller with the power of the Linux processor. This combination allows local machine learning models, such as face tracking, to run without additional hardware. The board is also available in a 4GB version with a full accessory kit, which includes everything needed to get started.

The original Elegoo kit, with its Arduino UNO Rev3 board, remains an excellent base for other projects. However, for this face tracker, the UNO Q is the right choice: it offers the necessary computing power and maintains compatibility with the shield. The overall cost stays low, and the result is a smart robot that impresses with its responsiveness.

Source: https://youtu.be/FIu14vCvGfs?si=8SSW0K6O7J6Y07tz

The post Face-tracking robot with Arduino UNO Q appeared first on Open Electronics.