chfritz

It looks like you are not yet using webrtc for streaming. We should talk. Or you can just try out the webrtc video streaming solution we've built specifically for robotics, plus teleop if you want. https://transitiverobotics.com/caps/transitive-robotics/remo... If you want to learn more about the various ways to stream video from robots and why your (I think) frame-by-frame approach is not ideal, you can read this: https://transitiverobotics.com/blog/streaming-video-from-rob...

+100 on this! My choice of glasses (and prescription) has nothing to do with my choice of how to talk to my computer. Don't risk failure just because you make them depend on each other.

Seems more like revenge than revolution? Why not just move on?

When should I use this vs Google Fonts?

"Real API calls, real latency, real bills. Caveats are stated, not buried." -- Gosh, who talks like this? No human would. Claude does. Wannable confident, arrogant, and super annoying. Stated, not implied. ;-)

very cool! I'd be curious how some songs I know sound like, e.g., Stairway to heaven, nothing else matters, etc.

We've added support for VR controllers and mouse gestures to our Transitive Remote Teleop capability. This means you can now control your robotic arms over the internet from anywhere in the world (with live video and low latency).

New documentation re. arms: https://transitiverobotics.com/caps/transitive-robotics/remo...

Full description: https://transitiverobotics.com/caps/transitive-robotics/remo...

Looking forward to your feedback.

Congrats on the launch! At Transitive Robotics we make full-stack modules so robotics companies like you can build their operational systems faster and with greater quality. We have a number of modules you might be interested in, e.g., for remote video-streaming and tele-op/-assist: https://transitiverobotics.com/caps/. Let me know if you want to chat.

Very much besides the point. The point being that automation often enables other things, not just making the thing they automate directly more efficient.

"So if you can't collect enough data before building, and simulation won't give it to you, where does the data come from? Goldberg's answer is what he calls the data avalanche: build a working system using engineering plus some learning, ship it, then let production generate the training data." -- agreed! This is also the approach taken by Field AI if I'm not mistaken. Rather than calling it the data avalanche, you could also just describe it as "learning by doing".

nice idea and setup, but it doesn't work. I can request control, it will say "you are next" or similar, and then right away "time's up, return to games". I never get control.

Another one? What's wrong with the one by IEEE? https://robotsguide.com/robots

love the synthwave soundtrack! So full of action and out of style for chess, it's hilarious.

great idea! Now, you are running into the same issue Google Trends had to solve: term disambiguation. For instance, "atom" is ambiguous in a comparison of editors like this: https://hackernewstrends.com/?q=sublime&q=atom&q=vscode. Given LLMs it might be possible to use an embedding vector (with context) instead of a text string for indexing, and if you do, this problem might go away.

how is this different from using puppeteer to load the page and save the DOM as HTML?

A script or program is not a robot.

Almost definitely 100% teleoperated -- the robot might move between places autonomously, but all the manipulation tasks, i.e., the actual cleaning, is not something anyone yet knows how to do autonomously reliably. And that's OK. However I'd like to know whether the data you gather from these cleanings is shared with other companies (who would be willing to pay a lot of money for it in order to train their own physical AI models).

What a silly idea. Technology moves 20x faster than the legislature. There is no point in even trying this. By the time any suggestions would get implemented and (all?) signs replaced, they would already no longer be necessary -- like, 15 years past being necessary.

Makes a lot of sense, and seems better executed than AWS's pathetic RoboMaker attempt 8 years ago or whenever that was. Was looking for the team but there is no linkedin link on your page.

Obligatory: https://xkcd.com/927/

The problem is not that there is no standard -- there is, it's called ROS. The problem is that manufacturers are not interested in opening their robots up to that degree.

Also, REST is a terrible idea for interacting with robots. REST is call-response based. But with Robots a pub/sub (like ROS or MQTT) or a blackboard data architecture (like what we used in Transitive Robotics) is much more efficient and natural.

Foxglove is not the only name in town. There are many, Transitive Robotics, the company I'm building is one of them. Different from Foxglove we are much more focused on live-remote monitoring and control, e.g., we have a pretty popular remote teleoperation module: https://transitiverobotics.com/caps/transitive-robotics/remo... You can find all the other modules we're currently offering here: https://transitiverobotics.com/caps/ The platform itself is and remains open-source.

We are thrilled to announce a new major version of Transitive, the open-source framework for full-stack robotics. Version 2.0 adds significant new integrations and features: storage of historic and time-series data in ClickHouse, visualization in Grafana, and custom alerting via Alertmanager. Some of our capabilities, like the free Health Monitoring capability, already use these features, providing significant added value to robotics companies with growing fleets.