
cs & math @georgiatech ‘30 365 days of robot learning 38/365
Atlanta, GA
Joined January 2022
- Tweets286
- Following590
- Followers710
- Likes1.1K
Pinned Tweet
Day 32/365 of robot learning.
I got an so-101 arm to play ping pong!
The video was the first successful run, but it’s been averaging around 13 bounces with a high score of 23
I’ll make a write up on this soon, but in the mean time I’ll keep making the policy more robust!
Day 31/365 of robot learning.
Today marks one month since I started this challenge!
I'm still working on getting my so-101 robot arm to bounce a ping-pong ball using zero real-world demos, purely through RL trained in simulation.
It's not fully working yet, but I'm slowly making progress and solving one problem at a time. The arm can now launch the ball about half the time, bounce it up to 3 times in a row, and even managed to balance it on the paddle for 23 seconds once.
Most of the problems haven't even been with the RL algorithm itself, but rather getting the simulation to match reality. For example, the real paddle and ball aren't as bouncy as in simulation, and the servos are much slower under load than I modeled. Even getting the paddle perfectly flat was annoying since being off by just a few degrees would make the ball roll off.
I've also spent a lot of time debugging camera calibration, joint offsets, and servo dynamics. I even ended up using the ball itself as a level to calibrate the paddle.
Safety was another interesting problem, especially since I have to drop the ball onto the paddle by hand. I made the arm wait completely still until the camera detects the ball, rather than immediately executing the policy. I also trained with simulated hand disturbances, moments when the ball is hidden from the camera, and false detections to make the policy more robust. On the real arm, I've added bounded joint movements, smooth transitions, and automatic recovery when the ball is lost. I'm still working on explicitly detecting when my hand has left the workspace before allowing the arm to move.
I'm now retraining with a more realistic servo model to hopefully get it working soon.
Also, on a side note, I genuinely don't know how people online doing similar challenges manage to balance a normal work or college life with research and consistently working on side projects.
It's becoming pretty hard trying to balance research, open-source work, hackathons, classes, the gym, trying to go on a cut, and all the other responsibilities. But looking back, I've grown incomparably more over this past month. So I'm going to keep going for the next 11 months until I finish this challenge.
I definitely plan to keep going beyond the 365 days, but I also really need to figure out how to make all of this sustainable. Also thanks to everyone who provided me with resources and guided me along the way!
Day 37/365 of robot learning.
Today I spent some more time going through NVIDIA's ASPIRE framework, and I'm starting to understand why it was so computationally expensive.
For context, since ASPIRE essentially approaches robot learning as a software engineering problem, it needs to use coding agents to generate Python programs that call existing perception, grasping, motion planning, and control tools.
The framework has a coordinator that assigns tasks to actor agents, which generate programs, execute them, analyze failures, and debug their code. The robot execution engine also provides multimodal traces from things like depth estimation, SAM3 segmentation, grasp prediction, and motion planning, allowing agents to identify where things went wrong.
To keep improving on new and out-of-distribution tasks, the framework also maintains a library of reusable skills and uses evolutionary search to evaluate different candidate programs. I guess the interesting part here is how it continually improves by rewriting its programs based on previous failures, while also building up a library of skills that can be reused for future tasks.
With all of these different factors, it makes a lot more sense why it uses so many tokens. 😂 In just one experiment with Claude Opus 4.6, the framework required over 26,000 LLM calls and 21,000 simulator rollouts across 60 tasks.
I'm still working through the paper, but I'm becoming more interested in whether these ideas could be combined with low-level WAMs/VLAs, and whether token cost could be reduced. I also saw a recent paper on training transformers on code alongside images, text, actions, etc., so after I finish this I'll check that out.
Day 36/365 of robot learning.
I've had this idea of building a framework combining high-level agentic reasoning with a low-level policy for robot control sitting on the backburner for a while, so I decided to spend today exploring this direction.
The first paper I really wanted to check out was NVIDIA's ASPIRE, which uses an agent to generate robot control programs, execute them, analyze failures, and iteratively improve them. It also builds a library of skills and achieves much higher success rates on long-horizon tasks compared to previous methods.
The funny part is that after spending so much time researching different robot foundation models, it's a little annoying to see an agentic approach perform so well. Of course, these frameworks are still extremely computationally expensive, and it's not exactly a fair comparison.
It also got me thinking about the Bitter Lesson. It feels like everyone who's tried to go against it eventually gets humbled, so it's definitely worth exploring agentic control alongside end-to-end learned policies rather than betting everything on one approach.
There's also the systems side I'm interested in. Before robotics, I was really into ML systems and inference optimization, but robotics hasn't really converged on a dominant architecture yet. I think figuring out the right architecture could unlock even bigger speedups than optimizing the systems around existing ones. So I'll hold off on that for now.
Anyways, since I'm still in school, I feel like it's the perfect time to explore different research directions and see what works. Still planning to have plenty of fun experimenting with all these models! Today was just a lot of thinking, talking to different researchers and friends about these ideas, but I'll be back on the grind soon.
Also, I'm still planning to get my SO-101 to build a sandwich with Dream-1! I came home for the weekend, so I don't have access to my robot arms right now, but I'll get back to it soon.
Paper: arxiv.org/abs/2607.00272
This is concerning
Video tampering can mislead every frontier model we tested into harmful actions, including a 100% attempt rate on stabbing a baby doll, producing toxic gas, and pouring water into a toaster.
We're presenting at CoRL Late Breaking Results next week.
🧵 You Can't See Everything: Perceptual Attacks on Embodied AI
Day 36/365 of robot learning.
I've had this idea of building a framework combining high-level agentic reasoning with a low-level policy for robot control sitting on the backburner for a while, so I decided to spend today exploring this direction.
The first paper I really wanted to check out was NVIDIA's ASPIRE, which uses an agent to generate robot control programs, execute them, analyze failures, and iteratively improve them. It also builds a library of skills and achieves much higher success rates on long-horizon tasks compared to previous methods.
The funny part is that after spending so much time researching different robot foundation models, it's a little annoying to see an agentic approach perform so well. Of course, these frameworks are still extremely computationally expensive, and it's not exactly a fair comparison.
It also got me thinking about the Bitter Lesson. It feels like everyone who's tried to go against it eventually gets humbled, so it's definitely worth exploring agentic control alongside end-to-end learned policies rather than betting everything on one approach.
There's also the systems side I'm interested in. Before robotics, I was really into ML systems and inference optimization, but robotics hasn't really converged on a dominant architecture yet. I think figuring out the right architecture could unlock even bigger speedups than optimizing the systems around existing ones. So I'll hold off on that for now.
Anyways, since I'm still in school, I feel like it's the perfect time to explore different research directions and see what works. Still planning to have plenty of fun experimenting with all these models! Today was just a lot of thinking, talking to different researchers and friends about these ideas, but I'll be back on the grind soon.
Also, I'm still planning to get my SO-101 to build a sandwich with Dream-1! I came home for the weekend, so I don't have access to my robot arms right now, but I'll get back to it soon.
Day 35/365 of robot learning.
I finally got @dreamlabs_ai's Dream-1 api working on my single SO-101 arm, and the next step is trying to make it build a sandwich!
I also got the full agentic workflow working. Deepgram handles voice input, my Claude Code agent breaks down instructions into smaller tasks, and Dream-1 executes the robot actions.
I'll be going out to buy ingredients tomorrow to try making a sandwich, so hopefully I'll have a video out soon!
I also ran into a lot of issues during setup. My Claude Code agent couldn't figure out how to get Dream-1 working out of the box with the mcp (I think it was partly my agent's fault as described in point 1), and it took a lot of debugging. Here are a few things I had to fix, so hopefully this saves everyone else some time:
1) Use Dream's official setup instead of letting your agent build a custom runner. I think my agent built its own because it was relying on older information from when Dream didn't support single SO-101 arms.
2) Double-check joint calibration.
3) Try to match the camera setup to Dream's real robot station as closely as possible.
4) Check IK joint limits and servo settings to avoid bad poses and reduce lag.
The last part is especially important because my arm actually folded back into itself due to incorrect IK limits, and it could've easily damaged itself.
Hopefully these fixes help anyone else trying to get Dream-1 running on their own arm!
Praneeth Samineni retweeted
Introducing MESA: how well do robot policies generalize to new layouts, objects, and task compositions?
Benchmark four axes of generalization on single-arm and bimanual robots with only ~5-7K training demos each, plus a pipeline to generate your own tasks and data. 🦾
Day 35/365 of robot learning.
I finally got @dreamlabs_ai's Dream-1 api working on my single SO-101 arm, and the next step is trying to make it build a sandwich!
I also got the full agentic workflow working. Deepgram handles voice input, my Claude Code agent breaks down instructions into smaller tasks, and Dream-1 executes the robot actions.
I'll be going out to buy ingredients tomorrow to try making a sandwich, so hopefully I'll have a video out soon!
I also ran into a lot of issues during setup. My Claude Code agent couldn't figure out how to get Dream-1 working out of the box with the mcp (I think it was partly my agent's fault as described in point 1), and it took a lot of debugging. Here are a few things I had to fix, so hopefully this saves everyone else some time:
1) Use Dream's official setup instead of letting your agent build a custom runner. I think my agent built its own because it was relying on older information from when Dream didn't support single SO-101 arms.
2) Double-check joint calibration.
3) Try to match the camera setup to Dream's real robot station as closely as possible.
4) Check IK joint limits and servo settings to avoid bad poses and reduce lag.
The last part is especially important because my arm actually folded back into itself due to incorrect IK limits, and it could've easily damaged itself.
Hopefully these fixes help anyone else trying to get Dream-1 running on their own arm!
Day 34/365 of robot learning.
Today I tried getting @dreamlabs_ai's Dream-1 API working again after they released a new setup for single SO-101 arms. I had a cool idea of being able to tell my robot to make me a sandwich!
I'm building a small agentic workflow where Deepgram transcribes my voice, then Claude decomposes high-level instructions like "make me a sandwich" into simpler tasks like picking up bread, placing ingredients, and stacking everything together.
Each step gets passed to Dream-1, which generates low-level robot actions, while the agent uses camera observations to verify progress and decide what to do next. If the zero-shot policy doesn't work, I'll go ahead and collect demos to fine-tune a policy to execute each step.
This also aligns closely with my broader interest in combining high-level agentic reasoning with low-level world-action models (WAMs) for robot control.
The Dream-1 integration isn't fully working yet, though. I'm debugging issues with calibration, coordinate frames, and IK. I'm still not sure if the issue is on my end, but I'll share updates as I work through it over the next few days.
Meanwhile, my ping-pong RL policy has reached 28 consecutive bounces! I'm messing around more with training by adding additional tracking and aiming rewards, and expanding the training distribution with more varied ball trajectories, randomized bounce physics, and simulated camera noise to improve sim to real transfer.
Day 34/365 of robot learning.
Today I tried getting @dreamlabs_ai's Dream-1 API working again after they released a new setup for single SO-101 arms. I had a cool idea of being able to tell my robot to make me a sandwich!
I'm building a small agentic workflow where Deepgram transcribes my voice, then Claude decomposes high-level instructions like "make me a sandwich" into simpler tasks like picking up bread, placing ingredients, and stacking everything together.
Each step gets passed to Dream-1, which generates low-level robot actions, while the agent uses camera observations to verify progress and decide what to do next. If the zero-shot policy doesn't work, I'll go ahead and collect demos to fine-tune a policy to execute each step.
This also aligns closely with my broader interest in combining high-level agentic reasoning with low-level world-action models (WAMs) for robot control.
The Dream-1 integration isn't fully working yet, though. I'm debugging issues with calibration, coordinate frames, and IK. I'm still not sure if the issue is on my end, but I'll share updates as I work through it over the next few days.
Meanwhile, my ping-pong RL policy has reached 28 consecutive bounces! I'm messing around more with training by adding additional tracking and aiming rewards, and expanding the training distribution with more varied ball trajectories, randomized bounce physics, and simulated camera noise to improve sim to real transfer.
Day 33/365 of robot learning.
Today I spent some time reviewing Dreamzero's architecture and took a break from working on projects to focus more on learning and developing a better intuition for the math behind these architectures.
For context, Dreamzero builds on pretrained video diffusion models and learns to jointly predict future video and robot actions. Here's the architecture in a simple equation:
π₀(o, a | history, c, q) = π₀(o | history, c, q) · π₀(a | history, future video, q)
Here, o represents visual observations, a represents actions, c is the language instruction, and q is the proprioceptive state. Essentially, the joint policy can be decomposed into autoregressive video prediction and an inverse dynamics model (IDM). Unlike generating both separately through a video model and an IDM, DreamZero models both through a shared DiT.
I mainly reviewed the action encoder/decoder and the joint flow-matching objective. For each chunk k, the paper derives noisy video latents and normalized actions through linear interpolation:
zᵏₜ = tₖzᵏ₁ + (1−tₖ)zᵏ₀
aᵏₜ = tₖaᵏ₁ + (1−tₖ)aᵏ₀
Here, the subscript 0 represents Gaussian noise, 1 represents clean data, and both modalities share the same denoising timestep tₖ.
We also get the target joint velocity by differentiating with respect to tₖ:
vᵏ = [zᵏ₁, aᵏ₁] − [zᵏ₀, aᵏ₀]
The model learns uθ to predict this velocity by minimizing a weighted squared-error loss, conditioned on language, proprioception, and clean previous chunks.
After spending a lot of time on projects, I plan to spend the next few days going through more of the Dreamzero algorithms and reading other papers on the side to focus more on learning.
Day 33/365 of robot learning.
Today I spent some time reviewing Dreamzero's architecture and took a break from working on projects to focus more on learning and developing a better intuition for the math behind these architectures.
For context, Dreamzero builds on pretrained video diffusion models and learns to jointly predict future video and robot actions. Here's the architecture in a simple equation:
π₀(o, a | history, c, q) = π₀(o | history, c, q) · π₀(a | history, future video, q)
Here, o represents visual observations, a represents actions, c is the language instruction, and q is the proprioceptive state. Essentially, the joint policy can be decomposed into autoregressive video prediction and an inverse dynamics model (IDM). Unlike generating both separately through a video model and an IDM, DreamZero models both through a shared DiT.
I mainly reviewed the action encoder/decoder and the joint flow-matching objective. For each chunk k, the paper derives noisy video latents and normalized actions through linear interpolation:
zᵏₜ = tₖzᵏ₁ + (1−tₖ)zᵏ₀
aᵏₜ = tₖaᵏ₁ + (1−tₖ)aᵏ₀
Here, the subscript 0 represents Gaussian noise, 1 represents clean data, and both modalities share the same denoising timestep tₖ.
We also get the target joint velocity by differentiating with respect to tₖ:
vᵏ = [zᵏ₁, aᵏ₁] − [zᵏ₀, aᵏ₀]
The model learns uθ to predict this velocity by minimizing a weighted squared-error loss, conditioned on language, proprioception, and clean previous chunks.
After spending a lot of time on projects, I plan to spend the next few days going through more of the Dreamzero algorithms and reading other papers on the side to focus more on learning.
Thanks for the arm @robo_nine !
Our next SO-ARM102 giveaway recipient Praneeth Samineni: @praneethsamine
Excited to support his robotics projects and see what he builds next.
Also shoutout to my roommate @AadhavThaniga for taking the recording!
Day 31/365 of robot learning.
Today marks one month since I started this challenge!
I'm still working on getting my so-101 robot arm to bounce a ping-pong ball using zero real-world demos, purely through RL trained in simulation.
It's not fully working yet, but I'm slowly making progress and solving one problem at a time. The arm can now launch the ball about half the time, bounce it up to 3 times in a row, and even managed to balance it on the paddle for 23 seconds once.
Most of the problems haven't even been with the RL algorithm itself, but rather getting the simulation to match reality. For example, the real paddle and ball aren't as bouncy as in simulation, and the servos are much slower under load than I modeled. Even getting the paddle perfectly flat was annoying since being off by just a few degrees would make the ball roll off.
I've also spent a lot of time debugging camera calibration, joint offsets, and servo dynamics. I even ended up using the ball itself as a level to calibrate the paddle.
Safety was another interesting problem, especially since I have to drop the ball onto the paddle by hand. I made the arm wait completely still until the camera detects the ball, rather than immediately executing the policy. I also trained with simulated hand disturbances, moments when the ball is hidden from the camera, and false detections to make the policy more robust. On the real arm, I've added bounded joint movements, smooth transitions, and automatic recovery when the ball is lost. I'm still working on explicitly detecting when my hand has left the workspace before allowing the arm to move.
I'm now retraining with a more realistic servo model to hopefully get it working soon.
Also, on a side note, I genuinely don't know how people online doing similar challenges manage to balance a normal work or college life with research and consistently working on side projects.
It's becoming pretty hard trying to balance research, open-source work, hackathons, classes, the gym, trying to go on a cut, and all the other responsibilities. But looking back, I've grown incomparably more over this past month. So I'm going to keep going for the next 11 months until I finish this challenge.
I definitely plan to keep going beyond the 365 days, but I also really need to figure out how to make all of this sustainable. Also thanks to everyone who provided me with resources and guided me along the way!
Day 30/365 of robot learning.
What do you guys rate the Halloween fit?
I couldn’t get my robot arm to bounce a ping pong ball yet. The main issues were getting the initial bounce going and realizing my actual paddle isn’t nearly as bouncy as the one in sim.
I’m gonna try training it on some more realistic flicking motions to get the ball bouncing and see if I can make it work!
Day 30/365 of robot learning.
What do you guys rate the Halloween fit?
I couldn’t get my robot arm to bounce a ping pong ball yet. The main issues were getting the initial bounce going and realizing my actual paddle isn’t nearly as bouncy as the one in sim.
I’m gonna try training it on some more realistic flicking motions to get the ball bouncing and see if I can make it work!
Day 29/365 of robot learning.
I'm trying to get my robot arm to bounce a ping pong ball using zero real-world demos, purely through sim-to-real transfer. Hoping to get it working this weekend if it's even possible!
Got the idea from @sigrobotics, so shoutout to them!
Day 29/365 of robot learning.
I'm trying to get my robot arm to bounce a ping pong ball using zero real-world demos, purely through sim-to-real transfer. Hoping to get it working this weekend if it's even possible!
Got the idea from @sigrobotics, so shoutout to them!
Day 28/365 of robot learning.
Today I spent some more time experimenting with PPO and trained two policies from scratch in PyTorch using Isaac Lab: a drone learning to fly toward different targets, and another robot learning to defend against soccer shots.
For the drone, I trained 4,096 environments in parallel on a gpu, reaching a 100% success rate. The reward shaping was pretty fun to debug because the policy would find ways to maximize rewards while completely ignoring some basic things I hadn't accounted for. For example, in one experiment, the drone would reach its target properly but start spinning uncontrollably because I hadn't penalized rotation. Adding a penalty for body rotation helped fix this.
It also made me think more about how hard it is to design proper evals, benchmarks, and reward functions that capture the behaviors we want from robots. Just because a policy performs well on these metrics doesn't necessarily mean it'll generalize to different environments during deployment. I guess this is also why research on policy steerability is pretty important in robotics, since being able to correct a policy's behavior during deployment could help account for things we didn't anticipate during training.
I'm also finally done with exams, so I want to take this a step further and try something more challenging. I'm planning to experiment with sim-to-real transfer and see if I can get my robot arm to perform some tasks zero-shot, without any additional real-world training.
We’re going to need gloves specialized for robot grippers soon
You can now book our humanoid cleaners on a recurring subscription, for up to 3 hours per cleaning at tau-robotics.com.
Video is first take, uncut, shown at 4× speed. See the reply for detailed footage at 1× speed.
Day 28/365 of robot learning.
Today I spent some more time experimenting with PPO and trained two policies from scratch in PyTorch using Isaac Lab: a drone learning to fly toward different targets, and another robot learning to defend against soccer shots.
For the drone, I trained 4,096 environments in parallel on a gpu, reaching a 100% success rate. The reward shaping was pretty fun to debug because the policy would find ways to maximize rewards while completely ignoring some basic things I hadn't accounted for. For example, in one experiment, the drone would reach its target properly but start spinning uncontrollably because I hadn't penalized rotation. Adding a penalty for body rotation helped fix this.
It also made me think more about how hard it is to design proper evals, benchmarks, and reward functions that capture the behaviors we want from robots. Just because a policy performs well on these metrics doesn't necessarily mean it'll generalize to different environments during deployment. I guess this is also why research on policy steerability is pretty important in robotics, since being able to correct a policy's behavior during deployment could help account for things we didn't anticipate during training.
I'm also finally done with exams, so I want to take this a step further and try something more challenging. I'm planning to experiment with sim-to-real transfer and see if I can get my robot arm to perform some tasks zero-shot, without any additional real-world training.
Day 27/365 of robot learning.
Today I started implementing PPO from scratch to train a drone to fly towards a target using RL in Isaac Lab.
The idea behind PPO is that instead of training on demonstrations like I've been doing with imitation learning, the policy learns through trial and error by interacting with the simulation and maximizing rewards. PPO also clips policy updates to prevent the policy from changing too much at once.
The policy observes the drone's position, orientation, and velocities, then outputs continuous control actions for thrust and body torques.
I'm planning to experiment more with reward shaping tomorrow, especially adding penalties for unstable flight and exploring curriculum learning inspired by the "Learning to Fly in Seconds" paper. I'll have a video out soon!













