chrisdalke

many INS packages also include a DVL (Doppler velocity log) which measures speed over ground if you’re in range of the bottom.

I do the same thing with a shortcut of Triple Click side button -> Color Filters. You can set this up in Accessibility and it will let you tint your phone to be nearly 100% red pixels.

This depends on your goal: Are you trying to build + finish a project, or learn a new skill? I like to separate these goals, or otherwise try to scope projects very narrowly.

For the former, I tend to reach for the tech stack that I've spent years working in and can very quickly spin up projects in. This is heavily specific to your background, but for me:

- Frontend: React, vite, react-router, Chakra UI.

- Backend: Node.js + Express

- Database: PostgreSQL

- Scheduled jobs/ML/data processing: Python

- Deployment/Infrastructure: Docker, docker-compose, AWS EC2 or Lightsail, Digital Ocean droplets, Netlify, Render

For the latter, there are lots of potentially better options, whether that's server-side rendering, serverless functions, etc. (Next.js, fly.io, supabase, are a few examples) and again depends on your industry.

Nice graphics, pretty smooth, biggest suggestion: Needs way more driftiness -- Right now it feels like the boat is "on rails" in that it follows the steering pretty closely. You should try tweaking the physics so the boat retains much more of its velocity, could be a lot of fun!

It's still got a small but vibrant community in the community-run servers (not accessed through matchmaking). These are typically hand-moderated.

Not just in a linear sequence, but it should have some concept of recursion -- starting with very high-level tasking and calling into more and more specific prompts, only returning the summary of low-level tasking.

He seemed to not react too much to the smell. With all the other crazy stuff he does, he must be seriously desensitized to strong smells if that’s even possible…

I did not suggest that anyone should DIY their IoT hardware. My point is I don’t find utility in shaming users for buying cheap cloud-based products - the average user doesn’t care or know about the tech choices, they just want to be able to change their light colors, play multi-room audio, etc.

Yes, a subset of consumers will find local-based IoT products and vote with their wallets, and there are great companies serving that market (at a premium). However, the financial incentives push most companies to produce WiFi/internet connected crap. It’s clearly cheapest to build on a ESP-type WiFi platform and build a bad cloud app.

I think the only way you really stop this is with strong financial penalties via regulation. I’d want two pieces:

Fines for cloud exfiltration of analytics or WiFi data beyond the base functionality of an application. Funding for FCC or other organizations to actively investigate reports of this.

Fines when companies “remotely” brick IoT products that are EOL by shutting off a cloud API. Something of this type should push companies away from any sort of cloud-based infrastructure because they’d need to maintain it for much longer. (Admittedly not well-informed here and maybe this is in progress already?)

I understand your perspective is that we can’t trust the government to properly regulate that, and maybe true. But it’s also unrealistic to expect most users to be well-informed. Even if most adults made that choice you still have a huge market of college students buying cheap crap.

This feels like a very tech-centric perspective. I agree with you, if you restrict this to the very IT-savvy group, but this shifts the blame away from companies’ bad design/behavior.

Most people have no understanding of the difference between a cloud-connected device and one that just uses WiFi or BLE locally to communicate with an app.

I’d say if you work for a company that produces this kind of crap IoT, shame on you, and that people in that position should strongly push for the ability to ship with offline-only firmware.

A short story that I just read and found very timely again with the advent of LLMs.

"In the near future from a 1950’s perspective, the first space station, in orbit around the Earth, gets knocked out of orbit due to pilot miscalculation. The subsequent disaster, with shuttle and space station crash landing near San Francisco, creates a public furor calling for the end of the space program. General Oglethorpe, the earth side base commander in charge of the space program, recruits Dr. Paul Medick, an expert in psychology and psychometrics, to head a new project: to eliminate human error. Oglethorpe is certain that men can be made to be more mechanical, operating with the same reliability of the machines which they operate.

The government had spent one billion dollars to convince the human race that men ought to be ashamed to be men—instead of being cybernetic machines incapable of miscalculation.. But they did not consider that an error less man is a dead man."

I use a fanny-pack style autoinflating PFD which actually comes with a ring to connect the lanyard to. Definitely agreed you need both.

Amazing story and the pilot of that boat is lucky to be alive. I think larger center consoles should ship standard with a wireless safety lanyard instead of a wired one, because very few people seem to actually use the wired lanyard because it’s inconvenient. this is the exact situation where that would help.

My philosophy is keeping the CI/CD workflow definition as simple as possible, and passing off the task itself into a shell or python script. The only thing I typically perform in a task definition is secret management, tagging & uploading build artifacts, managing distributed build agents, etc. and leave any complicated build process and success/failure criteria for the script to decide.

Jenkins works great for this purpose. It's fairly sketchy and held together by duct tape, but I find its developer experience to be much better than equivalent commercial options for a small scrappy team.

My playbook for a small team building a variety of software (Robotics software, web-based UI, AI, mostly running in Docker or built to static executables):

- Spin up a Jenkins master on a cheap VM

- Spin up platform/project specific VMs or physical machines as build agents, leave developers in charge of dependency and tooling installations on the build machine for their product. Don't bother with 100% reproducible tooling until you need to scale up to more than a few build agents.

- Maintain all build and deployment scripts inside the repository, next to the code, managed by developers. Store build pipeline/task definitions in the repository, and keep developers responsible for their service.

- Keep some boilerplate and convention around for pipelines and enforce it. Make sure all build pipelines use a similar git scheme. Doesn't matter as long as it's easy + reliable (ex. deploy every commit from develop w/ staged rollout? "Git flow"-based release workflows, etc)

- provide SSO access to the whole team via a plugin ASAP -- Avoid managing individual credentials to the machine

- Limit Jenkins plugins used for build actions! never use a plugin doing some action interacting w/ cloud resources, eg "AWS S3 Upload". Just asking for a security breach, and eventually turns the Jenkins UI into a giant mess of random UI controls. Instead, where possible use native tools eg. the AWS CLI instead of a Jenkins AWS plugin.

Most MQTT implementations do support MQTT-over-Websocket. I use it extensively at work and it's been fairly reliable!

Thanks for the corrections: So the bubbles are not a vacuum but low-pressure vapor and cavitation is the name for the collapse, not the bubble itself. And this can only happen in liquids where there is a potential phase transition. I've got a little marine knowledge but my physics is lacking so I appreciate the clarification!

I assumed cavitation had similar parallels in air propellers with high tip speeds (as you approach the speed of sound) but seems that is a different effect?

Related thread from a few months ago discussed the Sharrow propeller mentioned in this article, which applies the same concept to boats: https://news.ycombinator.com/item?id=33949895

The difference in geometry for air vs. water propellers has a lot of complicated reasons but above all the fluid density of water is about 1000x air: ~1000kg/m3 for water vs ~1kg/m3 for air. Air propellers are optimized for very high-speed operation which is needed to produce any significant thrust in low-density fluid. Boat propellers are very "built up" and physically sturdy since they are used in low-speed operation with high torque.

I have seen people use RC airplane propellers in water for small autonomous boats -- They do work but look very comical (think 10x the size of a boat propeller, running at 1/10 intended speed)

Cavitation effects -- microscopic bursts of vacuum at low-pressure boundaries along the propeller -- come into play much sooner than with air propellers.

Makani (Acquired by Google and shut down) built large airplane/kites which transmitted wind power to the ground via a tether. The engineering challenges were... intense. This was all documented extensively and this documentary summarizes all the footage they took: https://www.youtube.com/watch?v=qd_hEja6bzE

One of my favorite engineering projects and documentaries, just because of the sheer ambition and scale, and the grit of the team to keep pushing through repeated failures. Sad the project was cancelled but it makes sense given the cost and complexity.

Off topic, but wow, your generative art is incredible! I was already impressed and then saw that you're actually physically plotting everything which is next level. Love the fusion of art/math/robotics.

Outer Wilds is a profound, thought-provoking work of art.

A tip anyone encountering this comment: If you like Sci-fi, story-based, exploration games -- Just buy it. Just go play it. Don't read a single review. Don't look at YouTube videos. It's the type of game that you can truly only experience once, and the less known before entering that experience the better.

Also, play on Controller -- The game has a lot of spaceship flight which is pretty frustrating on keyboard/mouse.

Unsure if this would scale up but as others have mentioned for large ships the operation is very sensitive to cost. Fuel efficiency is weighed against current fuel cost, cost to design a technology into a new ship or retrofit, maintenance, etc. That said, since fuel rates are high and emissions regulation is set to come into effect soon [1] you'll likely see waves of shipbuilders adopt fuel-saving technology.

A few problems that might show up with this type of prop/"screw" on a large ship:

- Ship propulsion uses a fairly large-diameter prop and runs at very low RPM (~100rpm vs 1000-6000rpm) compared to smaller planing vessels. The Sharrow prop advertises decreased cavitation at high speeds but this effect may be diminished at low RPM.

That said, cavitation is a different beast for ships than for recreational boats: In the recreational market few boat owners are concerned about propeller efficiency loss due to cavitation -- Concern is mostly around noise and vibration. In contrast, ships are very concerned with fuel and maintenance cost, so if the Sharrow blade successfully reduces both of these it may be helpful.

- Seems like they're currently machining these on a 5-axis CNC out of blocks of raw material which won't scale to larger sizes. The complicated shape may not lend itself as well to casting, and even if they casted the shape it would need to be finished and this would require expensive equipment.

- Might be more difficult for third-party repair [2] which is done manually or with 3-axis machines.

Generally the commercial maritime market is much slower to adopt new technology than recreational, and also much smaller by volume, so it may make sense for Sharrow to continue serving small outboard boats because margins + sale volume is much higher.

[1]: Incoming maritime emissions regulations: https://hbr.org/2022/10/climate-regulations-are-about-to-dis... [2]: Example of ship propeller repair: https://www.youtube.com/watch?v=RuV3AsKTQlM

I think it's a pretty cool design but repairability does seem like a concern -- Normally you'd take a stainless prop to a shop and they'd just weld + grind any small damage but that seems more difficult with the geometry of this propeller.

Anecdotally (I'm familiar with the marine industry) they seem to be gaining popularity with the luxury center-console market, half as a fuel-saving metric but mostly because they're a talking point at the marina.

In recreational marine these types of products tend to spread based on word-of-mouth and sell fairly low quantities but at higher price points. Related: Seakeeper (https://www.seakeeper.com/), a fairly crazy gyroscopic stabilization system, wildly popular but fairly quiet in the tech world.

Timescale is built around a concept they call "hypertables", which automatically partition data into a set of smaller tables segmented by time range. Timescale exposes the time-series data as if it was a single table, but behind the scenes is managing queries against the individual table partitions and automatically creating new partitions as data is inserted.

By tuning the chunk sizes so their data fits in memory, many common queries gain a lot of efficiency. It's built around some assumptions of time-series data: Most inserts and queries are for recent data and are generally ordered.

I've had great experience with TimescaleDB for small-medium time-series loads such as sensor or analytics data; I've found it's pretty plug-and-play and have used it to store tables with ~1B time-series rows of geospatial data, sensor values, etc.

Similar dynamic slope soaring has been researched and demonstrated to dramatic affect by Spencer Lisenby and others: https://www.youtube.com/watch?v=nv7-YM4wno8&t=3s.

In the video I linked he describes how they engineered and flew a RC glider at a speed of 519mph.

Makes a lot of sense that this could be applied on a larger atmospheric scale for spacecraft.

3D printers have exited the hype cycle and now are in two categories:

People who bought them as a cool consumer gadget similar to VR. These printers are gathering dust because there ultimately isn’t that much interesting plastic junk to print.

Silently churning out hundreds of rapid prototypes a month for engineers & makers. In my circle it’s just become an assumption that you have 2-3 printers running when prototyping a project. 3D printers have just become a background tool rather than something that you actively tinker with + improve. I got mine down to decent print quality and haven’t upgraded it in years, but print daily!

Your comment is right above someone saying RJ-45 may be the worst connector! That’s just the internet I guess.

I think both opinions are right. If you’re a professional working in the field, RJ-45/8P8C is awesome because you can do large runs of cable and crimp on connectors after which is a lifesaver. The longevity of the connector is less important than ease of installation/replacement. I’ve done a little work with marine ethernet and CAN which uses M8/M12 circular connectors and those are pretty painful in contrast.

For consumers, it’s exactly the opposite. They’re unlikely to have the tools to crimp connectors. Most cables off Amazon come with lots of plastic that makes the cables rigid so it’s a pain to route and use in a home.

You’re absolutely right and here’s an open source self-hosted project for MBTiles: https://github.com/akhenakh/kvtiles

More info from the author here: https://blog.nobugware.com/post/2019/self_hosted_world_maps/

The vector tiles are much smaller in filesize than pixel data and the rendering technology is much better. Almost all the styling is done on the client side so the server is basically just querying a spatial database.

Will this be available for the open-source/self-hosted version? Would be awesome if this makes it there and we can self-host Timescale within AWS with S3 backing the storage of older data.

I use Timescale for internal analytics tools -- time-series metrics, logs, etc from hardware systems. Our deployments have very low CPU usage, so running on a single EC2 instance is feasible. Our main concern is always just running out of disk space. It would be amazing if this ends up being a config option in the open source version, where we can point the instance at an S3 bucket and provide the right IAM access.

Nice! Loved driving around and trying to break the physics.

At first I was disappointed you couldn't leave the road until I found you just needed to use more speed + boost. After that I spent all the time driving off-road.

I drove backwards at the start and clipped into some geometry, causing the car to gain a ton of vertical velocity and fly high into the air up to the clouds! When it dropped back down it bounced around a lot. Found you could reproduce this by finding where the road surface was clipped and gain some speed before entering it.

This made me think: You should add some planes!

Had a great time exploring.

Outer Wilds. The best sci-fi exploration game I’ve ever played. A very beautiful & profound experience that leaves you reflecting on life.

If anyone sees this and plays the game, don’t read any reviews or information online! Go in completely blind and you will not regret it.