chfritz

cool. submitted something!

Awesome, congrats on the launch! Can you say more about the software stack? Is it open-source? I see you are using ROS on the robot, but what about the full-stack (robot + cloud + web)? Did you build all that yourself? At Transitive Robotics we are developing the Transitive open-source framework for full-stack robotics (complementing ROS, not replacing it). On top of Transitive it is easy to build capabilities and we already offer many such modules, e.g., for webrtc video-streaming, teleop, mission dispatch, etc. This means you don't need to build all that yourself and once Transitive is installed on a robot, your end-users can install more capabilities now or in the future. Do you think this could be of interest to your users?

https://transitiverobotics.com/docs/learn/intro/

AI is poisoning the well from which it drinks. If OSS withers or dies, what will AI train on to get better? Same with StackOverflow.

Interesting, I didn't know that! We've built this map display module but always thought of it as something only relevant for indoor robots. Do you think this might be relevant for outdoor as well then? https://transitiverobotics.com/caps/transitive-robotics/maps...

For what kind of robots did you design this? "several kilometers" implies that its not in-doors, but if it's outdoors, then why not just use a regular street-/satellite-map, such as leaflet, where setting points and lines is already built in?

ClickHouse is awesome. We use it to ingest robotics data at scale.

tl;dr: No need to simulate life for it to exist -- "it's the thought that counts".

I have been entertaining this thought for a while and finally wrote it down. Would love to hear what people think, in particular in terms of how this might relate to existing philosophical arguments. I'm also really interested in other fundamental results about logic itself, similar to Gödel's incompleteness theorem, that might add corollaries to this theory.

> the most critical sensor logs often get lost when a robot loses power

That seems like a bizarrely niche problem. I've been working in robotics for many years and I don't think this has ever been a problem for us. Why would a robot suddenly run out of power? Conversely, why would something interesting be happening right before the battery runs out? Are you perhaps focused on a very specific kind of robots like drones, where a physical crash can also knock out power?

If that person had been a roboticist, they would have known what to do: stand in front of the car. It would have saved the cat's life. And most non-roboticists will immediately recognize this as a solution, too: these cars obviously detect humans right in front of them very well and will not move in that case. By the way, the same would have worked better for most human drivers as well. Even if you yelled at a human driver that there was a cat under the car, it would not be a reliable solution because they may not hear or understand you. But they, too, would almost certainly not run you over if you stood in front of the car.

To be clear, I don't blame the witness for not doing this in the moment. And she probably has figured this out by now, too. I'm mostly pointing out that, as more and more people learn about robot taxis, more people will known how to help in such a situation, which is clearly what she wanted to do.

Let's divide-and-conquer! -- like all good CS algorithms do. /newest is very noisy but if you subscribe to just a "sliver" that you are interested in and review those submissions, then we can improve voting together very effectively. Personally I'm interested in robotics, so I just use this in my RSS reader and literally look at every submission (because it's not too much): https://hnrss.org/newest?q=robot%20OR%20robotics%20OR%20robo...

Is it fate? Spotify was just playing "Sunday (The Day Before my Birthday)" by Moby as I was reading this. Should I reach out?

Cool, but what's the news here?

Great article! Read the whole thing. No idea why this hasn't been up-voted more. I found it by filtering for robots/robotics.

Rule of thumb: Demos = as low as 10% reliable (read: we are showing you the successful cases). Product = 99% reliability required and even that is still not great (costly to operate and maintain, sub-par reviews from customers). So the answer to your question depends very much on the use-case and form-factor of the robot. Watching that Neo robot closing a dishwasher was so painful, and even that was still teleop-ed.

Another data point: in academia people thought robot localization was solved back in the 90's. In practice, mislocalizations has been an issue for robotics companies in the real-world until very recently. The number of 9's really matter and is where all the sweat is.

Not true! https://robotsguide.com/

No video encoder information! As a roboticist, the number one thing I look for when comparing SBCs is whether they have hardware encoders for h264 video. Pi4, Jetson Nano, and Orange Pi 5 all had one, but some newer boards like the Pi5 and Orin Nano don't. It would be awesome to have that part of the spec be included in the data/comparison.

This is your third question along those lines. Mind sharing your context? Are you trying to identify a need to build a company around or is this research more academic in nature?

You seem to describe the problem of automated anomaly detection. Many companies tried or are trying to solve this (e.g., Heex), but I don't think anyone has done it definitively. The issue is that "normal" behavior keeps changing, so its difficult to build a model of what is abnormal. And by the time the behavior of the robots in the fleet becomes more stable (in all aspects, physical, electrical, networking, logging, etc.), it's usually easy for the engineers who built it to put in the right metrics and health-monitoring checks to detect issues. So even though theoretically automated anomaly detection sounds like the holy grail of fleet observability, in practice, it's not such a big deal.

So I guess to answer your question, I think yes, the second, better tooling (and a ton of metrics data collected from the fleet with good versioning).

I assume you mean Orin Nano? (Jetson nano is EOL and only supports Ubuntu 18). Yes, we have users that run on Orin Nano and it's plug-and-play on any hardware. However note that the Orin Nano doesn't have hardware encoders, so it will take CPU cycles to encode the video, making it a less then ideal choice for teleoperated robots. Cheaper boards like the Orange Pi 5 are a better fit.

All the webrtc-features really only become relevant when you want to control the robot over the Internet, i.e., not just locally where you can assume reliable network.

with congestion control, packet loss mitigation, hardware accelerated encoding, multiple streams, teleop commands on the same channel (required for safety)? Do you host your own TURN server? My point is that robotics companies should focus and push the envelop on the application of their product, not reinvent the wheel on infrastructure and tooling.

Don't underestimate the challenges of making remote-teleop work reliably and efficiently with low-latency via the Internet: https://transitiverobotics.com/blog/streaming-video-from-rob....

Very cool! But I think we can help you improve your video-streaming and teleop (it seems to be pretty low frame rate in the demo). We've built the probably best remote teleop solution for robotics in the market today and it can be embedded anywhere (white-label). Want to get in touch to discuss? You can find my linkedin in my profile.

Thanks for sharing! You've clearly done your homework. Can you contact me, e.g., on LinkedIn? I'd love to explore with you whether what you want to build could benefit from the open-source framework we've built for developing new full-stack robotic capabilities (Transitive, https://transitiverobotics.com/docs/learn/intro/).

What's the news here? ROS came out 18 years ago. Maybe that's the news -- ROS is now considered an adult in many countries?

"automated error detection" -- how do you want to do that? How would you define "error". Clearly you are not just proposing to detect "error" lines in the log, because that's trivial. But if you don't, then how would you define and detect errors and auto-root-cause them? Maybe we can discuss at one of the next meetings.

This is something we are actively discussing in the Cloud Robotics Working Group right now. We've already had a number of sessions on this topic with various guest speakers. You can watch the recordings here: https://cloudroboticshub.github.io/meetings. Feel free to attend the upcoming meetings.

What's the reason you didn't use an existing slicing machine, like the ones used for slicing ham at the butcher? Reducing the number of custom made machines will greatly increase robustness later on all around (reliability, supply chain robustness, spare parts, skilled repair people...).

Teleportation or teleoperation? :D

$3000 with no compute included? a bit steep, no?

Anyone who thinks they can just "out work" the competition cannot be serious about innovation. Sure, you have to be willing to work hard sometimes, but its much more important to work smart, meaning, knowing where to go and how to get there efficiently and effectively. The latter can't happen if you are too busy to get a good nights sleep. Good ideas don't happen when your brain works on fumes.