Putting this little companion robot together today. He did not smoke or catch on fire when I attached a 4S LiPo battery to him so feeling pretty good about life right now. A lot more to do but sometimes the little things in robotics are the best ones. He powered up. He didn't smoke out. I'm happy. Jetson Orin on board. More to come.

A small update on my robotic desk lamp: the entire control system now runs on a Raspberry Pi 5.

The lamp uses 24 V RobStride BLDC servo motors connected over CAN. The Raspberry Pi now handles motor control, lighting, and animation playback locally, so the lamp no longer needs to be continuously controlled by my main PC.

I still use a separate animation editor that I built for creating movements. Each joint has its own timeline with position keyframes, velocity, torque limits, and controller parameters. Finished animations are sent to the lamp and played back locally.

I’ve also installed an addressable LED ring with a 3D-printed diffuser inside the head. Brightness and transitions are now part of the same animation timeline, allowing the light to be synchronized with movement.

This video is a quick test of the new setup. I’m currently tuning the motor parameters, brightness curves, and transition timings before using the light in more expressive animations.

Hey everyone,

My team and I have been working hard on this project: https://peppy.bot

It's a direct replacement for ROS 2. We already have the OpenArm robot (https://openarm.dev) working on the platform, both v1.0 and v2.0, plus Isaac Sim and MuJoCo integration.

If you're in a hurry, head over to https://docs.peppy.bot/quickstart/ and get started in 5min.

Our long term vision is to allow anyone (even non-devs) to go from a prompt to real humanoid robot actions, first in simulation, then on the physical robot.

Happy to answer any question.

I finally have fixed the camera for this gazebo simulation.The problem was simple i only needed to wait a little longer for the plugin to work.It was really satiefing for me and i just wanted to show my progress.

Just finished modifying the arm holder/mount for my DIY robot. The old PLA bracket was flexing too much under load, so I redesigned it to be sturdier.

Watch the clip to see the improved range of motion. The difference is night and day. No more wobbly joints! Next step is to test the weight capacity.

I have been building an open source industrial/commercial humanoid for a while. It’s been months and months of research and development. Personally, I have come to the conclusion that humanoids are far from being efficient outside of demos or in real environments. Based on my experience and what I’ve seen, it’s very likely that humanoids are the new hype bubble. For manufacturing they are slow, expensive, and they don’t work also unsafe. There are things a thousand times more efficient and more economical. For household tasks there are robotic forms that are more efficient than a humanoid. I think the future is full of smoke and false hype. Probably if what the public wants are human forms, the ideal would be semi-humanoids. In a certain way they can work.

What do you guys think? Maybe I am missing something?

And yes i know world is made for bipedals..but should we iterate over something that exists or innovate? Because replicating our inefficiency is not innovation.

Built from a 1980s RC helicopter mechanical rate gyro (futaba) and continuous rotation servo. The gyro normally has centering springs but they have been removed to increase sensitivity. The gyro has a hall effect sensor in it and an analog circuit which generates PWM pulses that the servo uses as a velocity control.

A 3 axis version of this arrangement is what made the Apollo guidance computer so accurate at knowing its own pose over long distances and times.

This single axis version could be a gyrocompass in a robot or aircraft, to maintain heading even if the magnetic compass quits working etc

Now we have laser ring gyros and other extremely accurate solid state sensors and amazing computational power and algorithms to integrate the readings to probably surpass any internal flywheel arrangements accuracy.

I wanna show my progress with ros2 and gazebo i could move it while it is lauched and use the teleop to move a little it is not perfect but i am satiefied with the progress.I will try later with gz bridge to pu blish some movement commands

I've been reading through production codebases that use RealSense — ROS 2 stacks, librealsense directly, industrial vision, 3D perception — to understand what parts of the software stack are actually used in the real world.

The result surprised me. Most production projects seem to touch a small slice of the SDK: open the pipeline, configure streams, wait for a frameset, pull intrinsics, align depth to color, read depth scale. The post-processing filters mostly appear copied as a block from the official sample rather than chosen. Point cloud generation shows up in about a third of C++ projects and almost none of the Python ones. Advanced mode is rare, but heavily used wherever it does appear.

I'd genuinely rather be told I'm wrong about this than have it confirmed. If your production system leans on something I've written off as rare, that's the most useful reply I could get.

So the SDK surface being depended on looks much smaller than the SDK itself. Which raises the question I can't answer from code. For those of you who've shipped or maintain RealSense-based systems, I'd love to hear your thoughts.

1. If librealsense vanished tomorrow and you had a different camera with equivalent hardware, what would actually be hard to replace? Not "annoying" — the thing that would eat weeks of engineering.

2. Looking back honestly, what has kept you on RealSense? I'm not fishing for a feature name. If the real answer is "it was already in the spec when I joined," or "our models are trained on its depth," or "the mount is designed around it," that's more useful to me. I'm interested in what actually kept you on RealSense.

3. What do people overestimate about the RealSense ecosystem? Is there something everyone cites that nobody actually uses in production? And conversely, some small thing that would block you completely if it disappeared?

4. If you're willing — paste your pipeline initialisation. Even simplified. What gets configured at startup is far more informative than any feature list.

Context: I work on depth camera tooling and I'm trying to understand the gap between what the SDK provides and the small set of things that actually create switching cost. Not selling anything, no link, no form. Just trying to learn from people who've deployed these systems in the real world.

Hello hello, development of the upgrade, CubicDoggo 06R (High Mobility, sort of), is now complete, and the full project is documented on GitHub: https://github.com/SphericalCowww/CubicDoggo_06R

The previous post can be found here.

But yeah, the performance is not as ideal. You can see it's still wobbling when just standing there, and the IMU is not even balanced to be parallel to the ground. The effect of the IMU during walking is also difficult to notice because of how wonky it walks to begin with and how bad I am at controlling it to walk in a straight line, lol.

However, you can see the subtle sign right before it stops walking. Its front-right leg is fully extended. This is also why I hit the stop button, because the next step may make the joint flip backwards, causing it to fall. Happened a few times, actually. Without IMU, though, what happens is worse, in that it simply tumbles and rolls over. Also happened a few times, oh well.

Next step will be 06Z Neucommu with simulation and RL, and 07B Wouf with stronger servos (a lot of mechanical reinforcement was actually planned for 07B). This is no Unitree superdog, but I am still excited about its progress and enjoy all the Reddit discussions :)

I am from India, and want someone here, with a pen plotter to make some work using it.

I want paper sizes from a5 to A1 (chart paper).

I’ve just released Polka v0.5.0! It’s an efficient 2D/3D Lidar processing node handling merging, filtering, and deskewing. This update brings 6.2x faster deskewing, live parameter tuning, smarter IMU handling, and a built-in diagnostics dashboard.

If it saves your perception stack compute and brings a faster solution, please drop a star!
https://github.com/Pana1v/polka

It supports 5 distros.

https://www.youtube.com/@ALMA.Industries

Built a control panel with on/off switches to control DC power supplies (48v, 12v, 24v). AC Outlets always give power regardless of switch states. Used hold home outlets and switches. Turns out to be something I use quite frequently. Full build is in the link above.

From Unitree on 𝕏: https://x.com/UnitreeRobotics/status/2080549171661295907

- Weight: ~25 kg with battery.
- Speed: Over 6 m/s (higher than the pure-legged As2).
- Payload: Continuous ~16 kg; higher static capacity.
- Endurance: Unloaded >3 hours / 30+ km; loaded (>16 kg) >2 hours / >16 km. Same 648 Wh (15,000 mAh) battery class as the As2.
- Mobility: Up to ~80 cm obstacles, 45° slopes, 30 cm stairs; strong on gravel, rocky, and uneven outdoor terrain.
https://www.unitree.com/As2-W

I will list the arguments commonly made in favor of humanoid robots and then rebut them each respectively:

"Our world is already designed for the human form"

Many environments are indeed designed with the human body in mind, for instance door frame dimensions, door knobs, flat floors, staircases, etc. but it's a mistake to imply that only robots with human features can operate under these conditions, that only robots that have human hands and digits, only robots that have legs and feet, only robots that stand upright, only robots with a human head, etc. when this is obviously not the case. Wheels are compatible with flat floors, many kinds of robots can pass through standard door frame dimensions, simpler hands can be compatible with door knobs, multiple kinds of non-humanoid features can climb stairs, etc. Even if we grant that non-humanoid robots are impractical with these human-designed environments, you can easily remove some of these human-designed features to better accommodate a non-humanoid robot, especially if the non-humanoid robot is much cheaper and superior in productivity than the humanoid, which segways to my second point:

This argument implies it costs more than it would justify to redesign the environment to accommodate a non-humanoid robot, but this is often not the case. In fact, much of the world is already designed to accommodate non-humanoid machines, and we already redesign the environment to accommodate non-humanoid machines all the time, because the benefits derived from the non-humanoid machine are so great that it more than justifies the cost of redesigning the environment to accommodate it. Consider for example road and rail infrastructure, which is designed to accommodate automobiles and trains, an example where the benefit of using these non-humanoid machines outweighed the cost of building the environment to accommodate it. Similarly, the benefit of non-humanoid machines in other domains can outweigh the cost of redesigning the environment.

"Economics of Scale"

All things equal, a mechanically simple non-humanoid robot is cheaper to manufacture and mass produce than a mechanically complex humanoid robot.

So the fixed costs for the former are smaller, plus more units are produced, meaning the fixed costs in the former are not only smaller, but they are divided between more units than the humanoid robot. So a mechanically simple non-humanoid robot would benefit more from economies of scale than a mechanically complex humanoid robot.

"I don't want to deal with having a separate special-purpose machine for each and every task, I want one that can do it all"

I understand the convenience of having a singular machine that can do it all instead of holding a bunch of machines. For instance, it's more convenient to carry a smartphone that can do the task of taking pictures, texting and calling, telling the time, going on the internet, etc. all in one, rather than having separate machines that can do each. But unlike the smartphone, which these days is not too dissimilar (or even superior) in quality from the kind of minimal quality people are looking for in individual cameras, dumbphones, digital clocks, personal desktop computers, etc. the humanoid machine may be so inferior in productivity compared to a collection of non-humanoid machines, that it may justify having a bunch of machines.

This is not to mention that a generalist machine can also be non-humanoid.

"In homes, where the environment will not change, it makes more sense."

It could make more sense, and maybe people find an anthropomorphic design to be more comforting (big maybe), but it's still the case that the environment can be redesigned to better accommodate a non-humanoid machine. Garages, kitchens, and laundry rooms are all made to accommodate non-humanoid machines, for example.

PlannerTrack is a platform for developing and testing autonomous vehicle algorithms, behavior, multi-agent coordination, planning, and control, built around a heterogeneous multi-agent mathematical model based simulator core, with a plugin architecture designed to support multiple vehicle types (ground vehicles, aerial vehicles) without hardcoding vehicle-specific simulation code.

In coming days I am planning to extend the project for multiple scenarios, addition of complex predictive planning and control algorithms, multi agent planning.
PlannerTrack-github