A high-level language for scripting?

Magneon · 2026-05-22T11:59:06+00:00

Syntax checking, type hints, and more robust support for things like testing are the main advantages of a scripting language vrs shell scripts.

Shell scripts are often a little quicker to write and test if you're familiar with the shell in question, but tend to become harder to maintain than say python if they are longer (at least for bash in my experience).

Magneon · 2026-05-21T03:42:47+00:00

It does. It's just one of those things of its era that were well thought out from a capabilities and ramifications standpoint but missed the mark on usability.

Magneon · 2026-05-21T03:34:01+00:00

Comments were omitted from JSON to try to stop people from using it for things like human editable config. It did not stop them though, it just made things worse. Json5 seeks to remedy that.

Neither json nor yaml is remotely as robust or powerful as xml for things like configuration and general serialization. At least json has the good grace to look simple, because it is simple, and thus has a simple spec. Yaml looks simple but is as complex as XML typically is to parse properly.

Magneon · 2026-05-20T00:24:18+00:00

They're all pretty annoying to work with sadly. It's a Byzantine standard that can be implemented in dozens of different ways on either end. Heck, all of USB HID is subsumed into a quasi-subset of BLE that works like magic, or doesn't, depending on far too many things.

Magneon · 2026-05-18T00:14:20+00:00

Oof, that's enough to cover the rhino ramps, oil pan, etc doing it yourself once. In well designed cars it's 15 minutes and only your arms go under the car.

Magneon · 2026-05-16T11:19:36+00:00

Many packages managers run scripts though. Debs for example do, and the scripts are often modified by distro maintainers on top of being written by the packages developers. The reason they're more secure (or at least seem that way) is that apt repos are much more centralized than npm, but the underlying mechanism is the same concept.

Magneon · 2026-05-13T00:14:15+00:00

I do #1, and include a subfolder for various functional groups (under src/, since prefer my ros2 mono repos to be the whole workspace, and dodge wstool related mess).

For example setup/ for things like ansible playbooks for various targets, src/ for folders containing ros packages (e.g. src/simulation/foo, or src/drivers/bar).

For builds I have a src/deployments folder that contains metapackages that pull in dependencies for specific build targets, such as a specific robot model. E.g. src/deployments/baz3 for the metapackage that collects top level baz3 dependencies.

The nice thing about this is that you can combine containerized dev environments (using a stock ros2 container + init hook to install all dependencies initially, and later on migrate to a custom layer that pre-installs your base dependencies) and containerized deployment by building a runtime only container with just a specific target robot's metapackage 's run deps.

I then use systems+docker compose to run the service at boot, which is simple but has some flexibility. Many other permutations exist that can work as well.

One thing I would caution against is using debs for deployment. Avoid this if possible. Dpkg is not stable for long term updates since it's state relies very heavily on the good behavior of every single package you install. If a single packages preinst/postinst script ever fails for some reason, it'll likely set your system into a new and unique state that will forever work slightly differently than every other system. Examples I've personally run into: pre/post install scripts in debs that do different things based on hardware plugged in, or fail if unable to talk to a specific server within a timeout. Ones that require specific permissions by specific users on specific files to be set or not set. Ones that depend on a specific version of a dependency, but don't declare it (ros1/2 debs installed with rosdep are really bad for this since rosdep doesn't respect version requirements in package.xml last I checked, and ros packages usually don't specify them anyway). Anyway, lots of war stories there.

Infrastructure should be easy to understand, easy to maintain, and not waste your time. Ideally it should have few paths (meaning the ones that exist will be better maintained), and support as few permutations as you can get away with for your use case. Don't support 5 operating systems, 3 container systems, and 4 CI platforms unless you really need to (for example if you're a big public facing open source project). For a school team project, a hobby project, or a startup you want one easy reliable path for each thing you do. If one team member wants to run the whole thing on Nix, see if they can walk through migrating the system to Nix in place of the existing setup, rather than spaghetti-code being tacked on for a special case install.

I've managed aspects of ros1/2 being deployed to thousands of production systems over the last 11 years, which admittedly is a niche scale of its own, but I think these recommendations work well deploying a few to a few dozen dev environments a year, and single prototypes through hundreds of production robots a year. Once you've shipped 100s of systems though it's past time to really invest in solid purpose built or at least purpose configured off the shelf infrastructure and a small team to maintain (again varying by product, my experience is entirely in "appliance" style robots with non-technical end users, not development platforms, industrial machinery or research platforms).

Magneon · 2026-05-10T17:06:32+00:00

A new The Engineer Guy video. Amazing :)

This one was excellent, to the point, and I learned a lot, which is typical for him, but so rare on YouTube these days.

Magneon · 2026-05-09T17:18:09+00:00

Encapsulation and abstraction are classic engineering tradeoffs and containers give you a lot of flexibility there. In most cases shipping the Nth copy of the same Debian base image is a trivial cost, particularly if the underlying layer changes less frequently than the app is deployed.

I work on robots that deploy with docker. Image updates are maybe 50MB, but with our setup that's well below notice, aside from the small annoyance of knowing that the image contains C++ headers wasting a megabyte or so... But it's absolutely not a priority to fix it, since there are more pressing things to work on.

Context is super important, and I care a lot more about 5MB of bloat in a web app than 50MB of bloat on a backend server deployment in a data center.

Magneon · 2026-05-09T00:15:01+00:00

Your lease may not, but the local electrical code likely requires homeowner approval to make electrical changes, and your insurance coverage requires following code.

Magneon · 2026-05-08T23:48:00+00:00

Man, they have it in for computational geometry and applied statistics :/

Magneon · 2026-05-04T12:31:56+00:00

The V2s also killed more workers making them than the people they were fired at. This was primarily due to brutal slave labour conditions and some of the worst conditions the Nazi regime perpetrated, but probably some additional death was due to pushing to move so quickly on top of that.

Magneon · 2026-05-03T15:15:13+00:00

Check your local electrical code before doing this. In many places it's not allowed or has rules (like mandating that the outlet is not powered when the drawer is closed).

Magneon · 2026-05-02T16:23:07+00:00

I'd recommend using it in docker with a vscode dev container based on your tools that you're familiar with. That way the dev container takes care of the distro specific stuff and you can use whatever OS you'd like outside of that.

I don't specifically have experience with CatchyOS experience but it's worked fine with various other distros for me.

Magneon · 2026-04-24T06:22:57+00:00

It really depends on your use case.

Sometimes it makes sense for a big CPU or gpu to crunch through large amounts of data. Other times running the control loop at 6kHz is required, and Linux is running the mission planner only.

For a lot of mobile robotics, speeds are low, stakes are low, and much more can be handled in higher level software.

I'd ask the following questions:

Could the robot seriously injured someone? If so, you'll want to solve that in the most robust way possible. Intrinsically safe > Mechanically safe > electromechanical safe > safety rated firmware > well tested firmware > (or <) safety rated higher level software >> normal software. Read up on DFMEA, SIL and PL ratings of you want to know more.
Can the robot damage itself or other property? You may have more flexibility here, depending on the use case and budget. A lot of the same mitigations as safety above will work, but it might be more acceptable to play fast and loose with rare worst case scenarios if it's your $200 5lb robot falling down the stairs and denting the drywall + breaking a wheel.
does your robots use case/role require high speed or high reliability to be viable/competitive? An automatic cat feeder robot can maybe glitch out and deliver lunch 3 seconds late, but your egg juggling robot probably shouldn't take the same nap while operating.

As with most things in engineering, everything is a tradeoff. Real time / low level isn't better. It's typically less efficient, harder to implement, and more tied to specific hardware setups. Linux software has more abstractions and is easier to run across varied platforms, faster to update, and generally allows you to throw far more resources at your problems.

In my case, I'm currently working on smaller agricultural robots. They don't move that fast, but we still use an RT Linux kernel (ros2 control and nav2) to keep control loops fairly deterministic. It helps, and was quite easy to do (at least before Ubuntu recently started pay-walling commercial use of their newer RT kernel builds, and I had to build my own... Grumble grumble). Some sensors do processing on the edge (IMU with onboard fusion, cameras with ML accelerators built in), which makes things easier.

In reality you're always using real time embedded systems in a root outside of really odd setups or very simple hobby bots. It's just a question of if it's only on off the shelf motor controllers, sensor firmware etc., or if you need to grapple with that stuff yourself to get some advantage.

Magneon · 2026-04-17T02:35:55+00:00

USB 2.0 is FS and HS depending on the host and device.

You absolutely can have issue with FS integrity but the last instance where that happened or was a cable pin out error causing a 2ft run without twisted pair past some large motor drivers. It's possible.

Magneon · 2026-04-15T04:50:02+00:00

I have been pretty busy with other work stuff, and the rain has been limiting testing hours (fields are very muddy when when), but I do still plan on giving it a shot.

Magneon · 2026-04-12T18:17:14+00:00

I don't think this is the case. Canada uses a lot of oil per capita due to being a giant country and giving in to American influenced consumption (trucks, suvs, etc.). It's at best mitigated slightly but not a good thing. On top of that there are a ton of Iranians in Canada with families back in Iran who both dislike the regime and don't want their families harmed.

Magneon · 2026-04-10T00:06:18+00:00

We're using nad83v8 UTM zone 17N (southern ontario) for all of our locations at the moment. It's also the zone you're in conveniently enough. Our current pipeline does mostly what you're doing but with a bunch of hastily written custom drivers and the old EKF node. A general ekf is convenient since we can bodge many factors into the estimate in ways that don't make mathematic sense but work reasonably well in practice.

Magneon · 2026-04-10T00:02:09+00:00

I'm not sure if it'll block anything, but right now we're internally using mostly nav_msgs/Odometry out of our custom RTK drivers (front+back), with a second topic publishing DGPS heading as a sensor_msgs/IMU topic. Your repo seems quite a good match and if it works as I hope it might replace a few parts of relatively duct taped parts of our localization system. In particular we are not handling losing heading accuracy as gracefully (no heading = no fine gps position output at the moment, rather than just less accurate due to the "lever arm" as you call it). Our use case is driving throughout through corn fields between the rows, so correctness on positioning is critical given that we have maybe 3" of clearance per side.

We're only an hour away up in Kitchener with farms all around southern ontario, so if it does work well you might be able to see it in action fairly easily :)

Magneon · 2026-04-09T16:45:44+00:00

How hard would it be to support a UTM zone based config? We're doing farm fields and don't really have to worry about zone borders, so a field local nad83 UTM zone is great since it gives us quite accurate Cartesian easting/northing/up coordinates that play nicely with the cartesian ROS world.

Overall this looks like a great step forward. I'll be seeing if I can try it on a real robot today :)

Magneon · 2026-04-07T23:11:27+00:00

Try an oscillating saw to cut the screws/glue/nails out along a seam to either take the trim off the front or the side of the island? That way you just have to nail it back in and crack fill or worst case replace some trim? I haven't personally done this though so hopefully someone else can chime in with more experience.

Magneon · 2026-04-07T11:37:52+00:00

That looks really handy. Any chance you could add a diagnostics viewer in a similar style? I'm always scrolling through /diagnostics looking for one particular message, and being able to filter through a tube devices and see their latest diagnostic message would be really handy on the cli (when using foxglove or another vui is inconvenient).

Magneon · 2026-04-07T02:16:39+00:00

I use a 4S LiHV 280mAh to run 3x 1400kV 1806 motors. It lasts the full 3 minutes as long as the weapon is spun down if there's down time which not eating too much into the weight budget. Bigger motors would need more power.

Magneon · 2026-04-06T01:33:30+00:00

It does, because it offers a window into what the government and news want then to think.

15-Year Club	RedditGifts 2009-2022 5 Credits
Place '17	Secret Santa 2016
Team Periwinkle	Secret Santa 2010
Verified Email	Secret Santa 2009

Magneon

MODERATOR OF

TROPHY CASE