The Challenges of Managing Robot Config with Git
mirurobotics.com
mirurobotics.com
As you scale, this affects your ability to scale RobotOps, to stand up other fleet management tooling, and to provide the security/access controls your customers need.
> The first is a directory per device in a single repo. It is admittedly the most intuitive layout, but every config change across every device lands in the same commit log. At 100 devices, that history is unreadable. If you want to see what changed for one device, you’ll find yourself wading through hundreds of unrelated commits. Git wasn't built to filter history this way.
Wow, these people don't know how to filter git log by directory? This is pretty messed up, no wonder that git does not work to them.
> This is why we built Miru, config management for scaling robotics teams.
oh! This was a strawman argument to motivate their SAAS. Still, it's a pretty weak one.
Hmm... good point. Would you say that a directory per device is the best way to manage robot config? Have you felt that non-technical users are comfortable with this? Curious what your experience has been like.
> oh! This was a strawman argument to motivate their SAAS. Still, it's a pretty weak one.
I don't think this is a strawman argument. This is a problem we've heard from real robotics teams as they scale their fleets. I did my best not to shill. I'd like to think that reserving one sentence at the end of the blog is acceptable.
Still, I'd love to hear where you think the arguments are weak so I can reconsider them. Thanks again for reading. I appreciate it!
If you combine "directory per device" with "git forge, like github or gitlab" then most of your concerns disappear completely:
- "They’ve never used a terminal, let alone Git." - Solved! Github and Gitlab have online file editing, so no one needs to worry about terminal at all. It's just a slightly weird web editor. They can even open PRs, so you can have linters etc.. checking the changes before allowing them in.
- "has to learn branching, pull requests, merge conflicts" - Almost solved! Github/gitlab deals with this for you.. and with 1 dir per robot, there is no merge conflict unless you have multiple people editing same file for same robot.
- "You end up with two bad options: Train everyone on Git [...] / Route every config change through your engineering team" - or option 3, teach _few_ people in the ops how to use git web UI, and ask them for help.
- "Running a fleet in production means you often need to answer questions like: Which robots have vla_model_3 enabled?" - "git grep vla_model_3=on", that takes <1 second for all cases under 1K robots. Or build dashboards updated on "push" trigger. This will also let you answer more advanced questions, like "Which robots have vla_model_3 enabled _and_ reported VLA errors in last 1 month"
- "You can't find every file where feature_x: true without opening and parsing every file in the tree" - true, but what you've omitted is that once tree is cloned, "opening and parsing every file in the tree" takes less than a second (if you have under 1K robots). And of course, if you are serious about maintenance, you already have a database full of logs, events, telemetry... So adding config there is just one more step.
In a lot of cases, Git works pretty well. Yes, you might need to design and document schema, maybe write some scripts to enforce it, but that's what the whole "software design" thing is about. Maybe add few dashboards, too - but you'll likely already have this set up for telemetry, so this is not as big change as may appear.
A biggest reason to walk away from git is the permission issues, you are not going to fix that one. And when you get to 1000 robots (not 10!) your git gets kinda slow. Or if you are misusing config system and updating it all the time, instead of only during initial commissioning and troubleshooting events.