Tiny quadrotor learns to fly in 18 seconds
spectrum.ieee.org
spectrum.ieee.org
A fulmar is a cliff nesting sea bird (with a defensive habit of noxious projectile vomiting). They spend their early life on a ledge, but one day they have to start flying. And if you are a fulmar you have a very limited time to learn to fly.
So the question is, how does a baby fulmar learn to fly in 10s!
It would be interesting to know how much computing power is required for training (compared to the power reqùred to run the controlling NN).
My own view is that the network architecture is important, so fulmar brains have evolved with a neural architecture that enables extremely quick learning to stable flight.
I played around with a few ideas on using GAs to evolve NN architectures for rapid learning during my PhD 25 years ago, but ended up going in another direction.
Spiders reproduce much faster and have a much smaller survival rate so they're well selected for that kind of instinct. Birds less so.
at least this is a good deal all butterfly have same color...
Behaviours can absolutely be learned and hardwired, given 1000s of years
As someone mentioned above, a deer is not born with random weights on its NN
There are undoubtedly similar reflexes that assist fulmars in learning to fly quickly, but that doesn't mean that rapid learning isn't also required.
As a baby I fell into a pool and needed to be rescued. I didn’t inhale water, but as generally happens I very much did just sank to the bottom. Babies can be taught to float at around 5 months, but it’s not reflexive.
I can't say what the extent of those swimming reflexes really is, but water births are not unheard of. Besides there's literally countless examples of this sort of thing, most prey animals can walk or even run mere moments after being born, cetaceans and ram ventilator sharks all know how to swim immediately or they would literally drown, insects can fly as soon as they hatch, etc.
Homo Sapience is special in this regard with almost all their firmware broken. Homo Sapience needs to learn hard how to focus their eyes or to hold head or to walk and even how to crawl. Seems like our abilities to learn are linked with brokenness of our innate software, probably it is a double headed causal arrow: our software is broken because we could overcome it with our general abilities to learn, and our general abilities to learn evolved because without them and without working genetic programs for specific forms of behavior we would be doomed.
I can't help but think that autism is the next step at breaking innate software and developing more robust general learning mechanisms.
This allows for more social/environmental impact on development than pure genetics, and we have developed better language and understanding.
There is no physical limit why we can't have both. .. and we don't have datapoints for time to evolve for every trails.
I hate it when biologists talked as if they knew it all
For what it's worth there are also countless animals which start out very helpless, including many birds which are wholly incapable of flight for some time, and for which learning is not always an easy process. The bird in question is closer to an exception than a rule.
Human birth seems strangely difficult. If you’ve never witnessed a live human birth it’s very traumatic with lots and lots of things that can/do go wrong. I can’t think of another mammal that struggles as hard as humans do during birth. It makes me wonder how humans have survived as long as we have.
We're effectively propagating that difficulty and it compounds generationally (imagine your bloodline has unusually large heads...) but we're smart enough to circumvent fate and the net result would appear to be positive.
Much of what humans do approaches the limit of cutting off the nose to spite the face. Is life better than it has ever been, practically speaking, everywhere? With some exception granted to the last couple of years, yes, and even without, probably yes.
I find it rather disturbing to think about. Diversification is really our only long term hope (hedging so to speak) and in many ways we're constantly moving away from that. If we were suddenly space faring colonizers, or if there were another dark age, then that would cease to be true, for better or for worse.
Especially for a mammal with front-facing eyes.
It's interesting to note our peers in this regard. Mice have a two-piece pelvis, and dolphins have no pelvis at all.
Thank you :-)
I think that is a specific cultural view, to assume it is traumatic. I certainly did not think so.
And that human birth is hard, has the evolutionary roots in going bipedal and walking upright as far as I know. Being upright blocks the pelvis, being down, opens it. Apes who go 4 feet, do not struggle (so hard).
Were you the one giving birth?
And certainly quite some women experience it as traumatic, but not all of them.
Either way, I am not sure that watching a couple of births qualifies anyone to say whether birth being "traumatic" is a question of cultural assumption :-)
No, but talking with women who say convincingly, they did not perceive it as traumatic is enough for me to conclude that births are not traumatic by itself. They can be, but I have the suspicion, that is culturally enforced, but that seems to change slowly.
It doesn't flop out of the nest immediately after leaving the egg, though, right? This is more like a 3 year old child learning to ride a bike on the first go (still impressive) than a newborn infant doing so.
Of course there is that bit where control of the muscles also has to align so there is building up of neural pathways that can be also more like getting hardware wired up. Getting it wired up takes longer in humans.
On the other hand, I could see a drone being easier for a computer because it behaves the same in any orientation (projectile motion + directional thrust). Unlike birds with their ears and their eyes, computers don't really have an inherent sense of direction.
I have raised animals apart from their kind from birth. They know instinctively how to do things that cannot be taught or learned. How can two spiders for example know how to spin a web without every learning from another being?
Once upon a time there was a bug that had a little sticky bit on it's butt, it had a billion descendants when one of them randomly had a gene that affected it's behavior such that it, I don't know, rested on high surfaces using the sticky bit and was safer from predators or something, and then had slightly more kids than the rest. And one of those kids randomly had a gene that gave it more sticky stuff, and one of it's kids used it a little more effectively, and so on and so forth. And that probably takes somewhere from tens of thousands to a few million years.
That's not meant to be literal, but that's the story in my head, and it doesn't feel like a huge leap to get to complex behaviors like webs.
A column of rock erodes, and a piece falls. The piece did not learn to fall. It just _did_, subject to the rules that governed the process of its creation (different meaning) and its environment.
There is no reason to assume any of that.
https://royalsocietypublishing.org/doi/10.1098/rspb.2020.066... is a recentish overview of existing literature and touches upon this in the section Wing flapping before flight.
What am I missing? Genuinely confused.
Edit: After googling, I can't find any "Fulmar problem". This is just basic evolution 101.
Have you seen baby deer?
I don’t know anything about the state of research here, this is just what I always assumed. I’m sure there are built in drives and reflexes, etc. It seems perfectly reasonable that they could be "higher level" than the ones I assumed (food, water)
If you've ever seen a newborn foal stand up for the first time, it's clear that's a built-in behavior. Standing up on those long spindly legs usually works the first time. So does walking, and within hours, running.
Lying down, however, is not built-in. I've seen a foal try to get back down on the ground, which is clearly trial and error, often ending in a fall. There's no evolutionary pressure to have that work right the first time.
Deer are precocial, while humans are altricial.
https://en.m.wikipedia.org/wiki/Precociality_and_altricialit...
Like others mentioned, there is a difference between species who can learn it more easily and those who learn slower.
https://en.m.wikipedia.org/wiki/Precociality_and_altricialit...
But some sort of learning (or callibration) is always required, because no individual is the same, so you cannot have it prehardwired everything. The basic movement of the muscles to fly, yes, but the exact movement and coordination needed to fly, needs the information of the specific mass and lengths of the wings etc. which are going to be different.
In short, "the hardware" is organic and not standartized.
It is kind of impressive that it works that well. But also shows how much at the beginning machine learning still is. Theoretically a robot could learn flying in the same way as a human, without crashing million of times first. And the robot could learn much faster than a human does.
But also in other machine learning experiments the AIs need way more practice than humans. They just can do repetitions much faster, and clone themselves.
I mean if we're going to use "AI" on controls, it better be looking for tuning something else, better still, we should only utilize the "optimization algorithms" parts of "AI" hence optimal control.
[1] Taeyoung Lee, Melvin Leok, N. Harris McClamroch. Geometric tracking control of a quadrotor UAV on SE(3). https://ieeexplore.ieee.org/abstract/document/5717652
Also, and correct me if I'm wrong, I think in industry these vanilla PD/PID controllers are used for attitude and position control of quad-copters. Like, I don't think PX4 or BetaFlight implement any geometric controllers in their code bases.
Insisting on PID is rigidifying part of your control setup. It's forcing NN to partially not learn the optimal control.
It's a bit like transformers for LLMs. If we could train raw NN in reasonable time it would outperform transformers. We are currently using transformers just because it makes learning of large models feasible not because it's somehow the best architecture for predicting language. The same way PID is something that sort of works if you lack computing power to create better control schemes.
I have a lengthy notes file with exact settings required to make ArduPilot work well with a small quad. The result is a great experience, but getting there was not!
Also of note for ease: The ArduPilot code base is a mess compared to PX4's.
There are easier ways, like using an existing config file someone posted on AP forum or rcgroups..
It’s not made specifically for small quads and it will never fly as well as BF or even iNav. I wouldn’t expect an agricultural drone to support turtle mode, so no air mode by default shouldn’t be surprising :)
Re code base: AP supports LUA so for small mods you won’t have to change the code base at all, compared to PX4..
PX4 is ubiquitous in the industry and in prosumer devices.
PX4 provides the autopilot stack. There's all kinds of developer drone releases with all of the parts working and assembled.
Both of them use mavlink and mavlink sucks. Mavlink is probably the worst protocol I've seen used outside of a hobby environment.
In my experience, Ardupilot is more of a hobby autopilot. That doesn't make it bad, but it does make it less useful to industry and prosumers.
The main issue other than this I've found is it requires 12 bytes of overhead; could be shortened to half this. What problems have you found?
DroneCAN... now that's a hot mess. I think you will be pleasantly surprised with MavLINK after trying to implement that. I can go into details, but it's a more exciting experience if the jump scares aren't ruined!
Where do I start?
The C library has many problems. First, many of the constants are provided as macros (completely valid for C) but this can become a problem in C++ which is generally migrating towards constexpr functions or objects instead of macros. Second, many of the macros specify de/serialization to bitfields and the bitfields raise compiler warnings about safety when compiled in C++ with `-Wall -Wextra`. That's on top of the library being far too complex. I understand the need for an XML generator, but as far as I understand, the C library and C++ library do not provide an easy way to dynamically specify message types at runtime instead of at compile time (contrast with other message protocols). The library's headers are sensitive to the order they're included and they provide configuration via declarations. One of the configuration items is "how many" global "channels" to allocate. These global channels are not thread safe and are used by, eg, QGroundControl.
The mavsdk library for C++ is a wrapper around the C library (for the most part) and it brings additional problems. Using the C library means that things aren't very type-safe under the hood. Mavsdk's use of C++ wants to be modern but makes several design choices that I disagree with, particularly around threading (instantiating the C++ library creates a thread to handle its own event queue and creating sockets via mavsdk C++ library creates additional one thread per socket) and serialization (the C++ code does not usefully provide type safe serialization. It's a common pattern but definitely not helpful on power-limited devices: power consumption and latency is higher compared to asynchronous socket programming, both of which are important for flight duration and control feedback. These design choices also make it difficult to unit test with Googletest's EXPECT_DEATH tests which uses `fork()` and can be sensitive to thread problems.
Auterion is writing a Mavlink library, libmav. I haven't yet looked at its internals, but I understand they want to address a lot of the shortcomings of the official mavsdk C++ library. So I have high hopes for that ... but alas already have things written to mavsdk's API.
Speaking of threading problems, I've encountered problems with QGroundControl's use of threads. A pattern common among these libraries is poor use of lifetime management, and poor use of shared_ptr and/or mutex to guard against races. It's the typical kind of thing that even experienced engineers make ... when they don't use tooling such as Thread Sanitizer or Address Sanitizer to warn (and raise the warning to an error) and/or insufficient test coverage.
Past the libraries, Mavlink protocol itself also leaves a lot to desire. It's a protocol that wants to be at nearly every layer in the OSI model. It smells of reinventing the wheel at all of those layers. At layer 2, there's the fact that mavlink is designed to be transmitted directly over a radio, telephone modem, a serial bus such as RS232, or even a multi-component bus such as I2C. At layer 3 we have device and component addressing, and forwarding. At layer 4 we have message sequences, checksums, and retransmissions. Then layer 5 is a little fuzzy. Even at layer 6 there is a custom file transfer protocol. It has custom implementations of a terminal session, !
It stinks to the core of a hobby protocol which "matured" by reinventing every wheel there could be. That's just my observation as a 20-year software engineer who entered the hardware/embedded field a few years ago.
Some components or implementations/firmwares have different interpretations of the meaning of data fields. If a coordinate is XYZ then what is the frame of reference for the XYZ? If you've got an orientation with yaw/pitch/roll, then what is the frame of reference? Is altitude based on AMSL or AGL or pressure instrumentation? Are we using WGS84 or something else? Even some messages themselves are deprecated, and there are some custom messages that vendors will use (remember: using custom messages requires a recompile of the library, with a customization to add the message definitions).
That's just what I have time to write off the top of my head. There's a ton more problems with mavlink, from an experienced software engineer's perspective.
I propose we don't even talk about MSP; Holy fuck.
> I am tolerating it for now for gimbal operations
Make sure you're using latest (there was a recent fix to a crash in the gimbal manager and reconnect code recently). The mavlink guys are usually pretty responsive to mavlink support questions on Github issues and discord. Many of the vendors are also on discord, useful if you're integrating with components.
> I need 1 byte for payload size, 1 byte for message type, maybe 1-2 for CRC... the rest of the header is a liability for OTA transmission time.
Yup, exactly. If the component and you are both already connected to an IP network then there are more industry standard protocols to use which perform better (battery, bandwidth, latency, the whole shebang) perform in a more expected behavior (a single message to a single IP destination is has well-defined routing rules, but a single mavlink message is likely broadcasted and possibly broadcasted multiple times (even when deployed to a single system), and can be secured better because security tools talk IP.
You mention DroneoCAN - I assume that's a typo for DroneCAN [0]. Can you use ROS2 [1]?
Contrast ROS2 with mavlink. The communication layer between different ROS2 components (nodes) can be changed for different implementations of transport and I've seen things like shared-memory (same-host, saw it at a drone conference) or replacing with another COTS (I don't remember which one though, but I think it was ZeroMQ or based on it).
If you can provide a ros service then that's a step in the right direction as far as I'm concerned. ROS already has existing services to interface with CAN [2]. Even if you have some specific reason to need DroneCAN, there appears to be a an example for using ROS2 to talk to DroneCAN [3].
[0]: https://dronecan.github.io/
I should note that my perspective subtly clashes with the designers of both MavLINK and DroneCAN: think these protocols should operate as you'd read a hardware datasheet: It should be easy to implement in any language by referencing a byte-aligned table, and have explicit instructions. Because, it's just bytes down the wire. The DroneCAN creators, and it sounds like MavLINK as well consider it something where you should rely on an official library. The Get/Set API is a hot mess? It doesn't matter if you expect no one to implement it because the expectation is to use the official library. You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me.
> You will also note that DroneCAN (and maybe mavlink? Not sure) devices have poor or no protocol documentation, which is astounding to me.
Astounding, yes. Surprising, no.
There is an entire ecosystem around those, so you can go piecemeal if you want.
It's a company, but also the name of that whole style of drones. Anything in the 65, 75, or 85 mm range can whoop, maybe more, idk.
I'd start with a 75mm brushless if I were to do things over again.
I do have a source I trust, and here's his guide for 2023 (apparently it's someone he endorses):
https://www.youtube.com/watch?v=lgeeR8TiuP0
https://www.fpvknowitall.com/ultimate-fpv-shopping-list/
Looks like Mobula6 or Mobula7 is still a solid choice.
Also, you'll need a controller and FPV goggles. I would get suggest picking up something nice-ish. They're very general and can be used with many different vehicles/projects. I got cheap goggles and upgraded immediately.
Any reason DJI products don’t make your list? Would have thought they are the market leaders, no?
I’m just looking to use it for fun. Occasional use. No vlogging or racing or anything like that. Thing is, with the many AliExpress drones on the market, I can’t tell what is trash and what will actually be fun to use.
Thanks.
"I want to take areal photos/videos": Cinematic Drone - Go with DJI stuff, Mavic probably
"I want to pilot a spaceship": FPV Drone - Get a TinyWhoop or simmilar
I've been describing the latter. If you go that route, unfortunately I'd recommend skipping the kit. I don't like the box goggles that will come with it because their FOV is aweful. The EACHINE EV200D is what I'd consider entry level, but it'll set you back about $300. Fatshark has some good stuff too.
https://www.fpvknowitall.com/fpv-shopping-list-goggles-video...
DJI does have a full FPV kit too and it's very nice and very expensive. Only reason I didn't mention it is it isn't what I'd consider a Whoop. It's in the "can give you stitches" class of drones and is not usable indoors. Still, really nice drone.
DJI's FPV googles and Air Unit digital VTX are worth a mention on their own because they're awesome and one of the few DJI products you can occasionally use with non-DJI systems. It's heavy though, so not likely to fit in a Whoop.
It has a few "addons" like optical flow sensors and external position trackers that let you extract ground truth attitude/position, which is helpful for research like this.
Not really "off-the-shelf," but it's a good thing to get if you care more about the controls, learning, trying new algorithms stuff more than sourcing parts, getting RC receiver/tx, sizing motors, that kind of thing.
For an example you can have a look at our video [2] (e.g. the disturbance rejection tests at 3:00 and after are solely using the optical flow deck)
The real interesting parts is, A) rapid simulation that just works when loaded into a real quadrotor and B) that the NN is generating the PWM pulses! Eliminating all those separate control systems into a NN is an interesting leap.
Actually drone interception is also a research topic.
One day though, it'll be true. And sunlight will be blocked by swarms of them. And obviously, the AI will win.
It progressively improved its algorithm using a series of feedback sessions.
It _improved_ but it didn't _learn_. Someone pre-programmed basic control and feedback parameters.
Don't get me wrong—this is still amazing and has useful applications. But can we please stop calling this improvement/refining/tuning process "learning"?
The code is open source, you can verify it yourself ;)