I’m highly entertained by the way the robot tightens nuts. There is no way this would work in the real world :)
(This whole thing is awesome. I think they will need to get the number of rollouts needed down before it translates well to real robots — running hundreds of thousands of rollouts on small parts with a real rollout will be a real logistical mess when cleaning up parts on the floor and dealing with everything that the robots physically break while learning.)
We use sim2real with distillation-based transfer :)
This means no need to do the rollouts on real robots first! Please check out https://sgs-rl.github.io for some transfer examples (albeit a simpler setting then the multi-part NIST board we examine in AlphaNIST).
I know you are joking, but that is absolutely a possible trajectory. Reliable and cheap LLMs could lead to software that re-implements everything, instead of using libraries.
The starting states being at different points in the task and having success-guided starting state sampling seem like really neat ideas. I haven't kept up with RL in a while, how novel is this?
The mechanism is loosely related to curriculum learning, though we argue there are some distinctions. In the methodological companion paper (https://sgs-rl.github.io), we try to get into more details in the related work and baselines including comparison to methods like PLR (also from Deepmind), SFL, and linear handcrafted curriculums over states.
You are giving me some inspiration, though, that it might be good to try to explain the related techniques in a lower-dimensional setting to help teach the concept more effectively! brb
If you're interested in some more details, take a look at this post I made (and am admittedly still polishing) that discusses the method in a low-dimensional space. I am trying to make it more accessible to the community since explaining it for higher-dimensional robot control / hybrid-contact dynamical systems is a whole other thing :)
We can answer questions! But also, I want to highlight that the "AlphaNIST" name is an homage to the very well known work from David Silver's research group @ Deepmind circa 2016->2018. This was when we were coming up very early in our research careers and their work obviously had a big impact on us!
It has taken longer to make some of those ideas work for areas as challenging as robotics where there are physical constraints to deal with (and admittedly in this paper, we do not show the transfer to real hardware quite yet). But, we have some glimmer of evidence it is looking possible here (in another recent paper) that we cranked on for the last 6 months and will be featured at CoRL: https://x.com/octi_zhang/status/2108583315544682914
We are also all mega-lurkers here so we were honored to be featured on the front page!
Point received! We wonder what a better way to pay that same homage would be, since we followed the similar philosophy, but with considerations for our contact-rich robotic control setting.
Very cool line of work and emergent behaviors are so fascinating and solving NIST standard is very impressive! This just shows robot dexterity doesnt necessarily always need hands atleast for industrial assembly tasks.
Came across your CoRL publication before I found alphaNIST. I was curious how much simulation asset engineering and sysID/tuning was needed for transfer to the real robot?
Ensuring the assets are "CAD-level accurate" has a huge impact on making this work in practice. So much so, that our collaborators Yash Narang [1] and Iretiayo Akinola [2] have spent a number of years on just this - we are standing on the shoulders of giants!
Additionally, understanding the hardware well (including things like motor and controller dynamics) is non-negotiable. We learned the hard way that there is, in fact, no free lunch. You really have to get the deep understanding of physics and engineering right.
Really cool stuff. I especially liked the flicking behavior. Very organic movements.
In case somebody got the same question as me: the robot "sees" point clouds as input, so basically the full simulation state except for velocities (correct me if I'm wrong). As put in the limitations section, it "[does] not establish robustness to perception error, latency, or contact-model mismatch".
The movements of the robot gripper arm and its interaction with the longer objects ("Single-component assembly experiment", 1:00 and onwards) somehow really reminds me of how a horse moves it head.
31 comments
[ 1.5 ms ] story [ 55.8 ms ] threadAlphanist - Some app/lib/code that does something
HN guidelines are to use the title of the blog post and not editorialize.
(This whole thing is awesome. I think they will need to get the number of rollouts needed down before it translates well to real robots — running hundreds of thousands of rollouts on small parts with a real rollout will be a real logistical mess when cleaning up parts on the floor and dealing with everything that the robots physically break while learning.)
This means no need to do the rollouts on real robots first! Please check out https://sgs-rl.github.io for some transfer examples (albeit a simpler setting then the multi-part NIST board we examine in AlphaNIST).
It is not an Alphabet/Deepmind paper, and it also has nothing to do with the "NIST" OCR dataset.
Was there really not a more appropriate name than "AlphaNIST"?
Alpha historically had meant "Google DeepMind" not RL
Situation Soon: there are 15 trillion standards tailored to every possible situation.
You are giving me some inspiration, though, that it might be good to try to explain the related techniques in a lower-dimensional setting to help teach the concept more effectively! brb
https://rosarioscalise.com/garage-success-guided-sampling
We can answer questions! But also, I want to highlight that the "AlphaNIST" name is an homage to the very well known work from David Silver's research group @ Deepmind circa 2016->2018. This was when we were coming up very early in our research careers and their work obviously had a big impact on us!
It has taken longer to make some of those ideas work for areas as challenging as robotics where there are physical constraints to deal with (and admittedly in this paper, we do not show the transfer to real hardware quite yet). But, we have some glimmer of evidence it is looking possible here (in another recent paper) that we cranked on for the last 6 months and will be featured at CoRL: https://x.com/octi_zhang/status/2108583315544682914
We are also all mega-lurkers here so we were honored to be featured on the front page!
Ensuring the assets are "CAD-level accurate" has a huge impact on making this work in practice. So much so, that our collaborators Yash Narang [1] and Iretiayo Akinola [2] have spent a number of years on just this - we are standing on the shoulders of giants!
Additionally, understanding the hardware well (including things like motor and controller dynamics) is non-negotiable. We learned the hard way that there is, in fact, no free lunch. You really have to get the deep understanding of physics and engineering right.
[1] https://scholar.google.com/citations?user=M3NuG7AAAAAJ&hl=en [2] https://scholar.google.com/citations?user=e1zesfMAAAAJ&hl=en
In case somebody got the same question as me: the robot "sees" point clouds as input, so basically the full simulation state except for velocities (correct me if I'm wrong). As put in the limitations section, it "[does] not establish robustness to perception error, latency, or contact-model mismatch".