close-circle
Close
0%
0%

Coaxcopter

Autonomous, efficient, LIDAR-enabled flying robot. Just a pet project.

Similar projects worth following
close
I have always wanted a flying robot but never got one because none of the available robots gave me the feeling that they were really autonomous. Someone always has to hold a remote, or the robot has to stay in a specific controlled environment, or some off-board vision systems are required.

With my own design, I'd like to achieve a high degree of autonomy, in terms of robot brains and flight time. Eventually, I want to be able to use this robot for exploration, mapping and 3D reconstruction of spaces. I think that if I can get this robot to autonomously move in a dynamic real-world environment, other people will be able to use this as a platform for a virtually unlimited number of tasks.

OK, I think I should preface this by saying that this is a high risk project. Many things could go wrong, the most obvious one being time. I do have a fulltime job and I cannot spend as much time on this as I would like. Now, even if I do not have the time to advance at a sufficient pace to be competitive in the HAD prize, I still think this can be very rewarding for me, just for the experience. And I might get an autonomous flying robot out of this, how cool is that?

Why would I want to build a flying robot? Because it's really cool and because I can. Also, there are many possible uses of such a platform. Most companies sell those machines to the consumer/hobbyist as a toy. A few companies are trying to use them as surveillance/inspection tools, or to deliver packages. I think there are many more uses that still need to be discovered for these robots and are just waiting for the right capabilities.

Today, most flying robots are just RC planes and (heli/multi)-copters. Some constructors add features such as basic collision avoidance, follow-me and return-to-home capabilities. A few machines are close to being autonomous but only work in specific environments. Probably the best example would be the demo Astec/Intel presented at CES two years ago. Due to how the realsense technology works, this flying robot only has a very limited sensing range and works indoors only. In addition, because of its mechanical design (quad or hexacopter), it has a mediocre battery life.

Now, how can one build a flying robot that is more autonomous that what exists out there? I think the answer boils down to:

  1. More data about the environment. The more data the better. Quadcopters began to be a thing when IMUs got cheap and tiny. What if LIDARs got affordable and compact? What use could one make of it? Get a better knowledge of the environment!
  2. Better efficiency. I do not care if my flying robot can do flips or beat speed records. I'll be happy with a boring hover flight.

To achieve these goals, I have made the following design choices:

  1. Include a maximum of (useful) sensors onboard. I hinted at it previously, I want to have a LIDAR onboard.
  2. Have a system capable of processing all the data and making decisions onboard.
  3. Reduce the number of rotors to a minimum and use the densest power source available at this moment.
  4. Optimize mechanical structure to reduce weight while still protecting rotors (and people) from accidental contacts.

I'm aware that there are many hard challenges I would have to solve or get around for this to work. This pet project is about having fun, learning and trying out things, and I'm not aiming to have a "professional" solution in the end.

mini4412CoM.jpg

MINI4412 compared to an Odroid U3

JPEG Image - 104.22 kB - 04/09/2016 at 23:02

eye
Preview
download-circle
Download

electronics.jpg

Electrical wiring schematic

JPEG Image - 246.35 kB - 03/15/2016 at 00:44

eye
Preview
download-circle
Download

  • 1 × Boardcon MINI4412 Small Computer-On-Module used as main processing unit on the CoaxCopter.
  • 1 × STM32F407VG Flight controller processor
  • 1 × Venus838FLPx GPS
  • 1 × MPU-6000 IMU
  • 1 × MS5611 Barometer

View all 16 components

  • CoaxCopter Motherboard - Two Layer Version

    luca09/23/2016 at 18:10 0 comments

    Hi there Hackaday,

    First off, thanks again for selecting me again as a finalist in the Hackaday Prize. That's great!

    I've been quiet lately but made lots of progress. The CoaxCopter motherboard (in its 2 layer version) is completely routed and will be send to the fab service soon. I attached a view of the PCB below!

    I'm cramming way to much stuff on this board and it is very hard to route everything with only two layers. I'm am seriously worried about signal integrity and EMI. I'll see if I can optimize a bit more (not sure it is possible!) and might have a go at a 4 layer version. Here's all the components I have on my motherboard:

    • Exynos4412 module
    • STM32F407 microcontroller interfaced with the Exynos through UART (x2) and SPI (x1), with appropriate level-shifting
    • 3-port USB 2.0 hub connected to the Exynos:
      • One port dedicated to the WiFi module
      • Two spare ports available for future extensions
    • Communication:
      • WUBA-171GN WiFi module (up to +23dBm in TX, pretty sensitive RX)
      • 433MHz radio for telemetry / long range communication
    • 2 ESCs
    • 3 Camera ports:
      • 2 MIPI-CSI connected to the Exynos through a switch (compatible with Raspberry Pi camera modules)
      • 1 DVP connected to the STM32F407
    • 1 LIDAR
    • 1 Sonar module
    • Connector for top module containing GPS, LEDs, ON-switch.
    • 2x Connectors for bottom components (servos, lidar, bottom camera, sonar)
    • Battery voltage monitor
    • Some status LEDs.

    The SMD components are all 0603 except for two caps and a resistor in 0402 by the crystal (near the top-right of the STM32). Traces are mostly 6 mil wide unless they're carrying higher currents.

    Cheers,

    Luca

  • Project log #6: 3D printing some parts

    luca05/27/2016 at 19:29 0 comments

    I haven't had much time to spend on this lately, sorry about that. If you haven't seen the news, I've been selected as a finalist in the hackaday prize. Yay! Thanks HAD team!


    I've spent that last few weeks thinking about the mechanical design of my robot a bit more. I've revised the way the lidar integrates with my robot and the way the control surfaces work. With these changes I hope to achieve a lighter design and better control of my robot. For more details, see the previous build log (#5) [More details will be added shortly!].

    Now that the mechanical design is stable enough, I've decided to go ahead and start printing parts with my 3D printer. Here are some images:

    3D printer (reprap/prusa)

    Printed parts

    I'm now mostly done with the printing. I will probably print a few more parts to have spares (my printer is located in Europe while I'm currently living in the Boston area... not super practical :) ) .

    The PCB design will be next. Stay tuned for more build logs!

  • Project log #5: Mechanical design philosophy

    luca04/28/2016 at 21:09 0 comments

    As I explained in the project description, I'm looking to build a robot with a relatively long flight time. This means optimize the efficiency of my thrust generating components ("powertrain") and reduce the overall weight to a minimum.

    Powertrain

    To generate thrust, I need to have motors and propellers on my robot. It is more efficient to have one bigger propeller than multiple smaller propellers, I will thus reduce the number of motor/propellers to a minimum. Having one single rotor complicates the design as it will have to be rather large. Also, a mechanism to counteract the torque produced by the propeller has to be added (e.g. a tail rotor, as used by helicopters). Furthermore, there would be no way to recover the aircraft if this rotor were to fail. I have hence chosen to go for two contra-rotating rotors. To control the pitch and roll angle of my robot, I will use control surfaces (aka control vanes) below the two rotors. Changing their angle with respect to the air flow will allow me to control the aircraft.

    I could not find any contra-trotating motors that where lightweight and efficient. I will thus get two separate motors and mount one on top but opposed to the other (see pictures).

    Mechanical structure

    To provide support for the two motors, I have to design a structure that goes around the propellers. A duct-like design is an obvious choice. Not only is it rigid, it also enhances performance by reducing propeller tip vortices, provides protection from the propeller blades and reduces noise. This duct will be attached on the bottom to a "core tube" containing the lower motor, onboard electronics and power and on top to a smaller tube ("top tube") containing the top motor. Control surfaces are attached to the bottom of the core tube to provide attitude control. These will be adjusted using servo motors contained inside the core tube. In order to achieve a lightweight but rigid structure, I decided to go for carbon fiber sheets. Even the thinnest carbon fiber sheets have sufficient mechanical properties to serve as the main structural component of my robot, if used in the right way: they are very resistant to tensile and shear stress. In addition, using thin sheets will allow me to cut them easily, either by hand (exacto knife) or with a waterjet cutter. I would've loved to use a laser cutter but the epoxy contained in the sheets releases toxic fumes. The different sheets will be held together by epoxy glue and other diverse fasteners, depending on the needs. The different tubes will be made by rolling those sheets, as obtaining custom made carbon fiber tubes is very expensive (especially large diameter ones).

    --

    A more complete description will follow...

  • Project log #4: Time management

    luca04/25/2016 at 14:03 0 comments

    Here's an attempt to explain how I will manage my time on this project. I do have a full-time job, so things might shift.

    • End of April, early May: make significant progress on the mechanical design and pcb design. Send the pcb design to the fab house.
    • Mid, end of May: order components, assemble components as they arrive
    • Early June: assemble robot, test components
    • End of June: have the robot fly autonomously, using a minimal set of sensors, in a controlled environment
    • July and later: software development.

    This plan will evolve and get more detailed as I go...

  • Project log #3: Getting Ubuntu 14.04 to boot on the MINI4412

    luca04/09/2016 at 23:32 0 comments

      The MINI4412

      I have chosen Boardcon's MINI4412 module to serve as "brains" of my robot. It packs a quadcore Exynos4412 processor clocked at 1.6GHz, 2GB of RAM and a Mali-400 GPU (which I probably won't be able to use as it is a closed system...). All that power is packed in a small form factor: 65x47x4mm. Here is a picture of it against an Odroid u3, which packs the same Samsung SoC:

      Getting started

      The box I received from Boardcon contains the EM4412 development board, which has everything I need to get started with the MINI4412. After connecting the board to my laptop through serial, I was able to enable the onboard ethernet module and connect to my router. Sadly, the MINI4412 comes preloaded with some very minimal, unknown Linux distribution (busybox), where features such as wget or a package manager are missing. That's why I decided to use Ubuntu 14.04 Core with it instead, as it provides a rather complete system while still being very compact. To use this Linux distribution, I had to reconfigure the linux kernel as well as use my own ramdisk image, as the ones Boardcon provides do not support Ubuntu 14.04.

      If you are reading me and are trying to follow my steps, know that lots of googling is required to figure things out, as not much documentation is available. The xda-developers forum is a helpful resource, as this system works in similar ways to android smartphones. Also, check out my GitHub repo where I have put more documentation.

      Configuring the linux kernel, the initial ramdisk and the system image

      The 3.0.15 kernel Boardcon provides needs to be reconfigured in order to work with Ubuntu 14.04. I have tried more recent versions of the linux kernel but I could not get them to be stable (kernel panics after a few seconds with an untraceable error). I think boardcon added some modifications to the kernel but I did not have time to investigate that. Instead, I played with the settings and found a working configuration (available on the github repo). This involved a lot of trial-and-error and some settings might be suboptimal. I might update those in the future.

      The initial ramdisk (initrd) also needed updating as the one provided by boardcon was not sufficient to setup the Ubuntu system. I wrote my own version based on pieces of code I found laying around the web. The ramdisk image is also available on my git repo.

      I flashed the MINI4412 with Ubuntu Core 14.04.4 LTS, available [here]. If you're interested in creating that system image, you can follow the instructions I put on the git or ask me for the image. I won't go into details here.

      Running Ubuntu 14.04.4 LTS on the MINI4412

      With the above explained changes from the default factory version, the MINI4412 boots Ubuntu 14.04.4 LTS in less than 5 seconds, which is pretty impressive. After boot, the ram usage is 22/1989MB. After expanding the system partition, the available disk space is 1.4GB, which is plenty for my use. To get a better feeling of how powerful this board is, I have benchmarked the system using sysbench.

      sysbench --test=cpu --num-threads=4 run

      The task is completed in 37.848s. For comparison, a raspberry pi 1 needs about 500 seconds, a raspberry pi 2 about 76 seconds and a raspberry pi 3 about 49 seconds. Pretty happy about the performance of this little thing.

      Next steps

      Software-wise, the next steps are:

      1. Keep testing my system, make sure it is stable even under heavy load, see if some kernel settings could improve things. For instance, I would like to enable the ondemand cpufreq governor.
      2. Install ROS, play around a bit
      3. Make sure the WiFi module I'm getting is compatible (not sure about the drivers)
      4. See if I can hook up an OV5642 camera module to it, either over CSI or parallel interface. Otherwise I'll go for a usb camera (less optimal).

  • Project log #2: Electrical wiring

    luca04/09/2016 at 18:33 0 comments

    In the past few weeks I have spent some time thinking about the components I want on the CoaxCopter. Here's my current shopping list along with a wiring diagram.

    Processing:

    I want the robot to be as autonomous as currently possible. For this, I will need an onboard computer with a reasonable amount of processing power (Linux + ROS). I have chosen the MINI4412 available from Boardcon (Chinese supplier of ARM developer kits), a cheap Exynos4412-based Computer-on-Module. The Exynos4412 has about 12-15 times the processing power a basic Raspberry Pi has, which should be plenty. The online documentation on this board is scarce, but the files provided by the manufacturer along with the documentation available for the Odroid u2/u3 (based on the same SoC) will be enough. I'm also doing this project to learn :)

    In addition to the above mentioned board, I need a realtime system to control the robot while in the air. For this, I have chosen the STM32F407 microcontroller. It has the oomph and interfaces to work as a powerful flight controller and I have some experience working with ARM Cortex-M microcontrollers. The STM32F407 will be in charge of most of the sensors, the 433MHz comm channel, the two brushless motors and the attitude control servos. I'm hoping all of that fits! (I still have some doubts about the image processing required for optic-flow :/)

    Sensors:

    • IMU: MPU-6000
    • Barometer: MS5611
    • Cameras: 2xOV5642 (1:optical flow, 2:taking pictures, hooked up to the Exynos SoC)
    • Lidar: LidarLite v2 (v3?), rotary encoder, servo
    • Ultrasonic sensor: MB1240
    • GPS: Venus838
    • Various current sensors (probably ACS712)


    Communication:

    • RFM22B (433MHz, long range, backup channel)
    • WUBA-171GN (High power WiFi module, should allow for at least 150m range in the open, less indoors)


    Motors:

    • 2x 3508 380kv Brushless motors (not sure which brand yet, probably Arris)
    • 2x DYS BLHeli Mini ESC's (I thought about integrating my own ESC, but that is too much for the v1)
    • 2x Mini servos for attitude control (not sure which model yet, plenty would do the job)


    Power:

    • 4x NCR 18650B (3400mAh, recognized among the RC community as the highest power density currently available)
    • Various voltage regulators (5V, 3.3V, 1.8V)

    The following schematic explains how these components will be connected together:

  • Project log #1: Robot characteristics

    luca04/09/2016 at 17:26 0 comments

    As I suspected, I have been rather busy at work. Nonetheless, I have defined the main components of my robot as well as an estimated weight and autonomy.

    Here are the main characteristics of my flying robot:

    Onboard components:

    • CPU/GPU (Quadcore ARM-A9 clocked at 1.6GHz/core, 2GB ram, Mali-400@533MHz)
    • Flight controller (STM32F407 clocked at 168MHz, with hardware FPU), connected to the following sensors:
      • IMU, GPS (Venus838 with 50Hz update rate), Ultrasonic range-finder, Optical flow cam, State-of-the-art lidar (spinning lidar-lite, 360°H/60°V, 40m range, 5Hz update rate), barometer, ...
    • 2x 3508 380kv brushless motors (T-Motor or Arris, not sure yet, looking for highest efficiency) with 15" props.
    • 4x NCR18650B lithium-ion cells (14.4V, 3400mAh)
    • 2x Mini Servo motors for attitude control

    Dimensions:

    • Cylindrical structure
    • Diameter: 400mm
    • Height: 355mm

    Structure: entirely out of carbon fiber sheets, rolled up if necessary. These sheets can be cut with a razor knife or with a waterjet cutter (a possibility for the v2 if I have the funding...). I might lasercut templates to get precise cuts.

    Physical properties:

    • Total weight: 800g (estimated), the breakdown is as follows:
      • 200g for the mechanical structure
      • 200g for the batteries
      • 230g for the motors and propellers
      • 170g for electrical components and other miscellaneous components
    • Thrust @50% throttle: 800g (estimated)
    • Power at hover: 4 amps @14.4V (57.6W)
    • Flight time: 50 minutes

    These values have been estimated based on the components' weight, the motor/propeller thrust/efficiency and the batteries' max. energy. Weight might be over/under-estimated, but should be very close to reality. Flight time might changes depending on that and on the final motor/propeller efficiency.

View all 7 project logs

Enjoy this project?

Share

Discussions

Comedicles wrote 04/21/2016 at 16:48 point

FYI, mass of NanoPi 2 with connectors is 24g. NanoPi M2 is 37g. What does your module weigh after you connect? 

I have a bunch of original and discontinued NanoPi I can give away. They will run Debian on 400MHz  ARM9 S3C2451. 19g with WiFi and the works. Much lower power use than the Quad core units. Since an Arduino can keep a quad balanced, how much compute power do you need for the rest, granted more intense and time critical work?

P.S. Most of the board and module makers have 5K to 40K 4412 chips they stocked up on when the EOL came out. That was a while ago. I would not count on them being around for long before prices rise from legacy demand.

  Are you sure? yes | no

Comedicles wrote 04/21/2016 at 16:41 point

FYI, mass of NanoPi 2 with connectors is 24g. NanoPi M2 is 37g. What does your module weigh after you connect? 

I have a bunch of original and discontinued NanoPi I can give away. They will run Debian on 400MHz  ARM9 S3C2451. 19g with WiFi and the works. Much lower power use than the Quad core units. Since an Arduino can keep a quad balanced, how much compute power do you need for the rest, granted more intense and time critical work?

P.S. Most of the board and module makers have 5K to 40K 4412 chips they stocked up on when the EOL came out. That was a while ago. I would not count on them being around for long before prices rise from legacy demand.

  Are you sure? yes | no

luca wrote 04/21/2016 at 16:49 point

I will get back to you regarding the weight of my Exynos4412 board. The time critical work will be happening on the microcontroller (real time system), not on the Exynos. I'm not sure how much horse power I will need on my CPU module, but more is better, since I plan to do some heavy stuff like point cloud and advanced image processing. Eventually I want to do SLAM. 

In addition, I like that my CPU board only has the Exynos along with the RAM and eMMC on it. This allows me e.g. to choose the WiFi module I want. I also have access to most of the I/O pins of the Exynos4412 .

I'm not worried about the Exynos 4412 being EOL, I got mine, that's all I need for now. If I were to produce more units of the CoaxCopter I would have to reconsider that (along with other production aspects).

  Are you sure? yes | no

jarek319 wrote 04/21/2016 at 15:46 point

Looking forward to seeing how this turns out! I've been dreaming about a small flying robotic 'pet' to fly around and get better views of things for me, like traffic ahead or roof condition.

  Are you sure? yes | no

JoanTheSpark wrote 04/21/2016 at 06:41 point

Engineering question - how do you get power to the upper motor in a straight and efficient way?

What about redundancy in regards to a failure of sorts? Won't it start to spin when one fan fails?

What happens when the robot steers into something, is the structure stiff enough to not come into contact with the fan blades? Is it flexible enough to not break apart?

I think the hard part here will be the software side of things and getting the LIDAR working successfully. If I were you I would try to get that task tackled with 100% energy and take off-the-shelf components for everything else.. a hexa- or octocoper might not look as flashy as your design, but I bet you will have it flying and testing way sooner that your own design - if you're really into getting the robot part working.

Adapting the AI/software to a safer mechanic, that can bump into things and not hurt anyone should be the last step IMHO.

Good luck.

  Are you sure? yes | no

luca wrote 04/21/2016 at 12:22 point

Hi,

- I will get power (and other electrical signals, e.g. GPS antenna) to the "top tube" (as I call it) by having the wires go along one of the bottom arms then up on the duct and back towards the center on the top arm. I know this is quite a distance, but I will be using low current motors along with a relatively high voltage. The current shouldn't exceed 2amps during hover. I'm more worried about the antennas. I plan to place a GPS patch antenna in the top tube (direct sky view) and my 2.4GHZ and 433MHz dipole antennas along the side. I need to be careful because carbon fiber and EM waves do not play along nicely. All of that is black magic to me, I might just settle for a configuration that works.

- Regarding redundancy, if one motor fails, the second motor is powerful enough to keep it flying, but you're right, it will spin. I will take spinning over flipping over which is what a quad would do. I am not sure if I will be able to control the CoaxCopter while it is spinning. Another option would be to have a third degree of freedom in my control surfaces, which would require another servo. Not sure I can/want to fit that in there. I will think about that though. In general, there is some sensing redundancy (some sensors can give estimates if others fail) but some critical failure cannot be recovered from. If the robot loses power, there's not much that can be done. If a control surface servo dies, the spring loaded mechanism I'm designing should bring the control surface back to a neutral position. The flight controller is completely independent from the Exynos, so if my "high-level" control crashes, the robot will not fall from the sky.

- The carbon fiber structure is very stiff along its main axes while being flexible in the other (because I'm using sheets). One big challenge is the prop duct. If the robot hits something, the duct could flex a bit and come to touch the blades inside. This is why I will be adding reinforcements (currently not shown on the renders). Breaking things is always a risk with CF but I will try to minimize risks. I plan to add foam rings / air bags along the top edge of the prop duct and the bottom edge of the control vanes duct.

- I'm interested in building my CoaxCopter from the ground up, and that involves dealing with the mechanical side of things as well. I'm not in a rush and enjoy all aspects of product development, so I will stick with my "do everything" approach. Now if I had a team that would be different, but currently I'm the only one on this ;). In addition, my lidar idea only works well on this design, because it can rotate around the center axis, look up and down, and spins because of the airflow (no additional motor). I could not do that on a quad/hexacopter...

Thanks for the comment!

  Are you sure? yes | no

Comedicles wrote 04/21/2016 at 06:08 point

Exynos 4412 was EOL'd by Samsung quite a while ago. Try a 4418 like this one  https://andahammer.com/index.php?route=product/category&path=61_77  or the M2. Debian Jessie is running on them. Unmentioned advantage - Samsung 6818 is an 8 core A53 upgrade path on these.

  Are you sure? yes | no

luca wrote 04/21/2016 at 11:28 point

Yeah I know that the Exynos4412 has been EOL'd, but there are still plenty available. I chose that board because it has all I need and it's very compact. I don't need a board with connectors taking up space (and weight!)

If this project succeeds, I might upgrade different components and the CPU board is no exception. 

I worry more about the lidarlite being potentially EOL'd by Garmin. In that case I might go for a lightware laser rangefinder, but that's a bigger investment...


Thanks for your comment!

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates