Some off-shore speedboats have really incredible self-righting because they've been designed to always have positive stability at all angles. One of my favorite videos of this in action: https://www.youtube.com/watch?v=Y2i1fOJ-itw
855 karma · joined May 3, 2016
Contact me: https://www.chrisdalke.com/ chrisdalke (at) gmail (dot) com
Some off-shore speedboats have really incredible self-righting because they've been designed to always have positive stability at all angles. One of my favorite videos of this in action: https://www.youtube.com/watch?v=Y2i1fOJ-itw
Stability of a floating object is determined by a "righting arm": A torque produced by the horizontal offset between the object's center of mass, and the center of buoyancy (The center of mass of the portion underwater).
Sometimes, that torque produces "positive stability" -- When the object tilts into the water, the center of buoyancy shifts in a direction that increases the righting arm force and pushes the object back upright.
On the other hand, other shapes produce "negative stability" -- Tilting the object shifts the center of buoyancy in a direction that reduces the righting arm force, so the object flips.
This is why ships are (roughly) square shaped when looking at a cross section: If you visualize a floating box tilting to the right, more of the right side will be underwater. This produces a righting arm force that turns the box back to the left.
The worst case for stability is a circle, since no matter what angle the shape is at, the righting moment is always zero -- There's no horizontal offset between the center of mass and center of buoyancy, so a circle never has a righting force.
I've been mostly focused on data from experimental electric vehicles, but I am also really interested in hearing your experience building a sensor network. I'd really love to hear what kinds of challenges you encountered building a distributed sensor system like this, particularly with collecting and sharing the sensor data. If you're willing, please reach out to me at the email in my bio!
Most of the concern with proposed Remote ID regulations was because 1) The regulation didn't actually solve the issue of untrained drone operators and 2) Added a high barrier to entry that would stifle the large hobby/enthusiast/startup industry while giving large companies like Amazon free reign over the airspace.
The FAA has decided that unregulated drone flight is an issue, and no matter what, they're going to tackle it. So I'm happy to see any solution that allows for the continued existence of the DIY part of the industry.
In my mind the "ideal" solution for DIY aircraft is a separate RC receiver-sized transmitter, powered over BEC, that you add to your aircraft when you are flying in conditions that require Remote ID. The transmitter would become another fixed cost in the hobby, but you could use it on whatever aircraft you're flying -- It would be linked to a pilot, instead of a particular aircraft. I have zero knowledge of RF physics and engineering, but I'd be happy if that was possible without a heavy transmitter and significant power consumption.
"The final Remote ID rule eliminates the requirement that drones be connected to the internet to transmit location data; the final rule requires drones to broadcasts remote ID messages via radio frequency broadcast."
This is great because RF broadcast-based Remote ID is much simpler and cost-effective to integrate into existing hobby or consumer drones. It could be built into RC receivers, or as a separate transponder.
A few things that I've encountered in the past that Hugo solves:
- Page links breaking and requiring rework if you change your site layout.
- Standardizing link formatting, including trailing slashes.
- Editing headers/footers.
- Dynamically deploying separate development & production environments, so teams can preview changes before releasing.
- "Draft" mode, to turn on/off pages without moving or deleting the file.
All of these things you could do by hand, but having them handled automatically makes it less likely that you'll make a mistake. That said, the way I've used Hugo on several projects is pretty similar to your philosophy: Most of the content (index page, styles) is hand-written HTML/CSS, and Hugo is just used to format generic pages and links.
One common pattern I end up using for a lot of imperative calls is a "useAsyncFunction" hook which runs any async function, returns state for loading, error, and the result of that function.
Unfortunately each library handles DOM manipulation, configuration options, callbacks, instantiation, etc. in its own way, and so I don't think there's any generalized solution.
For example, if you wanted to instantiate a charting library like uPlot (https://github.com/leeoniya/uPlot) you might instantiate a uPlot object storing state and methods for the chart. You can perform the chart initialization in a useEffect hook, and use a ref to keep a reference to the instance you've created.
He has a really great video series where he builds a small computer from scratch on breadboards. Also some other highlights:
Reliable data transmission, more educational: https://www.youtube.com/watch?v=eq5YpKHXJDM DIY VGA "video card": https://www.youtube.com/watch?v=uqY3FMuMuRo
Super educational, but if you want to get into more embedded hardware hacking, I would say that building a homemade computer like he does is probably not a super exciting place to start. I'd recommend picking up some Teensy 4.0 microcontrollers and build some small hardware projects with the microcontroller before diving into lower-level circuitry.
http://mh-aerotools.de/airfoils/javaprop.htm
The tool works for any fluid, you have to configure the fluid density and viscosity for air. It can auto generate props based on some initial state, or if you have an existing prop you can measure the various parameters and feed that in.
And my favorite feature: Nearly every part comes with complete data sheet and CAD models on the product page.
One anecdote: I ordered a large mounted bearing for an electric vehicle drivetrain, about a $250 part. Upon opening it, I was confused because the bearing didn't seem like it was seated correctly -- It was slightly off-axis. I called McMaster and they sent a free replacement the same day, no questions asked. I later realized the bearing was self-aligning and needed to be greased/mounted to align properly, so it was 100% my mistake and the first part was completely fine!
If you want to display a line chart that is 500px wide, for example, you know you really only need 500 data points. You can treat this chart as a histogram, and compute a min/max/avg for each value. The chart could display the min & max as a high-low band, and if you zoom in further, adjust the histogram interval and requery.
This is what a query would look like with this strategy:
start_timestamp: The start of the histogram range
end_timestamp: The end of the histogram range
num_divisions: The number of histogram divisions
select
start_timestamp + ((bin_id - 1) * ((end_timestamp - start_timestamp) / num_divisions)) as bin_start_at,
start_timestamp + ((bin_id) * ((end_timestamp - start_timestamp) / num_divisions)) as bin_end_at,
average_value,
min_value,
max_value,
num_values
from (
select
avg(value) as average_value,
min(value) as min_value,
max(value) as max_value,
count(*) as num_values,
width_bucket(data_points.timestamp, start_timestamp, end_timestamp, num_divisions) as bin_id
from data_points
where
timestamp > start_timestamp and timestamp < end_timestamp
group by bin_id
order by bin_id asc
) t;
I'm interested to see if anyone else has taken this approach, and if there are any performance considerations I haven't considered!It’s perfect for personal sites, landing pages, documentation, etc.
That recently changed when I switched to a 144Hz, 1440p display connected to a Windows desktop and a docked MacBook. The MacBook can only do 60fps on the display (It's just a laptop, so not entirely fair), but the desktop easily handles 144Hz and the experience is great. Everything is so smooth - scrolling, typing code, moving around windows. It's an incredible delight and the 60Hz -> 144Hz transition gives the same feeling as upgrading to Mac did back in the day.
I feel like my personal impressions have been distorted from years of running Windows on old, crusty hardware loaded with bloatware and all the quirks of a long-running system. Of course, the fresh MacBook felt fantastic in comparison. This article aligns with my suspicions -- Running modern Windows on next-gen hardware and an empty hard drive evens the comparison a bit, and with that perspective the differences aren't so huge!
The main server loop: https://github.com/URSolarSplash/Telemetry-Server/blob/maste... The device implementation for our hand-rolled serial protocol: https://github.com/URSolarSplash/Telemetry-Server/blob/maste...
In classic "college engineering project" fashion, the project is rather disorganized and very specialized to the technology we used on our boat at the time. Our telemetry server had an in-memory cache of latest data points which were relayed over serial with all the telemetry nodes. We used the telemetry system to carry throttle and all other control signals for the boat. We replicated all the data points to a secondary server running on a shore computer, so we had two separate sources of data logs.
I will note that since building that system, my philosophy has changed several times -- Today, I would likely not roll our own telemetry protocol, instead using something like https://msgpack.org/index.html or going all-in and using ROS on a larger project.
If you're interested in chatting more, feel free to send me an email (my username @ gmail). It's always great to see others go through the same experimental process with telemetry and data collection systems! (Also, check out bps.space on youtube, who has done a lot with telemetry on model rockets.)
anecdotally, I built a telemetry system for an electric boat with very similar architecture (RPi, python script for telemetry collection, 433Mhz telemetry radio) and were pretty easily able to push on the scale of ~100 data points at 100hz. Part of that was efficiently (and manually) packing each data point into the minimum space required, pretty much just the raw data and a checksum. But from what you’re describing I definitely think you can push your system further without rewriting significantly.
However for IoT or hardware time series I’m left with a few questions... A few things it seems are not possible:
- An IoT device with limited network connection that batches data points while offline
- manually loading time series data from disk at a later date on an offline device such as a weather station
- loading data “in the future” (data points with bad/erratic timestamps, memoized predictions)
I guess the hardware / IoT use case is pretty small compared to infrastructure monitoring, where Timestream’s design choices make a lot of sense.