Pose is position + orientation, but I've been trying to find if there is a standard term for pose + configuration of a robot.
ABB uses robtarget but I would be surprised if that's the standard term.
From looking into it I've found both "model" and "posture", but I have no idea if these are specific for a manufacturer or standards in robotics.
A mobile retail robot using an open-source robot arm to pick items from store shelves.
It’s a simple demo, but a nice example of real-world manipulation: finding the item, reaching into the shelf, gripping it, and placing it into the cart.
The open-source hardware angle makes it especially interesting for robotics builders.
Matthew Johnson-Roberson, Dean of the College of Connected Computing at Vanderbilt University and former director of the Robotics Institute at Carnegie Mellon, argues that physical AI may not follow the same path as large language models.
Language models had a clear training target: predict the next word. That gave researchers a simple objective that could be scaled across massive amounts of text.
Robotics does not appear to have the same equivalent yet.
A robot can collect large amounts of video, sensor and encoder data, but that does not automatically solve the harder problem: what should the system actually optimize for?
Predicting the next frame, joint angle or robot motion is not as universal as predicting the next word in a sentence.
Burnaby/Vancouver based and currently working on an autonomous drone project using ArduPilot, MAVLink, Raspberry Pi, computer vision, and onboard AI.
Looking to connect with FPV pilots, RC aircraft hobbyists, robotics/autonomy builders, or anyone around BC experimenting with similar projects.
Would love to exchange ideas, learn from others, and possibly test/fly/build together sometime.
Feel free to DM or comment if you’re local and into this kind of stuff.
From Unitree on 𝕏:
https://x.com/UnitreeRobotics/status/2056674074735354265
From Boston Dynamics on 𝕏 (thread with longer video):
https://x.com/BostonDynamics/status/2056344756926460103
https://xcancel.com/BostonDynamics/status/2056344756926460103
Blog post: Training a Humanoid Robot for Hard Work: https://bostondynamics.com/blog/training-a-humanoid-robot-for-hard-work/
Finally made it! 🎉
After 3 days of hard work and learning the basics of ROS2, I successfully built and simulated a 4x4 car model. 🚗
As a beginner, there was a steep learning curve, but the feeling of seeing it work makes it all worth it. Excited to keep building and expanding my skills from here! 💻🤖
#Robotics #ROS2 #Tech #ContinuousLearning #EmbeddedSystems
I built a rear obstacle avoidance system on the LIMO robot using the HM-LD1 dToF LiDAR. Mounted at the rear of the vehicle and powered by a Jetson Nano for real-time data processing, the system enables precise reverse obstacle avoidance — the robot automatically detects rear obstacles and comes to a stable stop before collision. Full source code will be open-sourced on GitHub.
New head and neck designs complete and assembled, the old head is now a nice souvenir.
With that out of the way the last phase of this project has begun, the legs. I just got a few actuators to help me polish the leg design and then test, i’m now waiting for rotary encoders to arrive so i can fully finish leg design.
Once i have the final design the next step will be to get the material for printing, wire everything and last to balance it and HOPEFULLY make it walk✌️
Hi guys,
I’ve been working on a small ROS 2 project for AMR/AGV-style mobile robots.
Problem:
A robot may still be receiving valid velocity commands, but its physical motion no longer matches the command stream.
Examples:
- wheel slip on wet / oily floors
- odometry mismatch
- localization jumps
- stale / bursty velocity commands
- robot starts shaking or over-correcting before safety lidar / hardware E-stop cuts in
A normal timeout only checks:
Did a command arrive recently?
It does not check:
Is the robot still moving according to the command it was just given?
So I built a small inline ROS 2 topic filter:
/cmd_vel → Kinematic Guard → /safe_cmd_vel
↑
/odom
It has a passive observe mode first, so it can run without taking over control.
Example status:
{
"status": "RESYNCING",
"causalAlignment": "BROKEN",
"dominantCause": "WHEEL_SLIP",
"guardAction": "BRAKE_AND_RESYNC"
}
The demo does not need a real robot, Gazebo, or Isaac Sim. It uses a lightweight mock AMR/AGV and injects wheel slip.
GitHub:
https://github.com/ZC502/ros2_kinematic_guard
ROS Discourse discussion:
https://discourse.openrobotics.org/t/detecting-execution-collapse-before-hard-e-stop-ros2-kinematic-guard-for-ros-2-amr-agv/54944
I’d be interested in feedback from people who have dealt with mobile robot slip, odometry jumps, or unexpected hard E-stop events in the field.
From Brett Adcock on 𝕏: https://x.com/adcock_brett/status/2056211711859003466
Maybe, this is the last time a human will ever win.
Hi everyone,
I’m an independent developer with a background in algorithms, HPC, and robotics infrastructure. Recently I’ve been working on a lightweight inference engine built around hand-written CUDA kernels, focusing on small-batch and real-time performance (especially for VLA and robotics workloads).
Here are some recent results on Thor and Blackwell:
The focus is on pushing true real-time inference under small-batch settings, which tends to be underserved by typical large-batch optimized stacks.
Still early, but happy to share more details or discuss if anyone is working on similar workloads 🙂
Feeback welcome！：https://github.com/LiangSu8899/FlashRT
We've just shipped v0.12.0 of `bonsai-bt`, and the big addition this release is live visualizations in the browser — you can now watch the state of your behavior tree update in real time as it ticks, including which nodes are running, succeeding, or failing.
For anyone unfamiliar: behavior trees are a great way to build deterministic AI — they're widely used for things like robotics control loops, game NPCs, and any agent that needs predictable, debuggable decision-making. The new visualizer makes it a lot easier to actually see what your tree is doing and catch issues without sprinkling print statements everywhere.
The visualizer is gated behind a feature flag. Add it to your `Cargo.toml` like this:
```toml
[dependencies]
bonsai-bt = { version = "0.12.0", features = ["visualize"] }
```
For more, see repo: https://github.com/Sollimann/bonsai
A lot of humanoid demos focus on walking, balance, and whole-body motion, but I keep coming back to the hand as the harder problem.
This demo shows a dexterous robotic hand doing object manipulation tasks. The hardware is interesting, but the bigger question for me is: what should a robot hand learn first if the goal is useful real-world manipulation?
Reliable pinch grasp? Tool use? Opening containers? Handling soft/deformable objects?
Curious what people here think is the best first benchmark for a general-purpose robot hand.
I recently joined Alignerr for a different technical role and noticed they’re looking for people with hands-on MuJoCo / robotics simulation / reinforcement learning experience.
The role seems best suited for people who have worked with MuJoCo, MJCF/XML, Gymnasium/dm_control, reward shaping, PPO/SAC/TD3, physics debugging, and robot control.
It’s remote contractor work. I don’t want to oversell it because project availability can vary, but the listed rate is high and it may be worth checking out if you already have this background.
I have a referral link, but only reach out if you genuinely have MuJoCo/RL experience — this probably isn’t a beginner-friendly role.