Hacker News new | past | comments | ask | show | jobs | submit | more amacneil's comments login

Is there any indication this object detection algo was originally from Cruise? The linked code has been rewritten and has no attribution beyond "an autonomous vehicle company".

Fun fact - Cruise did actually have a source code leak a few years back, some engineer decided to embrace the 4 hour work week and outsource their role to a contractor, who uploaded their work to a public github repo (I assume this was accidental and they intended to make a private repo). But it was not core AV code.


It’s great to see more innovation in the robotics framework space, it’s sorely needed.

Deterministic log replay is a killer feature to have baked in from the start - many autonomous vehicle & robotics companies have invested years of effort to achieve that nirvana, while the most popular robotics framework today (ROS) makes it borderline impossible.


True. All of it. https://edms.etas.com for example.


Foxglove | Remote | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~25 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

- Tech Lead Manager - Frontend / Visualization (U.S. time zones; TypeScript, WebGL, Wasm)

- Staff Software Engineer - Frontend / Visualization (U.S. time zones; TypeScript, WebGL, Wasm)

- Senior Software Engineer - Rust (Australia / NZ time zones)

https://foxglove.dev/careers


Foxglove | Remote (U.S. or Australia/NZ time zones only) | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~25 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

- Tech Lead Manager - Frontend Visualization (TypeScript, React, Three.js, WebGL, Wasm)

- Staff Software Engineer - Frontend Visualization

- Staff Software Engineer - Rust / Data Infrastructure

- Head of Sales + Solutions Engineering (must have experience selling dev tools or infrastructure, robotics or autonomous vehicles experience is a bonus)

https://foxglove.dev/careers


Foxglove | Remote | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~20 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

Americas (must live in U.S. time zones)

- Head of Sales + Solutions Engineering (must have mgmt experience + dev tools/observability sales, robotics or autonomous vehicles experience is awesome but not critical)

- Visualization Tech Lead Manager (TypeScript, React, Three.js, WebGL, Wasm)

- Staff Frontend Visualization Engineer (TypeScript, React, Three.js, WebGL, Wasm)

- Staff Backend Engineer (TypeScript, Node.js, Postgres, bonus if you have Rust, C++, or Python experience)

- Staff Full Stack Engineer (any combo of above tech)

Oceania (Australia / New Zealand time zones)

- Staff Contract Rust Engineer

https://foxglove.dev/careers


Always exciting to see more innovation in the robotics middleware space!

Do you have a zero copy/serialization way that nodes can output messages back to their own input?

For example I have always thought that full determinism would be much easier to achieve if all nodes were purely functional/stateless, and if they want to accumulate data over multiple messages they must do so by explicitly outputting that state back to themselves.

This would mean that all state can be logged (if necessary), and therefore resimulation tests could start with a single tick, rather than needing to play back several seconds of data because there is no way to reason about what local state nodes might be maintaining.


Yes, though I'd want to add special detection for this case - to ensure that there are no runtime race conditions for having or not having a state from last frame. No serialization occurs unless the message goes over a non-inproc transport (unserializable inproc only messages are possible, too!).

I've considered this kind of idea before - I'd likely try to make it a first class citizen of the framework, in that case. Declare it in the definition for your node what kind of state it keeps, rather than try and shoehorn it into the pubsub system.

I'd have some worry about the performance cost of it, though, for large states.


Foxglove | Remote | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~20 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

Americas (U.S. time zones)

- Staff Frontend Visualization Engineer (TypeScript, React, Wasm, WebGL)

- Staff Backend Engineer (TypeScript, Node.js, Postgres, bonus if you have Rust, C++, or Python experience)

- Sales / Solutions Engineer

Oceania (Australia / New Zealand time zones)

- Staff Rust Engineer


Please is someone from Nigeria allowed to apply? I checked your website and its showing only schools in other countries.


No, we are looking for US time zones only sorry.


Do you just care about someone who could work those timezones or someone who actually lives in those timezones?


Interested about the Rust position, I am from Bangladesh, I have been working with US clients on US timezones. So, timezone is not much of an issue. Is that Okay?


Foxglove ceo here, thanks for the shout out!

Spot on with our history, most of the early Foxglove team came from Cruise where we built Webviz among other tools & infrastructure. Since then we have rewritten nearly 100% of the Webviz code.

MCAP is a multimodal logging file format we developed based on lessons learned from Cruise and other robotics startups, it has now taken on a life of its own and is the default logging format in ROS.

In terms of differences between Foxglove and Rerun, Rerun appears to focus more on local visualization whereas Foxglove offers more of a complete observability platform for local visualization plus cloud data workflows (upload logs from robot, organization & search, cloud visualization). I'm always happy to see more innovation in the robotics dev tools space though, the industry is growing quickly and pie will be very large so plenty of room for more alternatives.


Rerun ceo here, thanks for jumping into the discussion here Adrian!

First of, want to really highlight that MCAP is a great container format for robotics message recordings. We (like most of the robotics community) see it as the natural evolution of the rosbag format (co-created a while back by one of our team members).

To add onto some of the differences between Rerun and Foxglove, the Rerun open source project is focused on a viewer that runs completely client side. It's written end-to-end in Rust for maximum speed and portability. That means it can run fully natively for maximum speed (e.g. utilizing native threads and rendering APIs), and in the browser via wasm. You can even embed Rerun visualization in your own web apps and use it inline in python notebooks.

I would also highlight the SDK, which lets you log / send data easily from your own code without up front declaring a message schema. This makes it much easier to also use for quick debugging etc (although some of the largest companies in the world use it to build large sets of different internal visualization heavy tools as well).

On the data model side we've focused on developing what you might label a language or semantic data model. We believe this gives users significantly more power and control than "only" orienting around robotics messages. I think that's why you'll see Rerun being used in a lot more contexts than viewing Robotics messages (although that's a big use case as well). In order to really make use of that data model (with high performance) we've had to develop a new database query engine and a lot of other craziness.

We do have a cloud data platform in the works that leans heavily on our semantic model and query engine. It will have a different take to Foxglove's, with a much broader view of the full data lifecycle for embodied AI.


Foxglove | Remote | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~20 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

Americas (U.S. time zones)

- Staff Frontend Visualization Engineer (TypeScript, React, Wasm, WebGL)

- Staff Backend Engineer (TypeScript, Node.js, Postgres, bonus if you have Rust, C++, or Python experience)

- Sales / Solutions Engineer (onsite in Boston MA, experience with robotics and/or cloud infrastructure)

Oceania (Australia / New Zealand time zones)

- Contract Rust Engineer


Tried to apply but was unable to since my school wasn't listed in the required education section


Foxglove | Remote | Full Time or Contract | https://foxglove.dev/

Foxglove is the leading observability platform for robotics developers. We help robotics and autonomous vehicle companies log, ingest, organize, and visualize multimodal data. We're well funded (Series A, ~20 people), with an experienced and fast-moving team. Seeking like-minded people to join us!

- Senior / Staff Product Engineer (Remote, US time zone, mostly TypeScript + React + Node.js, bonus if you have experience with any of Rust, C++, Go, Python)

- Senior / Staff Rust Engineer (Remote, Australia / New Zealand time zone)

- Sales / Solutions Engineer (Boston MA, ideally experienced with cloud + robotics)

https://foxglove.dev/careers


At the Careers page it says "Remote - Americas" and then in the actual position's page it says "For this position, we're looking for someone in North America." So it's North America, not Americas.


Fixed, thanks! We're open to North/Central/South America, I think that text was unintentionally copied from a different role.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: