Hacker Newsnew | past | comments | ask | show | jobs | submit | snewman's commentslogin

A few questions / thoughts:

1. I didn't see it stated explicitly, but I presume the neural net is on the far end of a radio link somewhere, not running on hardware physically mounted on the drone?

2. After viewing the FPV video on the linked page: how the hell do human pilots even come close to this pace? Insane (even assuming that the video they're seeing is higher quality than what's shown on YouTube – is it?)

3. The control software has access to an IMU. This seems to represent some degree of unfair advantage? I presume the human pilots don't have that – unless the IMU data is somehow overlaid onto their FPV view (but even then, I can't imagine how much practice would be needed to learn to make use of that in realtime).


1) No, this is interesting specifically because it was all onboard, the drone has Jetson Orin NX on it.

2) No, the video the pilot sees is usually quite bad. Racing pilots usually use either HDZero (mid resolution video with weird pixel artifacts sometimes) or analog video (looks like a broken 1980s VCR). It’s amazing what they can fly through. These DCP spec drones are also slow by racing standards. Look up MultiGP racing, it’s even faster.

3) It can be overlaid but it’s useless. The human pilot is using the control sticks as the input to an outer rate regulation loop which contains the gyro as input to an inner stabilization loop though, so the IMU is still in the mix for human control.


1. It's entirely onboard.

2. The video they're seeing is worse. Spectators typically see the frames saved directly from the camera, but the pilot will be seeing them compressed and beamed over the air to their headset. See vid.

3. The human pilots do actually have access to it. Not directly, but the flight controller translates their inputs and makes use of the IMU to do so.

https://www.youtube.com/watch?v=kMGRLGkm0QE


> https://www.youtube.com/watch?v=kMGRLGkm0QE

I’m reminded of when the US military figured out it should just replace all its proprietary field drone controllers with Xbox controllers because every single grunt that enlisted already had 10,000 hours on the things. If the future of warfare is drones, Christ, that video is terrifying.


Funny you should say that. Gamepads are not quite what you want for drone piloting for three main reasons:

1. Less precise. Gimble size matters.

2. All inputs sprung. This is exactly what you want for your three rotational axis, but you absolutely do not want your throttle resetting to 50% when you lay off. You can fix this using 3D mode where the zero setting is in the middle, but then you lose even more precision.

3. Circular inputs. This means at low or high throttle you have less roll available.

The main reason you'd want a gamepad is the size and shape. They do make gamepad-style radios, like the Radiomaster Pocket, which combine the best of both worlds.

You can pick up a simulator for $10-20 if anyone wants to give it a whirl, and many are even on Steam, but the general recommendation is to pick up a dedicated radio as soon as possible.

Note that this mainly applies to FPV quadcopters, due to how sensitive and twitchy they can be. When it comes to controlling pretty much anything else (I'd argue even most planes) these advantages are no longer relevant.


The US military is not limited to using stock COTS hardware. They have imitated the form factor and general feel of those controls, but custom built and ruggedized.

https://www.wired.com/story/fmcu-us-military-controller/


The numbering jump is because there was "Claude 3.5" and then "Claude 3.5 (new)" and they decided to retroactively stop the madness and rename the later to 3.6 (which is what everyone was calling it anyway).


This one line was like 90% of the original implementation of Writely (the startup that became Google Docs; source: I was one of the founders).

The other 90% was all the backend code we had to write to properly synchronize edits across different browsers, each with their own bizarre suite of bugs in their contenteditable implementations :-)


This is a truly a great insight from how simple things can create industry giants like google docs.

I believe that a lot of problems can be converted into synchronization problems in browsers.

Are there any general synchronization libraries / applications that you suggest within browser / outside browser?

Thanks in advance.


Not OP, but common solutions in this space represent the state as conflict-free replicated data types (CRDTs). Some popular browser-based libraries for that are Y.js[0] and Automerge[1].

[0]: https://yjs.dev/ [1]: https://automerge.org/


By the way, for those wanting to do this but in Rust, there is https://crates.io/crates/yrs and https://crates.io/crates/automerge


And Loro [1], relatively new player which recently hit 1.0, with solid performance and some features the others don’t have

[1]: https://loro.dev/


Amazing, thanks for the link

What features does Loro have that others lack?


I thought it was a dynamic text box souped up with all sorts of tricks and semantics to make it appear like a rich text editor


I'm not sure exactly what you mean by "dynamic text box" but it was just a contenteditable div. There have been at least two complete rewrites since I was involved, nowadays I believe it's a canvas with all of the editing, formatting, layout, and rendering done "by hand" in JavaScript.


The kind of text box used in php forums ... called text area I think, and this would be hidden every time the focus went away and an HTML based layout presented in its place. This seemed to be clunky but I thought that was what made writely possible. ContentEditable is such a breath of fresh air had I ever known about it. I wonder if IE6 supported that.


The article clearly states that providing enough power to run the heaters was one of the challenges that led to the death of the probe. Satellites are rarely in the shade for an extended period.


Two different people I know with pro subscriptions report not having access yet.


There isn't a uniform temperature across the entire exchanger. There's a smooth gradient extending from one end to the other. If the outside is hotter, then the inbound air gradually cools as it gives up heat to the outbound air which is gradually warming.


NDAs don't generally have an expiration date. (As opposed to non-competes and non-solicitation agreements, which generally do.) An NDA typically ends only if the information in question becomes public, and then only for that particular information.


Note that very often, the solution process for a more difficult puzzle involves going through nontrivial logic to prove that a particular square must be water. It's important to be able to record non-obvious "must be water" squares.


Often the connection between the load balancer and app backend also uses TLS. I've operated a large / complex service on AWS and all internal communications at each level were encrypted.

Of course, in principle, a cloud provider could tap in anywhere you're using their services – ELB (load balancer), S3, etc. I presume they could even provide backdoors into EC2 instances if they were willing to take the reputational risk. But even if you assume the NSA or whoever is able to tap into internal network links within a data center, that alone wouldn't necessarily accomplish much (depending on the target).


Why do you say these are problems that are already solved? Sure, they're often variations on existing themes, but the same is true for chess positions and, honestly, almost everything else in any field of human endeavor.

Agreed that the absolute upper tier of chess players have trained longer and harder than most or all IMO contestants. Though I do wonder which (top-tier chess or the IMO) draws on a larger talent pool. To my understanding, a significant fraction of all high school students on Earth take some form of qualifying exam which can channel them into an IMO training program.

And as far as the being amenable to brute force (relative difficulty for humans vs. computers): it seems that chess was comparatively easier for computers, IMO problems are comparatively easier for humans, and the game of Go is somewhere in between.


These problems are literally already solved? Of course, the IMO problem designers make sure the problems have solutions before the use them. That's very different than math research, where it's not known in advance what the answer is, or even that there is good answer.


I'm saying they weren't solved until the problem composer (created and) solved them. They're not, in general, problems for which solutions have been lying around. So "these are problems that are already solved" isn't introducing anything interesting or useful into the discussion. The post I was replying to was trying to draw a contrast with chess moves, presumably on the grounds that (after the opening) each position in a chess game is novel, but IMO problems are equally novel.

It's true that IMO problems are vetted as being solvable, but that still doesn't really shed any information on how the difficulty of an IMO problem compares to the difficulty of chess play.


Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: