HackerTrans
トップ新着トレンドコメント過去質問紹介求人

msadowski

742 カルマ登録 9 年前
Maintainer of Weekly Robotics (https://weeklyrobotics.com/) Robotics consultant (http://msadowski.ch/)

Get in touch: [email protected]

投稿

NASA launches robot to save Swift telescope falling to Earth

bbc.com
31 ポイント·投稿者 msadowski·5 日前·9 コメント

Xiaomi-robotics-0 – an open-source Vision-Language-Action model

xiaomi-robotics-0.github.io
1 ポイント·投稿者 msadowski·5 か月前·0 コメント

Turning a VLP‑16 into a "Spherical" Scanner – A Cave Mapping Project

foxglove.dev
8 ポイント·投稿者 msadowski·5 か月前·1 コメント

Robot touch sensing with torque sensors only [video]

youtube.com
3 ポイント·投稿者 msadowski·9 か月前·1 コメント

コメント

msadowski
·9 か月前·議論
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.
msadowski
·9 か月前·議論
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.
msadowski
·9 か月前·議論
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.
msadowski
·7 年前·議論
I also think it's about sustainability. As a developer receiving an X amount every month (+/- Y%) can heavily reduce the financial risk and help plan better.

I'm currently not developing any open source software but if I was and worked as a freelancer knowing that by the end of the month I'll receive $500 for GitHub would allow me to balance my open source work with the freelance work, ensuring I have enough money to support myself.