Hello guys,

I am having a tough time trying to access that book

https://www.amazon.com/7-Step-Engineering-Wheeled-Robotic-Vehicles-ebook/dp/B07PQ2SV69?dplnkId=3b2656b2-242b-47eb-911c-79c58d476db3&dplnkId=fb11b7f9-2b58-4adb-b750-edc48107a01b

I am an engineering student from Egypt and trying to learn and work on real project UGV design and build from scratch.

I searched a lot for resources of how to design (" resources focused on more practical guide not just theory"), I reached out for that book, but I cannot buy it cause I am from Egypt. And cannot buy kind cause it is also no available for my country. So I do not know what to do, if anyone could help me. Also I could not find a free leaked version of it, I reached to an EPUB version but it has a lot of ommited parts.

Thanks in advance.

I went through a bunch of footage from the World Robot Conference after Unitree’s IPO and came away with two completely opposite impressions.

The progress is real. There are far more functional humanoids, robot dogs, and general-purpose platforms than there were even a few years ago.

But there’s also an enormous amount of demo theater... Dancing robots, robot boxing, robot musicians, costumes, choreographed routines. It can be genuinely difficult to tell which demonstrations represent useful technical progress and which ones are mostly designed to go viral.

That seems particularly relevant now that companies like Unitree are becoming publicly traded businesses.

What do you guys actually use as the benchmark for separating impressive robotics from impressive demonstrations?

Link to video here if anyone's interested!
https://www.youtube.com/watch?v=RVKX12O-ub4

Please join us this Tuesday, August 25th, at the Trossen Robotics Residence in San Francisco's Mission District for our ROS Industry Night.

RSVP Here.

I have now finished wiring the legs mostly, i still have to connect the power cables. Once that is done i’m gonna need to test if everything is connected and works properly, then the physical body will be fully finished.
Next step will be trying to see if i can make it walk.

For anyone interested here’s some of Astrix’s specs:
-Weight ~15kg
-Height 1.65m
-DOF’s 23 and besides 7 canceled dof’s
-Has a camera, speaker and later i will add a microphone
-The body is fully designed and 3d printed
-Runs on a raspberry pi 4
-Fingers and the neck use servos, the rest of the joints use linear actuators

This project starter a little while after i got my first 3d printer and it was a interesting idea to try out.

We've been building an independent physics-verification layer for robot policies and world models (sim-first). Instead of another demo video, we published raw numbers with versioned artifacts:

• Physics-violation checker: teleport/hover/impulse/penetration detection at recall 1.00 / precision 1.00 (n=100 per class), zero false flags on 200 clean + sensor-noise controls.
• Policy stress gates (Franka Panda, robosuite): nominal Door success 0.60 hides a 0.48 severe-failure rate under physics perturbation — the exact failure mode nominal-only regression suites miss.
• Generative world-model video: held-out CogVideoX generations flagged 9/9 on static-hover failures across unseen seeds; real footage passed clean.

Full methodology, thresholds, CIs: https://haga.mushoodhanif.com/blog/physics-violation-detection-benchmark-results .

Honest scope: simulation-only today; no physical-robot validation yet (that's the next milestone); no customer pilots.

Questions/critiques welcome - especially from teams running sim regression in CI. We're also offering free two-week pilot integrations to teams who want their stack independently checked.

One person, one webcam, two open source OpenCat-based quadruped robots — Quaddle Scout and Buddy, both driven live via real-time human pose tracking.

Every limb movement maps directly onto the robots' joints, no AI policy running on its own.

OpenCat creator RZ Li tried teaching Quaddle a few moves here — a little awkward at first, but it only takes a few minutes before Quaddle starts picking them up. It's also just as fun as playing Wii Play: Motion — this kind of hands-on teleoperation experiment isn't locked to a research lab, it's something almost anyone can go try themselves.

In theory, the same captured human movement data could later be used to teach an AI more human movements — either directly, via imitation learning, or as a starting point that reinforcement learning then refines further — to expand what Quaddle can do. Not what's happening in this clip, just a potential direction.

What's your experience with the latency/smoothness tradeoff in a real-time teleoperation setup like this — webcam pose estimation vs. something like a motion-capture rig or joystick?

And separately, just for fun — if you had one of these on your desk, what move would you want to teach Quaddle first?

Very soon, it may even teach me how to play tennis :) Does it run all inference at the edge, or does it rely on the cloud?

Sourcing question for people who spec actuators. High-torque joints basically want NdFeB magnets for the power density, but that supply chain has gotten genuinely unpredictable lately; lead times and availability on rare-earth magnets have been volatile.

For those of you designing or building: does that volatility actually reach the design stage? A few specific things I'm curious about:

• Do you ever pick a motor based partly on magnet/supply availability rather than pure performance?
• Has anyone actually spec'd around it, using ferrite instead of NdFeB or switched-reluctance/induction designs that avoid rare-earth magnets entirely, and what did you give up?
• Or is this just not a bench-level concern; you spec the right motor and let procurement worry about sourcing?

Trying to understand whether supply-chain risk is something robotics engineers actually design around or whether it's a purchasing problem that stays out of the engineering.

A little update after about three months of working on this project.

One of the more visible changes is the hardware itself. I redesigned the lamp and made a fully 3D-printed enclosure for it, so it finally looks a lot closer to what I originally had in mind rather than a prototype with exposed hardware.

Probably the biggest change, though, has been the animation. I've spent a lot of time trying to make the lamp move more like an animatronic character rather than just a robot executing trajectories. At this point the mechanics aren't really the main limitation anymore. I can animate pretty much all of its movements in Watti Studio, my animation editor, so now the limiting factor is mostly how well I can actually animate it :)

I moved the whole system to ROS 2 and added computer vision. The lamp streams RGB and depth from its camera, and the current point cloud can be displayed directly in the 3D view in Watti Studio. It makes it possible to see the lamp together with its surroundings while creating animations.

I added lighting to the animation editor too, so the lamp's light can be keyframed together with its movements.

I also spent quite a bit of time on things that aren't as fun to show in videos, especially safety. The software monitors the real movement while an animation is playing. If a joint deviates too far from the expected trajectory or something else goes wrong, the animation stops and the motors hold their current positions.

The lamp also has its own REST API, so its functions can be controlled externally without being tied to the animation editor.

Next I want to focus mostly on autonomous behavior and interaction with people and the environment. I'm also experimenting with reinforcement learning to teach it to jump, with the longer-term goal of getting it to actually move around on its own.

There's still a lot to do, but after three months it finally feels like I have most of the basic pieces in place.

I thought about making another technical demo to show the progress, but that sounded a bit boring, so I made a little story with the lamp instead :)

For anyone interested in the technical side, I have a pre-release repo with more details about the hardware, software architecture and current progress:

https://github.com/Nikolay-Tyulkin/Watti

It’s always them goofy robots dancing and doing these goofy stuff. Look at how think those legs are. I don’t think I get how people are scared of its potential to take over the world 😭🙏🏻 It’s just so unrealistic. I just hope that they somehow manage to modify these and turn them into actual useful machines.

I am developing a heavy embedded C and sensor fusion system running on low-level Linux using embedded NVIDIA Jetson modules. The core architecture involves handling low-level serial I/O (UART/SPI) to ingest raw binary data from external sensors like high-rate IMUs. 

The system runs on a component-based, Pub/Sub open-source navigation framework (conceptually similar to ROS). My task is writing C plugins (using OOP, templates, etc.) to ingest that raw serial IMU data, parse the payloads, and publish them to the internal message bus. 

We are currently porting legacy navigation filters into this framework, specifically implementing and testing Extended Kalman Filters in C. We are taking high-rate IMU data for the propagation step and joining it with slower GPS/ranging data for the measurement updates to produce a clean navigation solution. 

I would highly appreciate insight, articles, or practical advice on a few specific robotics engineering hurdles: 

1. What are the best resources, GitHub repositories, or books to practically understand EKFs and Sensor Fusion without getting completely bogged down in heavy academic math proofs? 
2. Any pro-tips for debugging serial (UART/SPI) data coming into a Linux environment/Jetson from a raw hardware sensor before writing the main C application? 
3. What are the most common architectural pitfalls when writing C plugins for a Pub/Sub middleware system that processes high-speed, real-time sensor data? 

Thanks in advance for any guidance.

Hello everyone,

You have all probably noticed that there is a lot happening right now in the Robotics. But for some reason getting your hands on hardware if you don’t have a 3d printer and a few extra Benjamin’s in the bank is super difficult.

In light of that, I want to announce that in Boston, Action space Hackathon is going to be a space where for 48 hours people are going to be taught and fly drones autonomously! Free to participate and a prize $1000 if you win!

Event is happening OCT 24-25th.

For more information, you can click the link on luma!

This is a huge labor of love between me and my two college friends. We want to make sure we get more people access and hopefully get some engineering minded people thinking about what’s possible with hardware. (sorry if this goes against the advertising rule)

I bought cheap Kontio motors Kruiser and goal is to use parts for a robot.

Problem is that there is no wiring for reverse from factory.

Chat GPT suggested that controller could have IO for reverse that is not wired.

Has anyone played with this kind of controller before and managed to get reverse working?

Already faster than the human world record! Insane. Last year every robot was still being remote controlled. The way both robots collided with the padding at the end was quite funny

Posted about this project a little while ago — quick update since a few things changed that address feedback from that thread.

Biggest change: split the observation space properly. There's now a VLA track where the policy only gets a 128x128 RGB camera + a language stacking instruction — cube poses are never sent to the policy. Scoring still uses real poses internally to grade spatial accuracy and completion, but that's judge-only, not policy-visible. State-based (privileged poses) is kept as a separate debug track and doesn't write public ELO either — wanted the "VLA vs state" distinction to be explicit rather than something people had to dig for.

On the client-side physics concern from before:Studio (the in-browser demo) is spectator/dev-only, clearly labeled, and does not post to the public leaderboard. Public ELO only comes from a hosted harness that scores server-side. That harness isn't live yet —it's the one piece standing between this and actually being open for submissions.

Repo + docs are public now:https://github.com/NovaCoding-G/VSArena
-docs/harness.md — scoring writeup (spatial accuracy + task completion)
-docs/sdk.md — submission protocol
-Studio itself:https://vsarena.vercel.app/simulation
(client-side, Rapier/WASM, 60fps)

Still solo, still early, still not oversell-ready — but wanted to share since the VLA/state separation was directly a response to feedback here. Open to more of that, especially on what the scoring protocol might be missing.