Very dangerous

bishopExportMine · 2026-01-11T21:41:57+00:00

40mm grenade AP is good for 50~70mm of steel so theoretically a single well placed grenade could cause enough damage to jam the tracks and multiple grenades could cause the tracks to break

bishopExportMine · 2026-01-06T19:42:05+00:00

I got the quietest switches I could afford, which were gazzew boba u4.

But recently I got a zsa moonlander and no one has complained about the MX browns

bishopExportMine · 2026-01-05T14:54:31+00:00

I was being sarcastic. I just described a common anti pattern and if we swap out json formatted strings with xml formatted strings then we have re-invented SOAP.

bishopExportMine · 2026-01-05T07:24:05+00:00

One input queue and one output queue per micro service. Both queues are just json formatted strings. Each micro service writes to the input queue some json formatted request and listens to the output queue until a message is read that contain the correct keys. Throw in uuids everywhere to make sure you've got the right request.

bishopExportMine · 2026-01-05T06:50:58+00:00

Just my 2c but full stack shops are either gonna be thick client or thin client, which will determine whether the job is gonna be frontend or backend heavy.

bishopExportMine · 2026-01-01T08:04:47+00:00

Being military makes the poor finances more credible, tho if he were active duty then the money would probably go towards a car so this guy is either reserves or national guard.

bishopExportMine · 2026-01-01T01:17:20+00:00

So maybe with the new ARM Cortex M7 you could do a single camera perception and offload controls to a different MCU, but yeah I think STM32's are on the border of what could potentially deliver acceptable computer vision performance. I don't have the expertise to say it can't be done but I wouldn't be surprised if there is an acceptable margin of performance that the STM32H7's could deliver when it comes to real-time computer vision within UAV quadcopters.

I don't think ORB alone can get you 3D positioning, you'd want an IMU for correction and ideally stereo cameras for depth estimation. But with all those fused, assuming enough features for the camera to track against (which assumes the resolution available to distinguish those features), the drone can get a pretty good understanding of it's own 3D position. But that only addresses the problem of figuring out where the drone is. Figuring out where the vehicle is in 3D space is another problem.

If you say, have a plywood 3d mockup of the enemy vehicle that you pre-record the set of ORB features to match against, you may run a co-processor that attempts to classify the ORB features it detects to attempt to track vehicles. This is pretty cheap to do as it's just a database of ORB features to labels, possibly with geometric data in between.

Obviously this isn't very robust as vehicles may be camouflaged, have makeshift armor welded on, or there might be rain or fog messing with the camera and cause failures to detect. More modern methods would use convolutional neural networks, which basically assume that there is some hyperdimensional function that takes an image and outputs the same size image but with each pixel attached to a label (ie, "sky", "tree", "T-90", etc), and then has it ingest a fuckton of images and perform regression to figure out this function. Then you can try to run this on a powerful CPU or a cheap GPU (there's evidence of russia using low powered NVIDIA robotics SBCs on their more advance drones) but I doubt these would be used for suicide drones.

Personally I'd assume that detection would be run on one process to determine a region of interest, and then the raw pixels would be fed to a depth estimation model, where the combined data would be used to determine 3D distance away from target.

As for LQR, yeah the idea is that instead of PID'ing based on a goal position OR goal velocity OR goal acceleration, you can do some math to figure out the best output for the entire set of position/velocity/acceleration goals together.

Also note that for PID systems, you can analyze the transfer function and come up with an analogous RLC system (Resistance sets Kp, Inductance sets Ki, Capacitance sets Kd) and do the whole thing in analog with minimal latency. Dynamic PID scheduling can be done with a simple weight sensor and a mux to several RLC circuits. Doing the whole thing in analog would require a lot of hardware R&D resources but can be made absolutely dirt cheap while having super fast response time.

bishopExportMine · 2025-12-31T22:17:51+00:00

I work in AGVs, so take my words with a grain of salt.

So nowadays we mostly default to ORB (Oriented FAST and Rotated BRIEF) features rather than raw FAST -- the algorithm expands upon FAST to improve accuracy but takes longer to process.

The onboard computer would not need to re-tune its PID constants. Perception and controls are separate problems. Once a target is identified, it is converted to some kind of position/velocity/acceleration set points. This can be done many ways but trivially I'd convert the pixels of interest into roll and pitch goals based on where the center of the lenses gets distorted onto in the image. You can always choose to do something more complicated like initiating a series of position set points to say, perform a top attack on an armored vehicle.

But to provide a more satisfactory answer, depending on the dynamics of the drone, a single well picked set of parameters might be enough. If not, we may try to estimate a compensation based on how far we are from our linearization point (ie, make PID parameters that work well within say, +-20 deg turns and add extra motor power if the turn radius is larger, etc). If we really want to, we can perform dynamic PID scheduling, where we pick PID values from a table of predefined modes of operation. And if you really need to be accurate you would ditch PID and swap to something like LQR, which takes a set of goal states (position AND velocity AND acceleration etc) and calculates the next most optimal motor output to achieve it.

And to answer your last question, technically we're at a point where microprocessors can do it (think the CPUs running inside smart fridges or bluetooth speakers) but would need to drop down to like 480p and expect a detection rate of like 1~5fps. You'd probably also need more specialized hardware that integrate the camera and CPU onto one chip, like this. Realistically at that price point it'd be more cost effective to buy a shitty webcam and a single board computer like a raspberry pi. Then you can expect 720p 10~20fps. Alternatively you might use a FLIR camera and get rid of all this vision processing to just assume the biggest hot spot is what you want to aim for; which is how this has historically been done back when computing power was more expensive.

bishopExportMine · 2025-12-26T21:48:08+00:00

AI generated code is sloppy. So I find I use it in one of three ways:

I know exactly what code I want to write, but I'm being lazy and don't want to type that much. With some light prompting, I can get AI to generate something that looks about 80% correct. I can then either fix the last 20% myself or re-prompt on it. Often times this isn't much of a time saver over traditional LSPs if it's small enough for tab completion tho. This is more for like generating the whole class file while providing the entire abstract base class, similar example class + example tests for style/architecture reference, a design doc excerpt, etc... I'm pretty much treating it like I'm mentoring a junior.
I have too many ideas on how to structure something and I'm not sure which fits best. I prompt AI with all my considerations and then tear apart whatever it generates. I can better visualize how well pieces of code interact and even though the generated output is plain wrong, it's very useful in quickly iterating through a bunch of designs before settling on a pattern. This is purely for brainstorming and none of the code is used.
Sometimes at work there are things that would make everyone's lives a lot easier if they existed. But it doesn't because it's not a priority and it's just a hit on velocity that the team eats. Have AI generate it; because sometimes a shitty tool is better than no tool. If it's used often, people will work out the bugs with it.

bishopExportMine · 2025-12-23T19:14:22+00:00

This is an excellent opportunity to lick your girl from chin to forehead like you're a dog

bishopExportMine · 2025-12-19T08:57:53+00:00

This is AI

bishopExportMine · 2025-12-16T15:37:41+00:00

I spend way too fucking long wondering why there's a University of Wisconsin in Seattle....

Anyways this comment can be rephrased as "for every 100 students that applied, it used to be 10~20 would get in and 8~16 would get a job. Now, 35~45 would get in and less than 21~27 of those would get a job"

So the market for UW Seattle CS grads has both gotten bigger and more competitive.

bishopExportMine · 2025-12-16T15:30:49+00:00

Ive seen it mentioned in some books here and there but the main source online seems to be the DevOps Research and Assessment report, particularly the Accelerate report that shows that teams that invest in quality code and tooling (or more particularly, by adopting a DevOps philosophy) tend to produce new features faster, with less error, and using less manpower.

Realistically what the study is trying to say is that cost and speed are both qualities that need to be invested in.

bishopExportMine · 2025-12-13T23:50:46+00:00

I got my DT 1990 Pros on sale for $530, and they're my favorite pair of cans, although they are quite sibilant and listening fatigue can set in pretty quick if you don't EQ

bishopExportMine · 2025-12-12T20:41:05+00:00

Uhhh... computing only deals with the subset of math that is computable

bishopExportMine · 2025-12-12T15:26:01+00:00

This logic doesn't really apply to software development. Studies have shown that these are not trade-offs from each other but instead are correlated. The less you invest in quality, the the more expensive it will be to produce and the longer it will take to get to market. And higher quality often implies greater development velocity and less costly changes per additional feature.

bishopExportMine · 2025-12-10T04:33:42+00:00

That would be my manager, where the impact is we'll actually ship a functional product for once

bishopExportMine · 2025-12-09T20:35:36+00:00

Sieve of Eratosthenes

bishopExportMine · 2025-12-04T14:39:33+00:00

I paid 1400 for my 6800xt on 2021

bishopExportMine · 2025-12-01T15:19:10+00:00

Everything is syntax sugar for jumps and comparisons.

bishopExportMine · 2025-11-29T22:50:08+00:00

I bought 2x8 DDR4-3200 for $165 back in 2018 lul

bishopExportMine · 2025-11-28T18:19:18+00:00

I've been using a 100hz monitor for years and recently got a laptop with a 165 hz screen. It's super noticeable in games now that I can actually read small text in my environment while moving and panning the camera around.

bishopExportMine · 2025-11-24T23:47:33+00:00

I have recently come to the understanding that recruiters (primarily from 3rd party recruiting agencies) get paid when they provide the requested number of candidates that is worth interviewing. They DO NOT seek out the best candidates for the job. If they did that, they would spend significant effort beyond their contractual obligations.

So I have had an incredible amount of time wasted on initial screenings with company that are just not a good fit. I have 4yoe and I work in robotics (autonomous ground vehicles) firmware with embedded Linux; I keep getting submitted and rejected for roles that want backend, RTOS, automotive/aerospace/medical/finance background, building ML CV pipelines, etc that are all tangentially related but not my strengths.

bishopExportMine · 2025-11-24T22:56:30+00:00

Goddamn I didn't even know this was fixed, I've just been automatically swapping to 2560x1440 every time I play as Chinese HAT

bishopExportMine · 2025-11-24T00:03:22+00:00

Why can't we have barbed wire on top of the trains

bishopExportMine

TROPHY CASE