4. Quac – All Terrain Crawler
QUAC (QUad-wheel All-terrain Crawler) is a compact and robust four-wheel rescue robot designed for rough terrain and autonomous operations in the RoboCup RMRC league.
QUAC is meant to be maintainable for students with ease: mechanics, electronics and software can be accessed and modified easily and quickly, making it ideal for experimenting with new drive concepts, sensor setups and autonomous navigation strategies.
With this robot, we will participate RoboCup 2026 Incheon. However, the robot is still under development, so further changes may be made.
We started working on this robot to participate in the RMRC League of the 2026 Robocup in Incheon, South Korea. The obstacle courses include the following challenges
- driving through and over the terrain (obviously)
- gripping and moving certain elements
- pressing buttons
- creating a map of the area
- scanning qrcodes
- detecting sources of heat
- detecting sources of magnetic fields
- recognizing hazmat signs
Further more, everything done autonomous would give quadruple the points, which quickly became our main focus.
Because autonomous conquering of the parcours was the main goal, we all agreed that we'll design the robot around that. A "complicated" robot design like for our N10 on the one hand would make it difficult to model and to know, where each movable component currently is, but we also had a massive pool of potential error sources each time we encountered one. That's why we decided on a simple structure with 4 wheels, which are fixed to the robots's chassis.
We use an iterative designing workflow, where with each iteration we design a new model based on what we learned from the last one, realize it and finally test if our ideas actually work. This was a massive improvement to our past robots, where we would just build whatever we thought could be good without actually testing anything. In the gallery at the bottom of this page you can see various of these iterations.
Most parts of our robot are designed and assembled in Autodesk Fusion CAD Software. Besides 3D-printed components we also use aluminium profiles and other elements to improve our setup.
Detailed & more in-depth description and explanation of our robots construction as well as the CAD-files can be found here.
Fusion's collaboration features made it possible for us to all work on the same project. Multiple of us could designed different parts and we would then combind them into one assembled model.
Our building and developing process is pictured clearly through the steps of our diffrent variants. All started with a simple four-wheel construction, which gives a basis for all other setups.
| Variant 1 | Variant 2 | Variant 3 |
|---|---|---|
 |
 |
 |
| Variant 4 | Variant 5 | Variant 6 |
|---|---|---|
 |
 |
 |
At the moment, we are developing a 6×6 variant in parallel to our main crawler model to improve mobility in challenging terrain sections of the course.
However, the additional axle and more complex suspension system introduce new challenges:
- significantly reduced space for electronics and components
- less favorable geometry when climbing high steps (e.g. stairs)
* UPDATE * Our original approach was to develop both variants (4×4 and 6×6) in parallel and evaluate them under real competition conditions. However, due to the high academic workload during exam season, we have fallen behind schedule on the 6×6 platform. As a result, we have decided to focus entirely on the proven 4×4 crawler for RoboCup 2026 in Korea. Further development and construction of the 6×6 variant will resume after the competition.
We replicated some of the robocup obstacles in our school because we wanted to see if our ideas around the robots design actually worked in the real parcour. For instance, we discovered that our wheels were to small and to rigid, so we went for softer, larger ones.
One important test was the stair obstacle. The maximum step height in the RoboCup parcours is 16 cm, which matches almost exactly the steps in our physics lecture hall. Our robot is able to approach the step and push itself upwards. However, once the front wheels are up, there's not enough weight on the front axle. As a result, the upper wheels do not generate enough grip and the center of mass is too far back, so the robot would just flip over. This is still an open problem in our current design. The test showed us that wheel size and material are not the only important factors; the weight distribution of the robot is just as critical for climbing obstacles reliably.
This was also the first year we experimented with SLAM and autonomous driving. Mapping the environment work good most of the time, and autonomous driving through the labyrinth is functional in principle, though still being fine-tuned for optimal efficiency and speed. QR code and hazmat sign detection works excellently, detection markers are automatically recorded and placed in the map accurately as long as the robot doesn't move too fast.
We tested how long the powersupply would last under stress with a treadmill that moved at 1 km/h. At the beginning the battery had a voltage of 21.9 V (which isn't fully charged) and after about 30 minutes of driving, it was just above the minimum of 19.5 V unconnected (a couple volts lower when connected) that's required for our components to work. Without driving, the robot lasts about double that time. We also measured the temperature of different electrical parts to make sure nothing is getting unreasonably hot.
We heavily used an oscilloscope to debug issues on a low level to get down to the core of the problem quickly. For instance, we had a problem where the jetson orin nano dev kit's 40 pin header uart low voltage wouldn't go all the way down when connected to a device (left) to what it should and would when connected to nothing (right).
When trying to repurpose the debug uart pins it also didn't alway work the way we wanted. This was because the tegra-tcu driver would trigger extra behavior on special bytes like the escape byte 0xff or 0x0A newline.
A third problem that occured recently is that the jetson would suddenly turn of once we released the emergency stop button. This was caused by a sudden drop in voltage that went below the threshold of 14 V for our DCDC converter. We suspect that the high capacity of our built-in capacitors is the root of this problem.
Our goal this year was to challenge ourselves and build custom circuits and PCBs from scratch instead of relying on premanufactured components as other teams do. Through this we learned that electronics can get pretty complicated and involve a greater risk of issues. Yet we learned a lot and developed many new skills that will be helpful for the future and, importantly, we are now far less dependent on external support from individual manufacturers, giving us greater independence and flexibility in our future builds.
Compared to previous years, we started much earlier with the development of our robot. This gave us more time to focus on the most important problems and to test our ideas in practice. We also tried to build first prototypes much faster, so that the software team could start testing their code on real hardware instead of waiting for the final robot.
Another important improvement was that we worked in many small iteration steps. We tested different ideas, identified weaknesses and optimized the design step by step. This made the development process more structured and helped us to react faster when something did not work as expected.
Our time management also improved. We planned backwards from the competition date and tried to define what had to be finished at each stage. In addition, we had a clearer distribution of roles within the team, so that mechanical design, electronics, software and documentation could be developed more in parallel.
We also established fixed weekly meetings: one meeting on Wednesdays in our school lab and an online jour fixe on Friday evenings. This helped us to stay in contact, discuss problems regularly and keep the project moving forward.
Overall, we experimented more than in previous years and tested more technical solutions. However, this also meant that the project required more financial resources, especially because more prototypes, parts and materials had to be produced or ordered during the development process.
Our chassis base is constructed out of rigid 20mm aluminum profiles. These protect the battery and provide a stable base to attach further components to. Trapeze nuts can be inserted into the profiles so it's possible to screw parts to the chassis from all sides. At the bottom, the profiles also function as a slider so we can dynamically set the wheel seperation and thus width of the robot. Above the battery is a 5mm aluminium plate that functions as a mounting point for our main PCB and other boards. Another layer of profiles seperates these from the top layer, which consists of acrylic plates that we cut.
Most of the other parts, expecially those for mounting hardware, are 3d printed, because it is the fastest and easiest way to try multiple designs and get the exact geometry.
Both grip and wheel deformability are critical parameters for our driving performance, but since there are no commercially available tires that fit our needs and motors (DDSM115 hub motors) at the same time, we had to develop our own custom solution.
Our current design uses the Absima 1:10 Universal-Offroad Räderset wheel tires with a rim designed by us
Here are some other configurations we've tried before.
Our first custom tire concept consists of a 3D-printed TPU tire insert with adjustable infill and an outer tire layer made from poured silicone. The TPU insert allows us to fine-tune the flexibility and damping behavior of the wheel by changing the infill structure and density. The silicone outer layer is intended to provide better traction on different surfaces and obstacles.
Due to time pressure before the competition, our main priority was to make the robot drive reliably and finish the overall system. Therefore, we were not yet able to test the self-cast silicone tires as extensively as we would have liked. However, the first results look very promising, especially in combination with airless 3D-printed tire structures.
This approach is particularly interesting for the DDSM115 hub motors, because there are no standard tires available that fully match our requirements in terms of size, softness, grip and mounting. For this reason, we plan to continue working on our custom tire design after RoboCup.
Our simple robotic arm serves two purposes:
1. Dexterity
For dexterity-involving tasks our arm is equipped with a gripper which can both press buttons (while closed) and grab objects with diameters up to 8cm.
2. Camera agility
With our arm and the two servos comes the possibility to change the camera angle vertically. This allows us to gather more information through video, e.g. to inspect QR-Codes from other perspectives.
The custom gripper design was inspired by Festo’s bionic Fin Ray gripper. It utilizes a triangular structure based on the geometry of fish fins, which provides passive compliance. This flexibility allows the gripper to conform seamlessly to the contours of an object. Furthermore, the inherent flexing mechanism protects the servo motors from damage, preventing mechanical strain if the gripper over-closes.
Through many iterations, we learned which geometric facts matter by constructing the gripper. It is important that the cross-connections are perpendicular to the angle bisector of the tip. Also, you can change the stiffness of the gripper with the number of cross-connections. We tried at first 7 cross-connections, which was too rigid. So we decreased them through many iterations and finished with the iteration with just 5 cross-connections, which seemed to be a nice compromise.
Schematic overview of power distribution and communication interfaces:
We decided to upgrade from our Raspberry Pi 5 to a Jetson Orin Nano Developer Kit , because it would allow us to run AI models on the high resolution images from our cameras locally, where as if we were to outsource it to an external machine it would be heavy on the network and couldn't run at higher framerates or resolutions. Because like this all the software can run onboard, we can easily drive using wifi thanks to the antennas mounted to the jetson's case.
We use a custom-built NiMH battery pack with 16 cells. Each cell is a FDK 4/3 A HR-4/3FAU industrial NiMH cell with a nominal voltage of 1.2 V and a capacity of 4.5 Ah. This gives the battery pack a nominal voltage of 19.2 V. When fully charged, the pack reaches just under 23 V, and the robot can operate until the voltage drops to about 19.5 V. From our experience, this usually allows a runtime of more than 90 minutes.
The battery pack is built from individual cells that were connected using a spot welder. For charging and temperature monitoring, we integrated a 6.8 kΩ NTC sensor of the type B57164-K682-J. The battery connector is a 3-pin Molex Mega-Fit socket, which provides a robust connection for the robot’s power system.
The CAD model of the battery layout is shown below. The pack was designed to be very compact and space-efficient. Another important design goal was an even weight distribution inside the robot. This improves the general driving behavior and helps to keep the robot stable. However, as described in the obstacle tests, this may also be a disadvantage when climbing stairs, because there is currently not enough weight on the front axle to give the upper wheels sufficient grip.
We decided to use NiMH cells instead of LiPo batteries mainly for safety reasons. NiMH batteries are generally more robust and have a much lower fire risk compared to LiPo batteries, especially when they are handled by students in a school environment. They also tolerate mistakes and rough handling better, for example during testing, transport, charging or mechanical integration into the robot.
Another important advantage is transportation. Since we travel internationally with the robot, especially by plane, NiMH batteries are much less problematic than LiPo batteries. This makes logistics easier and reduces the risk of problems at the airport or during shipping.
For a student team, this robustness and safety margin are very important. The downside is that NiMH batteries are heavier and larger than comparable LiPo batteries. This increases the total weight of the robot and takes up more space inside the chassis. However, for our use case, we accepted these disadvantages because safety, reliability and easy handling are more important for our team.
The battery voltage is distributed to three separate power rails:
- 21 V battery voltage directly to the wheel motors
- 12 V regulated output via a BEC for the Jetson
- 12 V regulated output via a separate BEC for the arm servo board
Each power rail is protected by its own separate fuse.
The wheel motor power rail is routed through an emergency stop switch. When the emergency stop is triggered, only the power supply to the wheel motors is interrupted, while the Jetson and the arm servos remain powered. This allows the robot to stop immediately in dangerous situations without shutting down the onboard computer or the rest of the control system.
For better and cleaner cable management we designed our own PCBs in KiCad. All custom PCBs used in the robot were manufactured by JLCPCB. For our student team, this was a very good solution because the boards were affordable, delivered quickly and produced with reliable quality. Overall, we were very satisfied with the service.
The first custom PCB is mainly responsible for power distribution and for connecting the data lines of the wheel motors. It combines four separate circuits on one board: the motor power supply, the Jetson power supply, the servo power supply and the RS485 data connection for the DDSM115 wheel motors.
Motor power circuit
The wheel motors are powered directly from the battery voltage. This circuit includes a fuse and the emergency stop switch, so that the motor power can be interrupted immediately in dangerous situations.
In addition, we placed four 1500 µF / 35 V capacitors on the motor power rail. These capacitors act as local energy buffers. They help to stabilize the voltage when the motors suddenly draw high current, for example during acceleration, braking or when the robot hits an obstacle. They also reduce short voltage drops and electrical noise on the motor supply line.
Each motor is connected as close as possible to its corresponding connector on the PCB. For the motor power connection we use 2-pin JST PH connectors.
Jetson power circuit
The Jetson has its own separate power circuit. The battery voltage first passes through a fuse and a capacitor of the same type. It is then converted to a stable 12 V output using a Matek BEC PRO 12S 9–55 V DC-DC converter. The 12 V output is routed to a 2-pin screw terminal, from which a cable supplies the Jetson.
Servo power circuit
The Waveshare ST3215 servo motors and the servo board are powered through another separate circuit. This circuit is built in the same way as the Jetson supply: battery voltage, fuse, capacitor, and then a Matek BEC PRO 12S 9–55 V step-down converter to 12 V. The regulated output is connected to the servo board through a 2-pin screw terminal.
DDSM115 data connection
The data lines of the DDSM115 wheel motors are also routed through this PCB. Each motor is connected via a 4-pin JST ZH connector. The connector carries RS485 A, RS485 B and GND.
These lines are routed to an RS485 converter module and then to a 4-pin screw terminal, which connects the board to the UART interface of the Jetson. However, this part of the design caused problems in practice. As described later, we solved this issue with a second PCB revision.
The Jetson Orin Nano's UART TX line operates at 1.8 V logic, which is insufficient to reliably drive our UART-to-RS485 converter. Rather than redesigning the main PCB, we built a small separate level shifter board using two 2N2222 NPN transistors to shift the TX signal from 1.8 V to 3.3 V.
The board sits between the Jetson's UART header and the RS485 module. Its design is intentionally minimal — just the two transistors and the necessary biasing resistors — keeping it compact and easy to integrate.
This is a transitional solution: the level shifter circuit will be incorporated directly into the next revision of the main PCB, making a separate board unnecessary for future builds.
Schematic and board photos are shown below.
We use the Waveshare DDSM115 hub motors because of their
- compact design
- integrated motor controllers
- high weight -> low center of mass (whole robot)
- high torque / quick braking
They are controlled via an RS485 bus
The actuators of our arm are three Waveshare ST3215 servos; two for vertically angle movement, one to open/close the gripper. These can be Daisy chained together, so only one cable actually needs to come down the arm. The servos can be controlled via position or velocity and have encoders for feedback.
We use two Intel RealSense D435 cameras, one mounted to the robotic arm facing forward and one behind the lidar facing backwards. They are connected to the jetson via USB-C to USB-A 3.0 cables. They have global shutters and are capable of 1080p video- and 720p depthstreaming at 30fps. Some downsides are that the rgb camera is located at the right end of the camerabody instead of the middle and that the images aren't sharp enough to detect the smallest landolt cs.
That's why we also employ an OAK-D Lite camera from Luxonis as a stable front camera that can observe the arm when its in operation. The integrated IMU helps with robot localization and the rgb camera, which can stream video at up to 12MP, delivers razor sharp images.
As a 2d lidar we use the RPLIDAR A2M8.
While the Waveshare MLX90640 only gives a resolution of 32x24 pixel, it proved sufficient for our purposes and can be accessed via i2c.
We are currently using the Adafruit TLV493D for magnetic field detection. It can be accessed via i2c.
The IMU Adafruit-lsm6dsox-lis3mdl-imu provides data from a
- Accelerometer
- Gyroscope
over i2c.
Our software is implemented in the framework of the Robot Operating System 2 (ROS2). It provides a standartised way for (network) communication between different components, so called nodes. Many major software components we use for e.g. SLAM, autonomous navigation or robot state tracking are implemented in ros2. This makes it easy to get started quickly and later replace components when we want to test or switch to different implementations. We use ros2 for everything except (depth) image transmission for performance reasons.
For the robot's moving hardware (wheels, arm, gripper), we also use the ros2 control software stack, because it provides a hardware abstraction layer to the controller nodes and already has a lot of controllers and hardware interfaces implemented that we can use out of the box. They also all run in the same process, which reduces latency and allows for a higher update cycle frequency.
All nodes and topics are namespaced to /quac
To manage this ecosystem, we have adopted Docker for containerization. This move has effectively eliminated dependency conflicts through isolated environments and significantly streamlined our workflow, making the deployment of new development setups faster and more reliable than ever. We store the built images in the Github container registry (ghcr.io), so in case the jetson experiences a catastrophic failure, we can just reflash the OS and the pull the images without having to manually setup and build everything
The frontend only contains software for generating commands and monitoring the robot, everything else is done in the backend, just as it would be in a real-life situation, where a robot is sent on a solo mission and may not have a stable network connection.
guiniverse2 (wggRobotics) - Teleoperation
For teleoperated driving, we developed our own custom graphical interface, which is currently in its second iteration. Built on the Dear ImGui framework, this GUI provides a lightweight and responsive control center, allowing for real-time monitoring and manual intervention whenever autonomous navigation is not required. It
- displays the front, back, gripper and thermal camera streams
- overlays bounding boxes for detected objects
- overlays the robots future wheel paths if the robot was to continue driving at the current speed
- can drive the robot around
- move the arm to a desired point in xy space and open and close the gripper
- displays the json description and images of mapped objects
- prints the latest data that imu and magnetometer measured
rviz2 (ros2) - Visualization
Launch file here
rviz2 is used for visualizing the robot's state and sensor information as well as controlling autonomous navigation. It visualizes the
- robot's urdf-model
- joint states
- lidar scan
- pointclouds of the cameras
- mapped objects
- the (cost)map generated by the slam system
For some of these we had to create our own plugins
This gives the pilot a realistic idea what the robot itself and its surroundings currently look like.
gazebo (gazebosim) - Simulation
Launch file here
The robot can be simulated in Gazebo, although we currently have issues getting the wheel friction right. Nevertheless, it proved really helpful for testing if most of our software actually works together, since we can simulate every component we want
robot_state_publisher (ros2)
Launch file here
This node publishes the urdf model of the robot as well as static and dynamic TF-frames based on the joint states, which is essential to know the current state of the robot.
joint_state_broadcaster (ros2 control)
This controller publishes the current states of all dynamic joints based on the position state interfaces of the hardware interfaces. That includes:
- wheels
- arm
- gripper
rtabmap_odom (rtabmap_ros)
Launch file here
This VSLAM System calculates odometry purely based on depth / stereo / rgbd images from our realsense cameras (the oak d lite depth image is too noisy). For that, we had to build with multi cam enabled. As it goes for VSLAMs, it's extremely accurate, but also requires high computational power. The robot can even be carried around slowly and it will keep up. However, we've also experienced some weird behavior where the odom frame would move in the z direction, which we don't want to happen.
ohm_tsd_slam (autonohm)
Launch file here
This SLAM system proved to be expecially good because of its continous updating of the map to odom transform. It is very responsive with fast error correction, which is essential for 2D mapping in uneven terrain. It calculates the map frame based on the odom frame and the map that it generates and updates based on the lidar scan results.
rtabmap_slam (rtabmap_ros)
Launch file here
The rtabmap slam system also uses the projected depth images besides the lidar scan to create a 2d map. We still have to evaluate, how well we can configure it. It also publishes the ever growing 3d pointcloud of the area seen by the depth cams, so we can get a more or less noise 3d representation of the enviroment.
In the future, we want to try out the nvidia isaac visual slam
cmd_vel_mux (wggRobotics)
Launch file here
An adapted version of the ros2 twist_mux package that multiplexes stamped and unstamped twist messages from guiniverse2 and nav2 and publishes the stamped message with the highest priority
diff_drive_controller (ros2 control)
This controller calculates the wheel's joint speeds for a differential drive robot based on hardware parameters like wheel seperation. It also reads the hardware interfaces to estimate the odometry. It is widely used, well tested and exatly fits our needs.
wheel_monitor (wggRobotics)
This controller reads the current drawn by the wheel motors in addition to position and velocity and sends the information to guiniverse.
quac_hardware/DDSM115 (wggRobotics)
This hardware interface talks to the DDSM115 motors over a serial connection and gets feedback from them according to the communication protocol.
nav2 - Autonomous driving (ros2)
Launch file here
We leverage the ROS2 Nav2 stack for autonomous driving as it is the standard for ros2 navigation and can be used easily with many resources available on the internet about it.
inverse_kinematics (wggRobotics)
Launch file here
This node calculates and publishes the angles of the two servo joints in the arm based a target pose in Cartesian space and the gripper servo angle based on how far the gripper should be open.
joint_trajectory_controller (ros2 control)
This controller interpolates between the current and target joint positions of the arm. It gives the results to the servo hardware interface.
quac_hardware/WaveshareServos (modified htchr, wggRobotics)
This is the ros2 control hardware interface for talking to the waveshare servos we use. It exposes position and velocity as a command interface and position, velocity, force and temperature as state interfaces.
arm_target_controller - autonomous gripping (wggRobotics)
This node guides the end-effector of the arm towards the object we want to move/grip.
rplidar_ros - LiDAR Scan (Slamtec)
Launch file here
This node publishes the lidar's 2d laser scan.
sensor_publisher (wggRobotics)
Launch file here
This node publishes the data of the I2C devices, namely the
- thermal camera
- magnetometer
- imu
cam_streamer - video streaming (wggRobotics)
This node superclass streams a camera to other nodes.
A subclass implements functions to pull rgbd frames and pointcloud data from a specific type of camera. Based on this data, it
- exposes a color stream with GStreamer over a UDP server with H.264 encoding or JPEG compression, massivly reducing bandwidth. It is received by our guiniverse2 control app. We can reduce the bitrate according to our network capabilities so we always have stable video transmission
- publishes bgrd images with the depth image aligned to color so another node can check the depth value at any color pixel
- publishes a pointcloud2 with color information
Launch file here
We use the RealSense SDK 2.0 to pull new frames, align the images and generate the pointcloud.
Launch file here
We use the DepthAI SDK to create a camera pipeline that provides color and depth frames as well as on device build pointclouds.
detection_server - object detection (wggRobotics)
This superclass node is responsible for detecting and mapping different objects in the robots area of operation
Object detection
A subclass of this node implements a function, which returns the bounding boxes and types for all objects it detected in one image. These are then published right away so they can be overlayed in a gui.
Mapping
With the bounding box, the depth image and the TF-frame of the camera, the position of the object in 3d space relative to the base_link and further to the map frame is calculated. The position is then compared to past detections and the mapped object locations will be updated accordingly. The positions are published so they can be visualized or used by another node to do further work, like navigation. Besides the position in 3d space, it also stores the image of each object with the highest detection confidence and publishes them in regular intervals.
We use a YOLO object detection model designed by Ultralytics, which we trained on a specific dataset. We take adventage of our jetson's hardware by optimizing and running the model with the NVIDIA TensorRT ecosystem, which allows for single digit millisecond inference. Only mapped objects that have been detected a number of times are actually published because with small object detection models, false positives do happen from time to time.
Launch file here
Dataset: https://universe.roboflow.com/kauil/hazmat-h6fgb/dataset/16 Contains all hazmat signs defined in https://rrl.robocup.org/forms-guides-labels/
Launch file here
We created our own dataset with over 700 images, that we labeled manually with the yolo oriented bounding box format. This type of model is especially good for detection the paintrollers, because their 2d projections are almost always a rectangle.
Launch file here
We use the quirc library to detect qrcodes in almost real time.
Launch file here
We use the opencv based detection algorithem from clubcapra to detect landolt cs. The steps are as follows:
- convert image to grayscale
- apply blur
- map light pixels to white and dark ones to black based on a threashold
- find contours
- for each contour of a minimum length:
- check that
$\frac{\text{Area convex hull}}{\text{Area minimum enclosing circle}}$ is above some threshold - check that there is only one convexity defect thats deeper than some threshold
- => valid landolt c
- check that
Landolt cs that share a center with error up to their average radius are then grouped together and sorted by radius from biggest to smallest. The orientation of the largest one is either defined by a parameter or decided based on its orientation in the image. The nested cs orientations are calculated relative to the largest one.
| Part | Quantiy | Price (€) | total (€) |
|---|---|---|---|
| Nvidia Jetson orin nano developer kit, 8GB | 1 | 319 | 319 |
| Waveshare DDSM115 Hub Motor | 4 | 64,9 | 259,6 |
| Waveshare ST3215 Servo | 4 | 24,9 | 99,6 |
| Waveshare Serial Bus Servo Driver Board | 1 | 5 | 5 |
| Matek BEC PRO 12s | 2 | 25,9 | 51,8 |
| Slamtec RPLIDAR A2M8 | 1 | 279 | 279 |
| Intel RealSense D435 | 2 | 420 | 840 |
| OAK-D-Lite | 1 | 192,95 | 192,95 |
| Waveshare Aluminium Case for Jetson Orin | 1 | 25 | 25 |
| Waveshare Gripper | 1 | 54,9 | 54,9 |
| Waveshare UGV Suspension | 4 | 34,9 | 139,6 |
| Absima 1:10 Wheels | 2 | 39,05 | 39,05 |
| Springs | 54,62 | 54,62 | |
| BBDINO Silicone | 1 | 27,97 | 27,97 |
| Siraya Tech Flex TPU Air | 1 | 39,7 | 39,7 |
| Waveshare MLX90640 | 1 | 71,99 | 71,99 |
| Adafruit-lsm6dsox-lis3mdl-imu | 1 | 21,95 | 21,95 |
| Adafruit Tlv493d | 1 | 12,98 | 12,98 |
| Adafruit Qwiic/Stemma QT 5 Port Hub | 1 | 9,99 | 9,99 |
| 12C Qwiic Stemma QT Kabel-Kit | 1 | 10,99 | 10,99 |
| Hardware(Screws, aluminum profiles, etc.) | ~80 | ~80 | |
| PCB-Components | ~40 | ~40 | |
| 2.553,90 |
PXL_20251213_141313305.1.mp4
quac_elevated_ramps.mp4
quac_v1.mp4
IMG_5633.mov
