Hi Hello Robot Team! Stretch has been a joy to work with: it’s a winning combo of solid, simple hardware combined with extensibility and open-source software. Based on our lab’s experience using it, I had a few suggestions for future models.
As LLMs and VLMs take off, a separate GPU computer is becoming a necessity for things like stretch_ai, but this is difficult for deploying in real environments where there may not always be reliable high-bandwidth WiFi. I’m aware of the Jetson Orin backpack solution, but in my personal opinion it would be far better if the Jetson was an option for the onboard computer instead of the NUC. Sure, it’s ARM, but in 2025 that has pretty solid support and it’s what most commercial robots are using now. My only concern might be power consumption, but that could be managed with different power profiles.
Also, I think a big limitation of the current Stretch models is bandwidth. Only the head camera is able to operate at its full resolution and frame rate because of its USB3 connection, while everything else is USB2. I think there could be a lot of potential for using Stretch in VR, but it’s currently not possible to get the high frame rates and resolution that would make for a fluid, immersive experience without routing cables from the base.
I understand why the shoulder and end effector are tricky to do with USB3, since the cables need to move around internally and USB3 cables can’t bend as easily. But it seems like that shouldn’t be an issue for the USB port on the robot’s head.
A potential solution could be integrated with the NVIDIA Jetson: GMSL. It would solve the cable flexibility issues and be more reliable for high-bandwidth data. I can see how these additions could add some cost, but for a marginal price bump I think the benefits would be worth it for Stretch 4 or a Stretch 4 “Pro Edition”. (edit: I realize this wouldn’t solve things for the d405. They make a GMSL variant of the d455 but not the d405).
Also, a tiny quality of life suggestion: a power button! I know it’s recommended to power down the NUC before switching off the robot, but this can be difficult if you’re deploying the robot without a researcher available to run a sudo shutdown command.
Stretch community or staff, feel free to chime in with feedback or additional suggestions!