If you want a hardware upgrade it's actually reasonably inexpensive to build something direct drive (which is how the real sub-30kg ones work). This gives you many advantages over the plastic gear type including a much faster response time and more accurate positioning.
Look for "gimbal motors", basically a large skinny pancake brushless motor. Combine those with a storm32, simplebgc or odrive and a magnetic encoder. A 3D printer will help.
You can also have a look at low cost suppliers of cheap UAV stuff if you want something fully integrated for you. A basic Gremsy, Viewpro or Siyi isn't that much more than your Amazon thing. Various software bugs but they can be worked around. The DJI units can sometimes be had used and some of the protocols have been RE'd already.
Presumably also open circuit not rebreather given this was mid 90s. It's a pity the article doesn't detail their dive plan, the gas quantities must have been staggering.
Nowadays this type of diving would be done using an eCCR (and backup open circuit), where some software on a microcontroller controls the amount of oxygen in a breathing loop. A scrubber (hopefully) removes the CO2. Changing the gas mixture as you go is required to reach these sorts of depths because oxygen becomes toxic at pressure, and gas density itself can cause issues with breathing.
Right, Terrence Tysall and Mike Zlatopolsky (Zee) dove the Edmund Fitzgerald in 1995 using open circuit gear. This article by Tysall gives some details of their dive plan.
I recently bought a robot vacuum, installed valetudo, installed tailscale onto the robot itself and now I can control it from anywhere through my personal mesh vpn.
It's pretty amazing. Valetudo is perhaps the most opinionated software I've ever used, which comes with the good and the bad. But overall, it works and it does what it says it will do.
I don't really need to access it remotely, though it has come in handy: when heading out of town I can turn off the scheduled cleans and just run it once on the day I'm returning home. Which is really the only functionality you would need the manufacturer-provided cloud connectivity for.
It's been fun explaining to people that it's "declouded", but I can access it from anywhere. Melts non-tech peoples' brains a little bit.
To expand on laulis' comment: Valetudo isn't a full custom-firmware, it's a mod for the existing firmware. You copy on the Valetudo daemon binary, fuss with the init scripts to start the daemon, and fuss with the DNS and such to point some domains at 127.0.0.1 to talk to that daemon instead of the normal servers (well, actually you probably download a firmware image from dustbin that already has those modifications applied).
This is a distinction that is worth making because the robot is still running and relying on all of the on-robot proprietary code; it's just the in-cloud code that has been replaced.
it's a bit of a blurry distinction because, what is firmware if not the software that runs on an embedded device? a more accurate description would be that the high-level operating system (HLOS) has been modified to include the installation of a drop-in-replacement for the cloud API. the client side, and whatever hardware abstraction layer lives below it, is untouched. so the client thinks it's talking to the server but it's actually talking to a local open-source server.
I think it's also not quite correct to say the low-level firmware is unmodified, because with vale tudo you rely on the project author to provide a minimal rootkit that gets customized on a per-serial-number basis for the initial rooting.
from a high-level though, it delivers what it says on the tin - cloud features without any requirement of packets leaving your network or even the robot itself.
Why on earth would you do it?! It was literally the comment I visit HN for - a solution for the problem we basically all have, already tested by someone, starting a thread with people's experience of it.
Thank you for sharing this! I'd love to know more about what led them to develop their own CPU, and what the instruction set looks like. It looks like AdaCore actually merged their support for VISIUMCore into upstream GCC.
The slides state it features SEU detection/correction, which is pretty interesting.
One interesting project is Saab Gripen jet fighter, whose entire software stack (other than software that is treated as "black box" firmware of certain physical components) is written in Ada, and AFAIK every sale includes complete source code and SDK to make modifications.
He also runs an excellent ISP in the UK called AAISP which I can highly recommend (https://www.aa.net.uk)
AAISP build their own core & customer networking devices/routers from scratch (not Linux based) in the UK. They are fascinating to use - a completely different evolutionary tree to any other networking kit I've used. Some unique features.
This blog post has a few hints [1]. Apparently they had to rewrite a load of code when they moved to a multicore processor, so it definitely seems to be in-house software.
It's absolutely wild to think about a suite of software this sophisticated that exists outside the realm of Unix, Windows, or any of the long-term players in the embedded networking device market. I know there are boutique embedded IP stacks out there but it still boggles my mind that a small company like this has had sufficient revenue to keep up with the "churn" in the networking space for 20+ years w/o leaning on free/open-source software.
Piling-on to my own comment: Searching the site https://www.revk.uk for the keyword "firebrick" returns a ton of results detailing the development. It looks like it's exactly what it says on the tin-- a proprietary operating system with its own implementations of a ton of protocols.
I wish I had a reason to interview RevK about the Firebrick code. I think it would be an immensely interesting topic.
I'm sorry you've had a bad experience but I don't agree, I prefer it to the ST, TI and definitely the Microchip tooling. It's CLI first, like the Espressif and Pico tooling which is a big plus for some and not for others.
Also, no mandatory login walls for toolchains and datasheets gets them a lot of goodwill in my book.
Microchip tooling: download, double click, install, just works. Zero need for any framework, good bare metal support. a C project is an actual C project. Granted, if you use that MCC piece of shit you're in for a bad time, but going bare metal require zero effort, a single include file if you need to access peripherals, and you actually have documentation to do so.
ST tooling: sort of almost just works, more effort but you can still go bare metal with relative ease.
Current nordic: it's actually a zephir project, thousands of files to generate and compile. No options to go bare metal. (used to be possible with the older SDK, or so they tell me. Too bad i can't seem to be able to let a project compile with the old SDK, or set up the IDE for intellisense with the new SDK, but i haven't had enough time yet.)
Bonus: Espressif. At least their VSCode integration really just works. The peripherals are frustrating and severely bugged though and there can be supply chain issues, and that's the reason i'm looking at nordic for some BLE-enabled project, because the ESP32 parts won't cut it for this or that reason (usually the basic yet still bugged peripherals).
But i'm willing to put up with microchip's BLE modules again (i evaluated them several times over the years, always a disaster. But not the newer based on PIC32MZ, and the price have come down to be reasonable.) if the only option with nordic is the zephir monstruosity.
I completely agree. I spent lots of time trying to figure out their modern SDK, but in the end I abandoned it and just used their old SDK. Their examples and approach are terrible, but in the end I was able to make it work, after untangling the holy mess of macros they put there. Their old SDK is bearable, their new SDK... I still think I need to go there, but I don't have enough willpower to do that. So much moving parts. Custom build system, not just one, but actually three of them at once (cmake, ninja, west). The whole RTOS which I never needed. And not just simple one like FreeRTOS, but absolutely humongous one. Add their terrible software which they insist I must use to install their stuff. Just give me zip, I don't want to install nothing.
Let me write simple Makefile, give me thin layer over CMSIS called SDK and that's all I need. Don't make things harder than they should be, my project is simple, I don't need operating system for it.
i did not use Nordic-Zephyr, but i have run Zephyr on ESP32/STM32.
It's true that the learning curve is very step, but their idea is reasonable.
The execution is ... not that good at this moment imo. It's nearly impossible to debug device tree "macro hell", the preprocessor is not designed to debug that, and they abuse the hell out of it.
Also i'm wondering why you dont want "RTOS", in Zephyr setup, your entry point is still old boring "main" loop.
Installing a whole toolchain and SDK system-wide is such nonsense.
Espressif's toolchain and SDK are in a git repo that you add as a submodule, or in a directory anywhere you want.
If I want to use microchip or Nordic on a new machine I have to go through this whole process of installing and configuring everything. My ESP projects simply involve a git pull and I'm done.
Nordic was a special pain in the ass because I had to hunt for the exact correct version of the SDK which was hidden away because it's a few versions old. If I need to do the same for espressif, it's literally just a git switch away.
Espressif is in an entirely different league from ST, nordNordic, et al. They're not even playing the same game. Espressif wants anyone and everyone to use their stuff and ST seems to actively hate developers and only want to work with companies buying tens of thousands of units. Like, ST cripples their USB programming tool to only accept 'genuine' ST parts. It's frankly disrespectful.
I mean, you _can_ go bare metal with Nordic chips, but you'd definitely be swimming against the current. I'm not a fan of Zephyr, but it really wasn't that much trouble to put together a docker image that would let me spin up whatever version of the SDK I needed and then just build from the docker. Quite tolerable.
The TinyCurrent or uCurrent can be used for this as well when paired with a scope with scpi. However, the ranges aren't dynamic which is annoying if you're using something a WiFi part where you're going from uA to 200mA.
Their “Fulcrum” design looks quite similar to a Flair espresso. I mean, it isn’t a complicated concept (just a press), but the resemblance is noticeable.
In the New Forest national park in the UK (where there are about 5000 free roaming ponies) they've been fitting them with reflective/hi-viz collars for years. Makes them much easier to see at night in winter.
If you want a hardware upgrade it's actually reasonably inexpensive to build something direct drive (which is how the real sub-30kg ones work). This gives you many advantages over the plastic gear type including a much faster response time and more accurate positioning.
Look for "gimbal motors", basically a large skinny pancake brushless motor. Combine those with a storm32, simplebgc or odrive and a magnetic encoder. A 3D printer will help.
You can also have a look at low cost suppliers of cheap UAV stuff if you want something fully integrated for you. A basic Gremsy, Viewpro or Siyi isn't that much more than your Amazon thing. Various software bugs but they can be worked around. The DJI units can sometimes be had used and some of the protocols have been RE'd already.