5 ms·

Apart from this project, does anyone know any other DIY quadrotor building instructions with cheap off-the-shelf materials?

pugworthy 3y ago
Have you looked into ArduPilot? https://ardupilot.org/ https://ardupilot.org/ https://github.com/ArduPilot/ardupilot https://github.com/ArduPilot/ardupilot
- IshKebab 3y ago
  Honestly anything with `ardu` in the name screams "I just learnt to code and I don't know what I'm doing". I know nothing about this space but I'd definitely check out the PX4 link that they other guy posted before this.
  - olex 3y ago
    Don't dismiss Ardupilot so easily. Yes, it grew out of Arduino Megas running the code with some stapled-on sensors, but that was many years ago - it's an extremely powerful and arguably more "hobbyist"-friendly platform that's very comparable to PX4. In my experience PX4 lends itself very well to more scientific or industrial use, especially when integrating with other on-board compute units that are part of the payload, whereas Ardupilot is much easier to get working and capable off-the-shelf. Both software stacks run on essentially the same hardware nowadays.
    - the__alchemist 3y ago
      I disagree about ease: ArduPilot is not easy to get working. It's a pain in the ass to get a flyable config, for say, a basic quadcopter. I now have a flyable config and notes, but it took me a lot of trial + error to get there. It has... surprising default settings , like going into a tumble if you 0 the throttle. Betaflight and PX4 are easier. 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.
      - 05 3y ago
        > I have a lengthy notes file with exact settings required to make ArduPilot work well with a small quad. 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..
  - cchance 3y ago
    For freestyle betaflight is the goto firmware
  - hadlock 3y ago
    Ardupilot is very very mature software. It stopped being able to be run on an arduino about a decade ago. There's a guy who has been doing aireal waypoint missions for miles and miles, as well as terrestrial boat missions lasting days. It's been adapted for sailboats as well.
    - pests 3y ago
      You referencing rctestflight?
      - hadlock 3y ago
        Yes, but I've also used it to do my own RC sailboat missions
  - wkipling 3y ago
    At least click the link before submitting your premature damnation
  - 05 3y ago
    The only advantage of PX4 is its license - it’s BSD vs Ardupilot’s GPL, so companies can use the code without giving back. The mindshare just isn’t there - PX4 is orders of magnitude more obscure, so instead of YouTube tutorials you’ll be trying to get help on PX4 specific forums or digging through the code base.
inetknght 3y ago
I work for a drone company. 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.
- the__alchemist 3y ago
  What is your take on the market share between PX4 and Ardupilot, and in which domains? Are any operations rolling their own firmware?
  - inetknght 3y ago
    > What is your take on the market share between PX4 and Ardupilot 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__alchemist 3y ago
      What problems do you have with MavLink? I will say I went on a (thankfully successful) goose chase this morning to figure out how to calculate the "CRC extra byte". I found the answer 2 ways: (1) by asking ChatGPT how to do it using the Python lib, and (2) by compiling ArduPilot and diving 10 folders deep into its build folder. 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!
      - inetknght 3y ago
        > What problems do you have with MavLink? 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.
jabroni_salad 3y ago
I got a tinywhoop kit for my nephew and my sister hated it, so it's probably good. There is an entire ecosystem around those, so you can go piecemeal if you want.
- littlestymaar 3y ago
  As a parent your deduction resonates well with my experience. How old is you nephew BTW?
- itishappy 3y ago
  +1 TinyWhoop 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.
  - leobg 3y ago
    You have a link for a model you’d recommend?
    - itishappy 3y ago
      Sorry, not really. I love my Beta75X2S, but it's almost a decade old at this point, and it's a fast moving field. 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.youtube.com/watch?v=lgeeR8TiuP0 https://www.fpvknowitall.com/ultimate-fpv-shopping-list/ 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.
      - leobg 3y ago
        I’d be interested in a kit. Containing everything. 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.
mlsu 3y ago
The quad these guys are using is a Crazyflie. Small, mostly prebuilt, targeted at researchers. 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. https://www.bitcraze.io/products/crazyflie-2-1/ https://www.bitcraze.io/products/crazyflie-2-1/
- the__alchemist 3y ago
  Interesting how they're using a PCB as the frame.
tamimio 3y ago
It depends what quad you are after, fpv, normal, something else? But they are all have some essential components and other extra ones, I am planning to make a full course soon including the software that will enable it to fly over the internet (cellular like LTE/5G).

pugworthy 3y ago

Have you looked into ArduPilot? https://ardupilot.org/ https://ardupilot.org/ https://github.com/ArduPilot/ardupilot https://github.com/ArduPilot/ardupilot

IshKebab 3y ago
Honestly anything with `ardu` in the name screams "I just learnt to code and I don't know what I'm doing". I know nothing about this space but I'd definitely check out the PX4 link that they other guy posted before this.
- olex 3y ago
  Don't dismiss Ardupilot so easily. Yes, it grew out of Arduino Megas running the code with some stapled-on sensors, but that was many years ago - it's an extremely powerful and arguably more "hobbyist"-friendly platform that's very comparable to PX4. In my experience PX4 lends itself very well to more scientific or industrial use, especially when integrating with other on-board compute units that are part of the payload, whereas Ardupilot is much easier to get working and capable off-the-shelf. Both software stacks run on essentially the same hardware nowadays.
  - the__alchemist 3y ago
    I disagree about ease: ArduPilot is not easy to get working. It's a pain in the ass to get a flyable config, for say, a basic quadcopter. I now have a flyable config and notes, but it took me a lot of trial + error to get there. It has... surprising default settings , like going into a tumble if you 0 the throttle. Betaflight and PX4 are easier. 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.
    - 05 3y ago
      > I have a lengthy notes file with exact settings required to make ArduPilot work well with a small quad. 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..
- cchance 3y ago
  For freestyle betaflight is the goto firmware
- hadlock 3y ago
  Ardupilot is very very mature software. It stopped being able to be run on an arduino about a decade ago. There's a guy who has been doing aireal waypoint missions for miles and miles, as well as terrestrial boat missions lasting days. It's been adapted for sailboats as well.
  - pests 3y ago
    You referencing rctestflight?
    - hadlock 3y ago
      Yes, but I've also used it to do my own RC sailboat missions
- wkipling 3y ago
  At least click the link before submitting your premature damnation
- 05 3y ago
  The only advantage of PX4 is its license - it’s BSD vs Ardupilot’s GPL, so companies can use the code without giving back. The mindshare just isn’t there - PX4 is orders of magnitude more obscure, so instead of YouTube tutorials you’ll be trying to get help on PX4 specific forums or digging through the code base.

inetknght 3y ago

I work for a drone company. 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.

the__alchemist 3y ago
What is your take on the market share between PX4 and Ardupilot, and in which domains? Are any operations rolling their own firmware?
- inetknght 3y ago
  > What is your take on the market share between PX4 and Ardupilot 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__alchemist 3y ago
    What problems do you have with MavLink? I will say I went on a (thankfully successful) goose chase this morning to figure out how to calculate the "CRC extra byte". I found the answer 2 ways: (1) by asking ChatGPT how to do it using the Python lib, and (2) by compiling ArduPilot and diving 10 folders deep into its build folder. 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!
    - inetknght 3y ago
      > What problems do you have with MavLink? 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.

jabroni_salad 3y ago

I got a tinywhoop kit for my nephew and my sister hated it, so it's probably good. There is an entire ecosystem around those, so you can go piecemeal if you want.

littlestymaar 3y ago
As a parent your deduction resonates well with my experience. How old is you nephew BTW?
itishappy 3y ago
+1 TinyWhoop 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.
- leobg 3y ago
  You have a link for a model you’d recommend?
  - itishappy 3y ago
    Sorry, not really. I love my Beta75X2S, but it's almost a decade old at this point, and it's a fast moving field. 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.youtube.com/watch?v=lgeeR8TiuP0 https://www.fpvknowitall.com/ultimate-fpv-shopping-list/ 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.
    - leobg 3y ago
      I’d be interested in a kit. Containing everything. 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.

mlsu 3y ago

The quad these guys are using is a Crazyflie. Small, mostly prebuilt, targeted at researchers. 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. https://www.bitcraze.io/products/crazyflie-2-1/ https://www.bitcraze.io/products/crazyflie-2-1/

the__alchemist 3y ago
Interesting how they're using a PCB as the frame.

tamimio 3y ago

It depends what quad you are after, fpv, normal, something else? But they are all have some essential components and other extra ones, I am planning to make a full course soon including the software that will enable it to fly over the internet (cellular like LTE/5G).