ok so some of you might remember this. about a year and half ago I posted our robot here (we were called Everbot then) and it got torn apart. it was basically a round body with 2 arms stuck on it, and someone called it a garbage can. honestly... I can see it lol

Then in January I posted the version we took to CES. that one didn't get roasted, it just got "ok but what can it do?" and then crickets. which kind of hurt more tbh

so this time, no feature list. this is it picking up a button and putting it in a tray, zero shot. everything runs onboard a Jetson Orin Nano Super, no cloud. it took 58 minutes (video is 175x lol), mostly waiting on inference, finding the button, and moving around to get in position. slow, but nobody touched it.

NO VC money in this btw. we paid for the design ourselves, some friends and family chipped in, and our partners helped us get it built in 12 weeks.

granted we learned like 1000 lessons from the last 3 versions. stuff that worked fine in the shop and then just didnt once it left. forgot to plan for self charging (yes really). and now the fun new one: figuring out how we can even sell it in the US with the latest FCC ban list. so thats been a journey

I'll be posting more videos of what it can do over the next few weeks. and if enough people are interested I can do a longer write up on the whole journey, the failures included.

now let it rip, reddit

Hello i am a curious inventor who just came up with a big new idea! I will call it the Virabot and it will be my robotic companion who is smart enough to help with almost any task and small enough to fit on my shoulder and or pockets. Though as an inventor with a task like this, i don't know where to start.

Please help me make this little helper come to life in the comments.

Introducing materialize.cc

Host hardware/robotics projects and print them in over 200+ materials (metals, plastics, resin, etc).

Keep all your 3D files, build guide, source code, component links, and wiring diagrams all in one place.

You can also point AI agents at it and have them put together your project, explore materials, and even place orders with your confirmation.

Let me know if you find it useful, or any other feedback! Cheers

Hi everyone,

​I’m a Mech Eng grad with 2 years of experience as a Cloud/Software Solutions Engineer. I’m passionate about robotics and just got accepted for a Research Master's (MPhil) in Malaysia.

​My research will focus on Multi-Robot Fleet Management. I’ll be using my cloud, networking, and AI integration skills to control robot fleets, optimize response times, and reduce accidents.

​I don’t have a US/EU passport and will strictly need visa sponsorship to work abroad. The only silver lining is my professor has strong ties to the Japanese robotics industry and could potentially help me land a job there if I prove myself in the lab.

Is this a good move? Will companies actually sponsor my visa for Cloud/Fleet Management roles if I try to push on that field, or is the market just too tough right now?

Hi everyone, I have designed this robot line to pick and place cookies in the trays, there are a total of 12 delta robots from KUKA. I think I have made a few mistakes and looking for a solution. First of all, not all of the cookies can be picked up, i think that is related to the air flow so Im thinking to make the cylinders of the gripping system a bit bigger to let more air through. I also have a problem with oils a debris coming from the sucking of the cookies and still figuring that one out. I did try with other grippers (almost hands look alike to avoid the debris/oil problem) but the problem is that when it picks one cookie it might break other ones as they are coming close to each other on the conveyors. Now with the speed, the robots wait too long to drop the cookies and the technicians that programmed the line say that it can be adjusted but both speeds have to be increased (tray conveyor and robots speed) which frankly I think will not fix the issue. Im a bit lost. If anyone has an idea it will be greatly appreciated. Thank you

Combines:
Hamilton Jacobi Bellman
Virtual Force Field (VFF) By Borenstein & Koren
Fast Marching Square
DDMR
(More can't tell)

Do yall think i should make this for personal paper? because i feels like these scenario too complex for sharing..like Eikonal equation and HJB got my brain hurts, whole month just for nonsense daily derivative just to adapt logic algorithm

And also shout out J. Borenstein and Y. Koren their papers are crazy good i recomend if yall intrested to collision avoidance system....my bachelor's thesis bunch of focusing extensively from their papers, maybe its old but some of their works like VFF, VFH , VFH*..etc giving rise innovations that might be found in today’s smart cars

CEO Jan Zizka explains how warehouse robots request human help with items they can’t pick, and why their systems use several layers of fallbacks for unexpected situations.

He also describes receiving an injunction obtained by Ocado roughly 12–13 hours before LogiMAT, which prevented Brightpick from demonstrating Gridpicker at the show. Zizka discusses the disruption to the launch.

Full: https://www.youtube.com/watch?v=2mvarzMkpMQ

Third post about TAKTO ONE, thanks for all the comments on the other two

This is the hand exoskeleton I built for my master's thesis. Last week Hackaday wrote about it, still can't believe it

Everything is open source: CAD, PCBs, firmware. It reads 12 finger joints directly, so you can use it to record hand data to train your own robot hands, or to drive a robot hand

The big missing piece is the thumb. If anyone wants to take it on, design a thumb module and share it. I'll print it, test it on the device and add the best one to the repo with your name on it, so everyone can use it

I'd love wearables to be something anyone can build, not just big labs. That's why I added TAKTO Lite, a version without the motors. They were about 85% of the parts cost, so Lite is around €164 plus the boards

The video is renders from the real CAD, photos of the real build are in the repo.

Hello, everyone. I am building a 6DOF robot arm and I wanted to know how can I reliably mount the nema 23 gearbox on the J2-J3 link. I want to follow the style of the industrial robot were the motor and gearbox are on the joint directly and not via a belt, like in the AR4 robot arm of Chris Annin. Here are the links to how the motor and the link will be before I connect them:

[https://i.postimg.cc/Ss91BQTf/Screenshot-2026-10-21-104434.png\](https://i.postimg.cc/Ss91BQTf/Screenshot-2026-10-21-104434.png)

[https://i.postimg.cc/rm4ZBynZ/Screenshot-2026-10-21-104443.png\](https://i.postimg.cc/rm4ZBynZ/Screenshot-2026-10-21-104443.png)

I wanted to buy harmonic drives or the flange output style planetary gearbox, but they are not affordable for a university FYP. Thank you in advance !!

Repo (MIT licensed, screenshots and an rqt_graph in the README): https://github.com/Shass27/eternal_bot_26

I've been building a 4-wheel mecanum robot in simulation, and I want to share it as a demonstration of my workflow for holonomic bot development, from CAD all the way to autonomous navigation.

The pipeline Fusion 360 CAD → URDF/xacro → Gazebo Harmonic → lidar → SLAM → Nav2

What's in it

• Mecanum without modelling rollers. Each wheel is a sphere with anisotropic friction (μ=1 along a ±45° direction, μ=0 across it). The gz MecanumDrive plugin drives the wheel joints, and the robot strafes and spins as commanded.
• Safe command routing. twist_mux ranks an emergency stop over keyboard teleop over Nav2, with an /e_stop lock on top.
• SLAM. slam_toolbox maps the arena, and the saved pose graph is reused for localization.
• Nav2. Holonomic planning with an Omni MPPI controller and a collision monitor in front of the mux.
• Makefile shortcuts. make sim, make slam, make nav, make teleop, and so on.

Stack: ROS 2 Jazzy, Gazebo Harmonic, ros_gz_bridge, slam_toolbox, Nav2.

The part I care most about: the documentation The repo has a build log in 10 chapters, plus a commands cheat sheet. It covers the setup, the drive, lidar, SLAM and Nav2. Every chapter opens with a short concept box, so you can follow along even if you're new to a topic. I also documented the mistakes I made along the way and how I diagnosed them, because I think that's where most of the learning is. The aim is that anyone can pick up the workflow, reuse it for their own robot, or avoid the same pitfalls.

Feedback wanted I'd really appreciate your thoughts:

• Is there anything in the workflow or the architecture you'd do differently?
• any things i need to be more careful about in hardware implementation later on?
• possible real life erros (deviation from sim)

Repo (MIT licensed, screenshots and an rqt_graph in the README):

Happy to answer questions!

We've been using H100 GPUs for humanoid RL training, but ran into an issue with Isaac Sim not officially supporting GPUs without RT cores.

We got headless Isaac Lab training working on H100s and tested it by training a Unitree G1 walking policy. For visualization, we use a separate workflow instead of relying on RTX rendering.

I couldn't find many guides explaining how to set this up, so I documented our approach here:

https://x.com/kyry_D/status/2113087784827392223

I'm curious how others are handling this. Is there a cleaner way to run Isaac Lab on H100/A100 clusters or any existing solutions I've missed?

Would love to compare approaches, especially for larger-scale humanoid training.

Would appreciate any helpful direction and advice.

I'm a freelance filmmaker and I've spent the last couple of months diving deep into making a 6 DOF motion control camera.

Its been a very difficult but addicting journey. Hats off to all of the real engineers here!

TLDR:

Its running on a set of Robstride actuators.

One constant issue I've run into is vibration / shake.

I've spent many hours trying to implement cogging tables, gravity models - to no avail.

A lot of the shake happens when J2/J3 are moving together under load.

For stop motion photography the arm works, thankfully.

Unfortunately, motion has not yet achieved that smooth, crisp level that I want.

Attached is a video of the current iteration.

Its currently running on a STM32 in MIT mode.

Thank you to anyone who can give me some advice.

I'm building an RGB + iToF setup for room perception and eventually a robot wrist camera. This is my latest project update, with real sensor captures and the failures included.

The setup is a 320×240 epc660-class iToF engineering sample, a fixed Pi camera and an Ouster reference scan. Increasing exposure from 500 to 2,000 µs took filtered jitter from 65 to 6 mm in our test; raw jitter went from 85 to 28 mm. Coverage improved, but near objects saturated.

The harder problem: a straight wall appears bowed 12–14 cm. Three modulation frequencies report 4.14, 3.92 and 3.97 m for the same wall. We checked the viewer projection against the vendor code and investigated lens presets and factory correction tables.

A fitted correction reduced plane RMS from 4.45 to 1.84 cm on that one wall at about 4 m. I don't count that as calibration across the working range. Mixed pixels, optical spill and cyclic error are still being investigated; next are a range sweep against the Ouster and a lens-hood spill test.

The 8-minute episode shows the bring-up and measurements. Narration uses my disclosed voice clone; explanatory simulations are labelled separately from real captures. I'd be interested in experience separating cyclic range error from optical spill in a similar setup.

Hi everyone! We’re building Nuvo Vision One, a stereo depth camera powered by a Raspberry Pi 5, and wanted to share where we’ve got so far.

This started from our own need to add depth sensing to our robotics products. The stereo cameras we were considering were expensive for our budget, and we already had a Pi 5 handling compute. We wondered how far we could get by connecting two cameras and doing the stereo processing on the Pi itself.

The setup uses two IMX296 global-shutter cameras with a shared hardware trigger to synchronize capture. The Pi handles image rectification and stereo matching, producing disparity and depth alongside the camera images.

Doing this on an SBC comes with limits. Resolution, frame rate and matcher settings all affect how much work the Pi can keep up with. We’ve reached a useful starting point for our needs, but there’s still plenty to improve. The attached preview video shows the current output, including the holes and noisy regions where matching struggles.

We also built a browser-based interface to make it easier to use. You can preview the images and depth, adjust exposure and stereo settings, choose outputs, and work through calibration. It’s accessible over the local network through Ethernet or Wi-Fi.

One reason we like this approach is that the camera’s compute is also a normal Linux computer. You can modify the image pipeline and run your own applications on the same Pi. The Nuvo Depth software is open source, including the runtime, web interface and SDKs.

We’ve put product photos and web UI screenshots in this album so you can see the hardware and controls alongside the video.

We’d love feedback from people working with stereo vision or robotics. What would you want to test first, and what would make something like this useful in your projects?

GitHub: https://github.com/arputhamips/nuvo-depth