I'm making a custom bldc motor to use as the main propulsion for an automated rigg to map the bottom of the sea! For now i'm testing it in my paddle surf, outside the water it seems to be way to powerful! The motor itself is all 3d printed, I'll soon make a post about it! submitted by /u/ArnauAguilar [link] [Kommentare]

Hi everyone, I built a small open-source web simulation of a double pendulum to demonstrate chaotic motion and sensitivity to initial conditions. Repo: https://github.com/mohammadijoo/Double-Pendulum-Chaos-Mechanism The goal is educational: a browser-based demo that lets students or beginners see how a simple mechanical system can produce complex, chaotic behavior. It is written with HTML, CSS, and JavaScript, so it can run without installing a physics engine. I would appreciate feedback on: whether the visualization explains chaotic behavior clearly whether the equations / numerical integration could be improved what parameters or plots would make the simulator more useful for control, robotics, or physics students whether adding energy plots, phase portraits, or Lyapunov-style divergence visualization would be useful I’m sharing it mainly for technical feedback, not as a commercial project. submitted by /u/abolfazl1363 [link] [Kommentare]

Curation of materials for robotics and Artificial Intelligence. Learn as your practice materials. Today we have some extensive knowledge available for building robotics. And there is a roadmap that everyone interested can easily build using the available resources. submitted by /u/dineshmadhava [link] [Kommentare]

Real Steel Fighting .. It says the robot are real autonomous fighting. That means it will be better than real steel movie which is tele operated. submitted by /u/Modulus3360 [link] [Kommentare]

I've always been interested in point clouds and spatial data, so I created my own LiDAR scanner! It runs off of an esp32 and TMC2209s on a custom PCB, which continuously rotate and sweep the LiDAR sensor. I learned a ton creating this project, as this was my first time creating a PCB and using NEMA motors (I have used other motors before). Github repo submitted by /u/thatonebckid [link] [Kommentare]

I’ve been working on a mission assurance architecture called Parallax and recently completed another validation run in a degraded operating environment. In this sim run, an autonomous USV fleet experienced GNSS/RF degradation resulting in conflicting navigation observations across multiple assets. Rather than assuming all telemetry was trustworthy, the system continuously evaluated observation integrity, measured divergence from a shared world model, isolated compromised data sources, reconstructed authority through distributed consensus, and maintained mission continuity without operator intervention. One of the problems I’m interested in is what happens after sensor fusion. Most autonomy stacks do a good job combining observations, but what happens when those observations can no longer be trusted? The entire system runs locally at the edge with no cloud dependency. All processing, validation, trust scoring, consensus generation, and decision support remain completely air-gapped and self contained. Current areas of development: • Distributed trust scoring • Reality integrity assessment • Consensus reconstruction • Autonomous recovery and reintegration • GNSS degradation and spoofing resilience • Edge-native operation with no cloud connectivity Interested in hearing how others are approaching sensor trust, degraded navigation environments, and resilient autonomy. submitted by /u/DraevenOfficial [link] [Kommentare]

Been working on a PiCar-X build on a Raspberry Pi 4B. v1 goal: detect an AprilTag (36h11 family, ID 0), steer toward it with a PID controller, drive forward, and stop at a configured distance threshold. Toggle it on from a browser dashboard, 3-second countdown, and it goes. I built this entirely with Claude Code. It’s been a massive productivity boost while balancing a full-time job, and the process of building agentically has been a great learning experience. WebSocket concurrent send corruption The broadcast coroutine and the sensor push loop were both calling send_json() concurrently. At await boundaries they interleaved, Starlette threw, and the client was silently dropped from the send set — meaning the toggle-off confirmation never arrived and the button stayed stuck in active state even after the car stopped. Fixed by replacing the shared client set with a per-connection asyncio.Queue and a single drain task per connection. Camera color inversion that didn't respond to the obvious fixes BGR888 didn't fix it. RGB888 + cvtColor didn't fix it either. Root cause: capture_array() on this Pi hardware returns RGB regardless of the format name, and this platform's libjpeg encodes from RGB input correctly without any conversion. One-line fix once the actual data layout was confirmed via a frame diagnostic log. Had to fully remove Vilib It uses a Picamera2 internal API (allocator) removed in 0.3.36 — crashes on any camera restart after a chase session. Server now owns Picamera2 directly for the full session lifetime. What's next v2 candidates on the list: distance-proportional speed, latching stop behavior, camera tilt tracking, and operator override during chase. Stack: Raspberry Pi 4B · PiCar-X v2.0 · Picamera2 · pupil-apriltags · FastAPI · Python 3.13 submitted by /u/okineedaplan [link] [Kommentare]

I put together a small ROS 2 subsystem that turns a 2-DOF pan/tilt platform and a cheap 2D LiDAR into a stop-and-capture 3D scanner, and figured it might be useful to someone else here. The setup: two Feetech STS3215 serial-bus servos aim an LDROBOT LD19. A node sweeps the platform and an assembler stacks the 2D scans into a `PointCloud2` using the live TF tree. There's an optional MQTT bridge so an external controller (in my case a microcontroller mission queue on a rover) can trigger scans and get a completion handshake back. It's a *complete* project — it even includes a fix to the LiDAR driver (upstream `ldlidar_stl_ros2` won't build on recent GCC/glibc; the patched fork is linked below). It talks to the rover over a well-defined set of MQTT messages, but every command also has an equivalent ROS 2 topic, so if you want a pure ROS 2 setup you just don't launch the bridge. (Personally I love the MQTT side — it lets me drive the whole thing from a tablet.) No vendor SDK — the Feetech STS/SMS half-duplex protocol is implemented directly over pyserial, including handling the URT-1 adapter's habit of echoing every TX byte back on the RX line (the kind of thing that eats an evening if you don't know it's coming). The assembler is driver-agnostic: it consumes standard `sensor_msgs/LaserScan` on `/scan`, so any conformant 2D LiDAR should work. It's running on an RK3588 today and is built to go headless on a Pi 5. This is the first piece I'm open-sourcing from a larger autonomous rover project, GPL-3.0. I'd genuinely welcome feedback — particularly from anyone who's done multi-LiDAR or TF-timing work, since the scan-to-TF synchronization was the fussiest part to get right. But it does work! Happy to answer questions about any of it. Project: https://github.com/aa2mz/pan\_tilt\_lidar Patched LiDAR driver: https://github.com/aa2mz/ldlidar\_stl\_ros2 submitted by /u/CorrectAir8833 [link] [Kommentare]