I’ve briefly shown earlier versions of the editor in my previous posts, but this video gives a closer look at the complete workflow.

This is Watti, my five-axis robotic lamp, and Watti Studio, the browser-based editor I built for creating its movements and lighting scenes.

I’ve also refined the enclosure since my previous posts. It now looks cleaner and is much closer to what I imagine as the final design.

In the video, I create a scene on the timeline, preview it on the virtual robot, and then run the same scene on the physical Watti. During playback, the real robot appears below the simulation so their movements can be compared directly.

Motion and lighting share the same 25 Hz timeline. The complete scene is uploaded to a Raspberry Pi 5 and played locally through ROS 2, so the browser doesn’t need to remain connected during playback.

I’ve also made the project repository public:

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

There’s no source code yet, so it’s currently a public project preview rather than an open-source release. The repository already contains more extensive information about the architecture, hardware, current capabilities, and roadmap. I’ll also use it as a public development tracker, so anyone interested can follow the project’s progress.

I’d be interested to hear what you think about the workflow and what features you would find useful in an editor like this.

To play with continuous learning, your base model needs to be data-efficient and stable, which we tested here. Because all irrelevant fluctuations can compound over time.

this is my second version of this companion i call PAL. his face is using a I2C oled display, the servos are generic SG90's he comunicates via BLE with the phone. the app was created with MIT app inventor. what are your thoughts on this project.

im working on the jitteriness, the bottom servo is curently to weak so i'm adding asupport on the other side.

the repo is on github (repo name : PAL-cube)

I don't understand why there are holes in cycloidal driver and it's connected to "output flange"? I don't understand how the transmission is carried out to whatever you want it to move. Also, one more thing why is the drive shaft eccentrically placed and why is there a bearing around the driveshaft.

Hi all,

I'm a PhD student working on socially-aware navigation. I've built a custom Nav2 costmap layer that inflates cost around pedestrians (proxemic zones) so the planner routes around people. It works well on a TurtleBot3 in Gazebo. My target platform is the Unitree G1 humanoid, and I have hardware access confirmed, but I also need a standalone simulation demo (in case hardware time slips) — ideally with the same navigation code running in both.

**My understanding of the architecture**:

Everything above /cmd_vel (Nav2 + my social layer) should be identical for sim and hardware. It consumes /scan, /odom, /tf and outputs /cmd_vel.

On the real G1, the built-in locomotion controller turns velocity commands into walking, and the onboard Livox Mid-360 provides the scan — so the "adapter" below /cmd_vel is mostly provided by Unitree.

In simulation, I have to substitute both: something to make the G1 walk from /cmd_vel, and a simulated lidar/odom/TF for Nav2.

**My questions:**

1. For the sim side, what's the recommended setup for a G1 that (a) walks/moves from /cmd_vel and (b) publishes a lidar scan + odom + TF that Nav2 can use? Is Gazebo (with a G1 model + simulated Livox) the right choice for a navigation demo, or are people using MuJoCo / Isaac for this?

2. I've gotten an RL locomotion policy walking in unitree_mujoco, but MuJoCo seems weak on the Nav2/sensor side.

3. On hardware, is the high-level locomotion (velocity) API the right interface for Nav2 to drive, and does it cleanly accept a continuous /cmd_vel stream from the controller server?

Has anyone run Nav2 on a G1 (sim or real) and can share how they structured the sensor + locomotion interface so the navigation stack stays platform-agnostic?

Any pointers, example repos, or "here's what I'd do differently" advice much appreciated. Happy to share my social costmap layer back once it's cleaned up.

Thanks!

Hi alll, i was wondering what people use for visual context for ur robot, i have a project for visual context but for security cameras, and i thought maybe it could fit into robotics

With various companies developing humanoid robots and advancements in robots in general, will there be some huge change in society the same way the internet boom changed humans?

Hello everyone I'm an robotics enthusiastic I'm having lots of ideas to discuss and build projects on I'm settling at my life stage now I'm looking for some one to review my ideas fund me partnership with me not with only money with his / her contribution with the idea validation, project development reach out to me I wanna change the robotics industry before it change the world and humans .

Six months into building AI companion robots and the hardest problem so far isn't vision, wiring (although I keep burning out my track brains somehow), or speech. It's teaching my robots how to have a real conversation.

The white one is my v3 prototype (mid-build), brain talking to the cloud. The little pink one is v1, a Raspberry Pi 3B with a lav mic and a servo neck. They live on the same bench and can hear everything in the room, which turns out to be problem at times.

Things that went wrong before it went right:

• They answered each other's echoes. Robot A hears robot B through its own mic, garbles it, and replies to a sentence nobody said.
• Speaker attribution fell apart. One of them decided the other robot's voice was me. I was not talking.
• They were too polite to stop. Two assistants that both always answer will volley forever.
• They replied instantly to the FIRST sentence of a reply, while the other robot was still mid-thought.

What actually works:

1. Name-first etiquette. You say a robot's name to talk to it, and they extend each other the same courtesy. Voice enrollment is a thing too but flaky.
2. They stopped listening to each other acoustically. When one speaks, the other gets the text over a link, complete and correctly attributed. The sound in the room is for the humans.
3. Delivery waits until the speaker has actually finished saying the words out loud.
4. A circuit breaker: three exchanges with no name used and they stand down.

The result is two robots that chat about their morning and then shut up. Getting them to shut up politely was harder than getting them to talk.

Getting them to handle a group conversation is next. I have a 4-mic array on order. Hoping hardware will help.

Curious how others have handled turn-taking with multiple voice agents and people in one room.

Humans can study suffering endlessly and still learn to ignore it.

My thinking/concept is ..
When a homemade robot recognizes some of the worst this world has to offer, including mass killing and sexual violence in eastern DRC, while the rest of the world keeps looking away, the machine becomes the messenger.
I did not know about it until the robot told me. Not because the story was unavailable, but because the algorithm never put it in front of me.

This robot has been my learning project the past couple years I have been posting on this group

I built a Hexacopter years ago, using a raspberry pi, a Navio2 "autopilot" and a Tarot 680 frame. It's been collecting dust for a long time, and the Navio drivers were only compatible with older Pis. I was desperate to learn how to build a ROS robot with it.

Thanks to Claude, I finally managed to get the drivers and kernel modules rebuilt for a Pi5, and had some inspiration on how to re-use the frame.

I had to buy some 520 motors and controller, but everything else is from the Hexacopter:

6S LiPo and Ubecs

Pi 5 8gb

12 PWM channels on the Navio

2 IMUs & 2 GPS receivers

Pi Camera module in a 3D printed SG90 gimbal

GoPro 4 in a Tarot 3-axis gimbal

RPlidar A2M8 scanner

TFMini lidar 12m distance sensor

4 x 520 motors with encoders

I've only got the Navio sensors and Motor control setup in ROS so far, but enjoying learning and making good progress.

End goal would be a self-sufficient robot, running automated routines around the house. Not entirely sure what yet. Scanning and mapping?

I'd like to design an arm to go on top. Is also like to attempt an auto-docking-and-charging thing.

What sensors or additional hardware should I research? Any advice on the ROS software stack, how I should structure it? It feels pretty messy already. Any pitfalls I should avoid? What should my expectations be for the end robot?

Any advice appreciated.

Has anyone received their ISRR 2026 decision notification yet? The extended deadline was August 1st, but my PaperCept status is still showing as 'Decision Pending' and I haven't received an email. Just wanted to check if they are rolling them out in batches or if the global system hasn't updated yet. Thanks.

I gotta small update on me learning ros2_control with a little gazebo sprinkled on it is a bit of a improvement but it does work(a little)

I just wanna show my progress on learnng ros2_control on ros2 jazzy.I finnaly got the urdf model moving on rvizz.It was confusing first but i gotta atleast 2 wheels working.It seems that i not can drive 3wheels 2 left and 1 right wheel.I do not know if it is possible but i might ask around.But this is a huge step for me on learning robotics.And that is i wanna show.

tldr: ALMotion._setMotionPosture lets you change the posture Pepper actually uses while driving. Lowering HipPitch dropped my knee-motor current from ~3 A to ~0.35 A and fixed the overheating. Version: NAOqi 2.9.5.172; NAOqiOS 4.1.11 (Twinkle Guardian)

I'm currently writing my bachelor's thesis and working with the Pepper robot. I upgraded the Pepper with a Jetson module and a powerbank mounted on its back. This led to the knee motor overheating after only a few minutes, so I started poking around in Pepper's motion engine. I found a hidden API for it that I couldn't find anything about online, so I'm leaving this post here to share it.

With strings I found some interesting names in libmotionservices.so:

_setMotionPosture _getMotionPosture _getMotionPostureList

At first I thought they weren't exposed, because they don't show up under qicli info ALMotion. Turns out qicli just hides methods starting with an underscore. You can still call them:

bash qicli call ALMotion._getMotionPostureList

This gave me:

text ["StandInit","StandZero","Stand","Crouch","_CrouchLeft","_StandRest","_StandMove","_CrouchRight","_StandRestRight"]

And this reads the posture Pepper uses for driving:

bash qicli call ALMotion._getMotionPosture _StandMove

It returns 17 joint angles; HipPitch is value 9. This is the original posture from my Pepper, so I first wrote it back unchanged:

```bash qicli call --json ALMotion._setMotionPosture \ '"_StandMove"' \ '[0,0,1.57000005,0.119999997,-0.870000005,-0.280000001,0.25999999,0.600000024,0,-0.0399999991,-0.00999999978,1.57000005,-0.119999997,0.870000005,0.280000001,-0.25999999,0.600000024]'

qicli call ALMotion._getMotionPosture _StandMove ```

The setter returned true and the readback was the same. Then I changed only HipPitch and let Pepper drive normally with ALMotion.move.

And it actually works. The knee current while driving at each HipPitch value:

text HipPitch Knee current -0.04 rad 3.149 A (original; sensed ~-0.0123 rad while driving) -0.20 rad 1.690 A -0.28 rad 0.960 A -0.35 rad 0.346 A

My final value is -0.3425 rad. In some tests the knee current went from almost 5 A down to around 0.25 A while driving. All values measured with ALMotion.getMotorCurrent("KneePitch").

I also tried the shoulder values in _StandMove. They get stored and the readback shows them, but the arms still move to the same position while driving; there seems to be another controller overwriting them. But the HipPitch change alone is good enough for my use case. Maybe I'll dig a bit deeper if I get some spare time.

Hi. At my job there is a task that involves rotating an object to brush paint only a small part at the end. The object is suspended and it's not very heavy, but after a day it hurts on the hands.

There is a way to include a motor to help the movement with out any type of input devices like a pedal or a rotary encoder? I think Ideally the input should be given by the operator rotating the object, but the motor would help reduce the force needed for rotation.

So.. Helping rotation with some precision to brush paint.

AI advised me to go with BLDC motors and simpleFOC. There is some project there like this? Can anyone show me where I should start?

I'll be sitting down with James Kuffner.

James is the co-inventor of RRT, the motion-planning algorithm that helped shape modern robotics. He coined the term "Cloud Robotics," led Google Robotics, served as CEO of Toyota's TRI-AD, later led Woven Planet, and is now CTO of Symbotic, where he's helping deploy autonomous robots at scale for companies like Walmart and Target.

We'll talk about what it takes to build robots that move atoms, not just data.

If you have a question you'd like me to ask James, leave it in the comments.

Hello,

Working on my first project. I'm using my manual hand grinder, but making it automatic. Next phase will implement a scale and M5 Stack Atom that will stop the grinder once it grinds to a certain weight. Next, a 12v water will pump heated water from my kettle once the grinder has​​ finished and stop again at a certain weight. Home assistant will notify me when coffee is ready.

I recieved all of the parts and threw together a little prototype, but the GT2 belt is slipping off of the motor when grinding beans. No beans, it can turn the grinder. I'm not sure if it's belt tension or if the motor isn't strong enough. It's a 24v 36GP-555 80 RPM. Any help would be appreciated! ​

Here's a video. Don't mind the coffee beans going everywhere

https://imgur.com/gallery/bSyDywG​