msadowski

One thing that comes to mind is checking the timestamps across sensors and other topics. Two cases come to mind:

* I was setting up Ouster lidar to use gos time, don’t remember the details now but it was reporting the time ~32 seconds in the past (probably some leap seconds setting?)

* I had a ROS node misbehaving in some weird ways - it turned out there was a service call to insert something into db and for some reason the db started taking 5+ minutes to complete which wasn’t really appropriate for a blocking call

I think the timing is one thing that needs to be consistently done right on every platform. The other issues I came across were very application specific.

In my case, it’s definitely the data triage. Once I see the signal, I usually have ideas on what’s happening but I’ve been doing this for 11 years.

Maybe there could be value in signal interpretation for purely software engineers but I reckon it would be hard for such team to build robots.

Full disclosure, I work at Foxglove right now. Before joining, I spent over seven years consulting and had more than 50 clients during that period. Here are some thoughts:

* Combing through the syslogs to find issues is an absolute nightmare, even more so if you are told that the machine broke at some point last night

* Even if you find the error, it's not necessarily when something broke; it could have happened way before, but you just discovered it because the system hit a state that required it

* If combing through syslog is hard, try rummaging through multiple mcap files by hand to see where a fault happened

* The hardware failing silently is a big PITA - this is especially true for things that read analog signals (think PLCs)

Many of the above issues can be solved with the right architecture or tooling, but often the teams I joined didn't have it, and lacked the capacity to develop it.

At Foxglove, we make it easy to aggregate and visualize the data and have some helper features (e.g., events, data loaders) that can speed up workflows. However, I would say that having good architecture, procedures, and an aligned team goes a long way in smoothing out troubleshooting, regardless of the tools.

  Location: Prague, Czech Republic
  Remote: Yes
  Willing to relocate: No
  Technologies: ROS, Python, C++, Robotics, Px4, Ardupilot, Pixhawk 
  Résumé/CV: https://www.linkedin.com/in/mateuszsadowski/
  Email: mat[at]msadowski.ch

I have 11 years of experience making software for robots. For the past 7 years, I've been working as a consultant on various projects. I have experience building software for hardware platforms, from autonomous mobile robots through drones to heavy-metal industrial robots. These days, I have a slight preference for consulting projects but can consider a full-time position if there is a good match.

Anyone has any stories on companies overusing AI? I’ve had some very frustrating encounters already when non-technical people were trying to help by sending AI solution to the issue which totally didn’t make any sense. I liked how the researchers in this work [1] prose calling LLM output “Frankfurtian BS”. I think it’s very fitting.

[1] https://ntrs.nasa.gov/citations/20250001849

SEEKING WORK | Remote | Prague, Czech Republic | Robotics Software Developer

I'm a robotics software developer with experience leading teams and integrating software on various platforms (custom industrial robots in smelters, UAVs, rovers, USVs). Have experience on robotics full-stack from low-level interfaces of actuators, sensors etc. to deploying navigation and behaviour trees. Mostly experienced with ROS, but did a fair bit of work working with Px4 autopilot. My super power is putting things together and diagnosing difficult issues.

LinkedIn: https://www.linkedin.com/in/mateuszsadowski/

Personal Website with some older projects: https://msadowski.github.io/

E-mail available on my HN profile

I’ve been consulting for close to 7 years in robotics now, robotics being a niche field I guess it has been a bit easier for me to find clients. I never had a period without a client and never had to do cold outreach.

Here are some things I learned: * You can usually charge way more per project basis instead of charging by the hour but it’s crazy difficult to get it right for R&D projects * Most of my clients came to me through my blog * 2 years ago UpWork was surprisingly good for finding projects, these days there is lots of AI stuff coming from freelancers when they apply and I’m not so sure anymore * Discuss price as early as possible to not waste time

I wrote a series of blog posts on my journey in case anyone is interested (I’m quite sure you will find the above points there): https://msadowski.github.io/5-years-remote-robotics-consulti...

This year I might write another update to share a painful lesson on having all your eggs in one basket and not spending time on working your blog.

Same experience here. I also found that if they haggle on the price at the beginning they turn out very difficult to work with.

There was a ~€20k electric car from the VW group. It was called Skoda Citigo iV but they axed it. Seems like they are walking in circles.

One thing I learned really quickly renting in Europe is to take pictures of the rental before driving off. Last time I rented a car there was a huge scratch on the side that wasn’t included in their pickup form. When I returned the car they were ready to bill me for it until I showed the picture and their response was: “OK, no worries then, all is good”. From the reviews I’ve been reading people often get charged this way and I’m wondering how many people end up paying for the same damage.

Can you recommend any resources on nix?

I maintain a list of interesting robotics projects (https://github.com/msadowski/awesome-weekly-robotics). You will find a simulator section there but whether they are useful for you will depend on the details of your project. I don’t think it’s there but you could also check out MuJoCo.

Fun fact: this project might or might not have started as an open-source smart robotic gripper that you can build yourself: https://punyo.tech/

My journey is a little bit opposite to the author’s: I studied robotics and started learning programming by myself to create software for robots. There are two observations I have that can be useful to people making the software->robotics journey.

* Agile for software-hardware is hard if not impossible. For software it can be reasonable, but it’s really hard to iterate on both hardware and software at the same time. It’s easier if the hardware designed is locked or the process involves waterfall on the hardware side. * I often found that people that come from pure software to robotics don’t have control experience and something that can be easily solved with a PID controller end up being a custom code that ends up being way more complicated than needed.

I’m about to buy all the appliances to a new place in Europe and could use some more horror stories and learn which brands to avoid. So far I’ve been told to stay away from Samsung ovens. Anyone has any regrets on appliances?

That’s a bummer if true and not a temporary issue. The RSS is my workflow for creating a newsletter and if RSS does not work then I’m way less likely to include any yt content because I simply won’t come across this. It’s not like Google would care about this either.

There was a time where these were used heavily in robotics, nowadays people usually use other sensors but every now and then a project using a Kinect pops up. Last one off the top of my head is this one: https://github.com/macorobots/roomac_ros

Check out Naonosaur: https://github.com/rnanosaur/nanosaur. If you would like something larger and with a bit more off the shelf components then jpl open source rover has seem quite a bit of updates recently: https://github.com/nasa-jpl/open-source-rover