EVPR: Electric Variable Pitch Rotor

An electrically actuated variable pitch rotor with a wireless interface

Similar projects worth following
The Electric Variable Pitch Rotor (EVPR) is a variable pitch rotor that is electrically actuated. The design is self contained, eliminating the need for heavy mechanical linkages or costly slip rings. An on-board controller, the ESP32, receives commands via wireless data and controls the blade pitch via servos placed inside of the rotor hub.

The primary power source for the on-board electronics will be a 3-phase axial flux generator, rectified to DC. The frequency of the alternator will be used to measure the rotor speed (RPM).

The EVPR could enable new multi-rotor vehicle designs, enhance current multi-rotor designs and potentially even be applied to small conventional aircraft.

The design files are open-source under the GPLv3 License.


Multi-rotor vehicles are opening up new possibilities everyday. While much of what's promised regarding agriculture, shipping, flying cars, etc. is years, or even decades away, if just some of their capabilities can be achieved, the world will be a different place. Variable pitch rotors can make the promises of multi-rotors come to fruition.

Fixed pitch rotors are typically optimized for a single condition, namely hovering. This means that for other conditions, the design is less than optimal. Variable pitch rotors change the pitch of the blades as required and provide better overall efficiency.

Variable Pitch Examples

Most multi-rotor vehicles use fixed pitch rotors, but there are a few exceptions. The Stingray 500 and the MIT ACL Variable Pitch Quadrotor are two such examples. The maneuvering capabilities of these two vehicles are simply amazing.

EVPR: Electric Variable Pitch Rotor

The EVPR is a self contained mechanism. Servos inside the hub are used to actuate the blade pitch. Power for the servos is provided by an axial flux generator built into the hub. Control is provided via wireless signals. Once completed, the project will be demonstrated on #Goliath - A Gas Powered Quadcopter.


Unlike traditional variable pitch rotors, the blade actuation hardware is self-contained inside the rotor hub. Each blade is mounted to a shaft, held in place by two pillow-blocks. The shaft is actuated using a geared servo.

Below is the gear drive in action.

The servos and gear ratio should be application specific. For #Goliath - A Gas Powered Quadcopter, the required torque and a variety of servos are shown in the figure below.

The gear ratio chosen was 5:3 and the servo chosen was the Hitec HS-5685MH.


The heart of the EVPR will be the ESP32. The chip will receive the data signal wirelessly from the flight controller and be used to command the servos via pulse with modulation (PWM) signals.

A simple test was conducted to ensure that data could be transmitted to the spinning rotor. The test was successful and the same wireless system should work for controlling servos for a variable-pitch rotor.

Power Source

Primary power for the on-board electronics will be provided via an axial flux generator with battery for startup and backup power.

The axial flux generator will have permanent magnetsfixed to the vehicle frame. and the coils will be built into the rotor hub and provide 3-phase alternating current. The current will be rectified to provide a DC power source for the on-board electronics and servos. An example of an axial flux generator is shown in the below video. The axial flux generator for the EVPR will be based off of that design.

Power Required

The power required will be dependent of the blade torque requirements for a specific vehicle. A simple power budget is shown below for the Goliath quadcopter as an example.

Item mA Voltage Count Watts
Servos 2700 7.4 2 38.5
ESP32 260 3.3 1 0.9

Total 39.3

The axial flux generator example shown in the video was outputting 45W at about 2000 RPM. For Goliath, the EVPR rotors will be operated nominally between 3000 and 4000 RPM, so the design will need to be scaled down to keep too much power from being generated.

The total power required will be about 160W. Since the gas engine is capable of providing 22kW (30 Hp). So the percentage of power used for the rotors would be 0.7%. Even if the power budget doubles, it still only be 2% of the total power available.

  • 1 × SparkFun ESP32 Thing Dev Board
  • 1 × EVPR Breakout Board Custom board (see instructions)
  • 2 × Hub Plates 6061-T6 0.125" Plate (CNC cut to shape, see instructions)
  • 2 × HiTec Servos HS-5685MH
  • 30 × Socket Head Screws Black Oxide 6-32 3/8" long (91251A146)

View all 17 components

  • Firmware Progress

    Peter McCloud2 days ago 0 comments

    Solid progress is being made on the firmware, particularly for the master node that connects to the flight controller. As the firmware is being developed, it's tested periodically on an ESP32 connected to the Pixhawk 2.1 (shown below).

    ESP32 is connected via on of the UARTS to the TELEM2 port on the Pixhawk. The Pixhawk sends out messages via the mavlink format on the TELEM2 port. The data is then parsed using the mavlink c libraries. The firmware is finally correctly parsing the mavlink messages, so the next step is the pass the relevant messages onto the other rotors.

    The ESP32 is also running a webserver via Mongoose to provide a status page. Example shown below:

    Time since start: 28.942919 secs
    Connected stations: 1
    Station 0 MAC: AC:7B:A1:DE:DB:4F
    Connected to Flight Controller
    System ID: 1

    Most of the major pieces for the firmware are in place, it's just a matter of tying together all the pieces now. Once it's done, then the next step will be to test a single EVPR on the vehicle and test the ability to change pitch.

  • Building Progress, Working on Firmware

    Peter McCloud09/04/2017 at 18:57 0 comments

    Over the last few weeks, the hardware for three more rotors has begun to take shape. Below are some of the parts coming together. 

    Clockwise from upper left are three clockwise blades (one completed, two almost complete), the cores for all of the counter-clockwise blades, rotor plates for three more rotors, including one with servo mounted, and the latest power module.

    The goal is to have a second clockwise rotor ready for testing by the end of the week. The other rotors will be completed in the next few weeks.

    The power module has been revised and a diagram was made to show the wiring.

    Progress is moving forward on the firmware as well. The data transfer from the master node to the slave nodes (rotors) is working using UDP. Work is now focused on transferring the data from the flight controller to the master node. The initial concept was to use I2C, but it appears that the code for the ESP32 to act as a slave I2C device hasn't been implemented. CAN was my next choice, but the ESP-IDF doesn't have a driver. There is another Hackaday project #ESP32 CAN Driver that looks promising, but between that and having to write a custom driver for the PX4 Firmware, it's proably too much work for the time left. The Pixhawk2 has a wierd note about SPI not being recommended, so that was out.

    So that leaves using UART for now. This should be relatively straight forward since 1) There's already a PX4 driver for sending PWM signals through the UART port and 2) The UART is fully implemented in the ESP-IDF and there are examples available. In the long term I hope to have multiple protocols to give the user multiple options.

    So if all goes well, the firmware should come together in the next two weeks and then the control scheme with the Pixhawk in the loop can start being tested!

  • Still holding together, getting ready to make more rotors

    Peter McCloud08/20/2017 at 22:49 0 comments

    Updated design

    After the first successful (success == not flying apart) rotor test last week, the design was tweaked to change the orientation of the servos so that the centrifugal force held the internal gears in place instead of tearing them out. The change required moving the axle gear, and a new set of hub plates were cut  with the gear pockets moved. Below is a shot of the reassembled hub with the reversed servo orientation.

    Rotor weight

    The rebuild of the rotor allowed the opportunity to weigh the EVPR by itself (versus attached to the hub). The complete assembly weighs 2.7 lbs (note: in the future I still need to add the alternator, but the batteries give about 10 mins of run time right now). The fixed pitch rotors weighed 1.25 lbs, so adding variable pitch only adds. 1.45 lbs, better than I'd anticipated (The 7075 aluminum axles reduced the weight considerably). For a full set of 4 rotors the total increase in weight will only be 5.8 lbs.

    In contrast, the grid fins control concept is anticipated to weigh 6 lbs a piece (not including actuators and mounting hardware. A set of 4 would add 24 lbs of weight. If the variable pitch rotors perform as hoped, that will mean upwards to 18 lbs of weight savings.

    More Testing

    With the rotor rebuilt, two more tests were conducted. Both tests were 60 seconds long and the rotor held together. Both blades have survived 3 start-up/shut-down cycles and 3 minutes of run time. It's looking like the mechanical bugs have mostly been worked out.

    More Rotors

    With the hardware performing well, the prize money from the Wings, Wheels and Walkers round was invested in buying enough parts to build a full set of variable pitch rotors. The majority of the hardware is from and the parts arrived on Friday.

    I've been really happy with their hardware so far and if you send them pictures of your project, you can get a discount. It's also pretty cool to get a handwritten note with your order!

     Forward Work

    More testing needs to be done on the first rotor to build up the time and cycles on the hardware to make sure things will hold up in the long term. The other big priority is to to mature the firmware and demonstrate controlling the servos.

    As time allows, the buildup of the second rotor will continue. The hub plates have already been cut and the rotor blades are almost complete. Work on the build instructions have started now that the hardware has reached a somewhat stable state.

  • Design Iterations

    Peter McCloud08/12/2017 at 17:21 0 comments

    Since the last project log, the design has undergone a few iterations. The main problem had been keeping the rotor blades attached to the hub. One failure mode was that the blade came detached from the axle and the second was that the axle detached from the hub.

    The axle was fixed by added a second retaining ring so that both pillow blocks keep the axle from flying out. It also became apparent that the pillow block bearings were not adequate to take the axially loads. A thrust bearing was added at each pillow block to improve the design.

    Better bonding techniques were used to attach the blades to the axles. Another test was conducted (see the video later in the log) and for the first time everything survived past the engine starting up. Then after running for about 90 seconds the blades detached from the axles.

    It was decided that only using epoxy to keep the blades attached wasn't going to work and that rivets should be added. However the 1045 carbon steel axles are difficult to machine (at least with the equipment I have) due to their hardness. After some research it was decided to switch the steel axles out for 7075 aluminum which has nearly the same tensile strength, but is easier to machine and much lighter.

    The latest iteration of the axle is shown above. A knurled surface was added to further improve the adhesive bonding to the axle. After the axle was placed into the blade, holes were drilled though the assembly and six solid aluminum rivets were added.

    The new axles and rivets did the trick. For the first time the whole assembly survived startup, running for about 60 seconds and engine shutdown.

    A few other issues have popped up as well. The screws holding the servo in place allowed some movement of the servo which wasn't desired. Torquing the screws down further wasn't an option with the plastic flanges. The solution was to use precision shoulder screws to mount the servos.

    The screws are shown in the image above next to the red and black wires. They work great, but at $2.24 a piece they are pricey.

    Losing rotor blades caused vibrations that damaged the quadcopter frame. Three of the gussets on the rotor arm were cracked. Below is a shot of one of the worst cracks.

    Part of the problem was the concave corner that I had cut too sharply. The gussets were replaced, but a large radius was added to the corner to prevent a crack from starting.

    I'd love to say that the hardware design is complete, but one last issue popped up during the last test. Inspecting the hardware after the test, one of the servo was not holding position and would make strange noises when the blade was rotated out of position. Taking about the servo it was found that one of the gears which just has a friction fit had come loose.

    The culprit gear is the brass gear in the middle of the assembly above. Why did it come loose? While the gear case holds the gear in place from top, the centrifugal forces are likely pulling the gear out of the friction fit. To keep this from happening the servo should have the top pointing inwards instead of outwards so that the centrifugal force helps the gears stay in place instead of pulling them apart. 

    Looking at the design it should be straight forward to make the changes. It'll have the added benefit off keeping the main servo gear attached to the spline as well. The only downside will that it will more difficult to adjust the blade pitch with the gears inside of the hub, but it'll still be doable.

  • Prototype Repair, Working Power Supply

    Peter McCloud07/24/2017 at 01:26 0 comments

    While it's impossible to know the exact sequence of failures during the previous test, it's clear that losing power was a contributing factor. Using small gauge solid wires with soldered connections and standard servo connectors was a poor choice considering the high vibration environments.

    The power supply board was re-worked afterwards to come up with a better design. The connectors for the servos and the batteries are all screw terminals now and all of the solid core wires have been eliminated. The image below shows the power supply board with the screw terminals.

    Another test was conducted, this time with just the electronics powered and the blades and axle removed (The replacement parts aren't ready quite yet, but I wouldn't have put them on for this test anyways). 

    The test was a success. The start-up and shut-down sequence was conducted a total of four times and the electronics never lost power. I should have done a test similar to test before attaching the blades in the first place, which would have eliminated some of the re-work I'm having to do now.

    The new blades are nearly complete and a spare set is in-work to ensure that if there is another failure, the project won't get slowed down. Below is the two epoxied blades and the cores for two more space blades.

    One other design change in the works is the addition of thrust bearings. The hardware for that will get here tomorrow and then the blades will be ready to be installed with the thrust bearings. If everything goes smoothly, the full prototype will be assembled again and ready for testing by the end of the week.

  • First Full Prototype Tests, Prototype Broken

    Peter McCloud07/16/2017 at 16:27 0 comments

    The first full prototype had been assembled and some basic firmware was written to do some simply tests. The first was a self test where the on-board ESP32 command the servos to sweep through the servo travel range. Below is the video of the self-test.

    Note that the servos have way more range than is actually required. More gearing could be added, but that would mean a loss in response time. It was decided to keep the current travel range, but limit the range in software.

    For the next test, the firmware was setup simply hold the blades at a specified angle of attack. The blade angle was set to a near zero lift condition (Due to the blade twist, the isn't really a true zero lift condition). The position hold functionality was tested by attempting to twist the blades by hand and the blades maintained their specified position. With the firmware functionality confirmed, the vehicle was turned on to test out the full prototype similar to the hub spin up test done a few weeks ago.

    The test didn't go well. The vehicle had an unusually hard start-up, causing the vehicle to flex more than usual. Shortly afterwards the electronics on the rotor lost power. Afterwards, it's hard to determine exactly what happened next. Even at 60 fps, the blades are spinning too fast to see what's going on. However, without power, the servos can't maintain the blades. It's possible that they rotated into the belts and were subsequently ripped off.

    Here's a photo of the rotor after the test. One of the blades was simply ripped from the axle. It appears that the bonding between the shaft and the blade wasn't that great in places. The black wire is the battery wire that became disconnected during the test.

    The other blade (the one that bounces page into the frame in the video) took the axle with it. To do this, one of the retaining rings and the steel gear had to be stripped off (I still haven't found either of those pieces in the shop). It appears that when the blade impacted the wall, the axle was kept going and popped out through the blade.

    Repairs are in-work and shouldn't take too long. More robust power connections are needed. I'll start with slightly bigger wires and screw-down style terminal blocks. Mechanical limit stops will also be added to prevent the blades from rotating too far. It'd probably also make sense to add some additional clearance between the rotor and the belts.

    UPDATE (7/16/17 10PM PDT)

    I finally found the missing gear today! The gear was embedded in the foam enclosure around the CNC router. The 2" thick foam was the best possible material for the gear to impact and the steel gear is completely unharmed.

  • Blade Construction

    Peter McCloud07/11/2017 at 01:20 0 comments

    The previous project log showed the assembled prototype complete with rotor blades. However, the construction of the blades for EVPR hadn't been documented. The rotor blades use a similar process as what's documented in #Inexpensive Composite Propellers/Rotors, but with a few tweaks.The blades are built using a composite layup process. The image above shows all of the materials that go into making the rotor blade. The process starts with the pink object, which is the foam core. The core is cut into the shape of the rotor blade using a CNC router. The core as shown above is after the supports have been trimmed off.

    To start, epoxy is mixed and a thin layer is applied to the core. Next, the two strips of uni-directional carbon fiber tape (The two black strips on the far right) are applied over the quarter chord on the top and bottom of the blade. Next, 3 layers of fiberglass (white woven fabric in the image) are applied individually and wetted out with epoxy as they are applied. The fiberglass is then covered with Aeroveil (gauze looking material below the fiberglass fabric in the image) which gives the composite a smooth finish when complete.

    The next step is to wrap the blade with peel ply (green plastic) which keeps the bagging material from sticking to the epoxy and then with breather cloth (white felt) and then everything is placed it n the vacuum bag (yellowish plastic).

    When vacuum is applied to the bag, the air is removed and the excess resin is sucked through tiny holes in the peel ply and into the breather cloth. This makes the part as light as possible. Below is the part after the epoxy has cured and the item has been removed from the vacuum bag.

    Finally the ends are trimmed off, and the axle is attached. This is done by drilling a hole into the root side and using epoxy to adhere the axle to the blade. With the axle attached, the blades can then be installed onto the hub.

  • Blades and electronics added to the first prototype

    Peter McCloud07/05/2017 at 03:56 0 comments

    The rotor blades and the electronics are now complete and have been added to the hub.

    For now, the prototype will just be operated on battery power. Once the rotor has been tested, and shown to work, then the primary power source will be added.

    Two 3.7V LiPo batteries provide the power (and will be the backup source for the final version). The batteries are tied together to provide the 7.4V needed to drive the servos. A voltage regulator is mounted on one half of the hub and provides power for the ESP32 dev board on the other side of the hub.

    Small proto-board with battery connections and voltage regulator.

    ESP32 dev board.
    The hardware is now ready to test all of the capabilities, except for the primary power source. The next step is to develop the Firmware so that more complex testing can begin

  • Prototype Hub Spin Up Test

    Peter McCloud06/21/2017 at 04:46 0 comments

    The prototype hub was assembled with just the mechanical components. (No batteries, controller or blades). It was decided that it'd be good to do a quick test to ensure that the assembly would hold together before proceeding further with the rest of the project. Therefore the hub was mounted onto the vehicle and a quick spin up test was performed.

    The hub held together, so the next step will be adding the batteries and the controller board. I've also started making the first set of rotor blades, which I'll document in a future build log.

  • Batteries selected

    Peter McCloud06/09/2017 at 02:31 0 comments

    While the primary power source for the rotor will eventually be an axial flux generator, batteries will be present to provide startup power and serve as a backup. The latest servos, HS-5685MH, run at 7.4 V max and draw a maximum current of 2700 mA.

    Packaging was the primary driver for the battery selection. It was desired to have batteries that would fit inside of the hub. The battery chosen was the UBP053450/PCM. This battery will tuck into the gap between the servo and the upper plate and the main mounting bolts. The batteries are highlighted in blue in the figure below.

    Each of the batteries have 900 mAh, so the total capacity is 1800 mAh. This is sufficient to provide 10 min of operation time at the maximum stall current for both servos, and should be adequate for controlling the vehicle if the axial flux generators fail.

    The batteries should arrive next week. In the meantime a design for the battery clip needs to be created. After that, the ESP-32 dev board can be mounted inside the hub and the electronics testing can begin in earnest.

View all 19 project logs

Enjoy this project?



Mal'oo wrote 07/18/2017 at 18:35 point

When thinking about flight critical systems in aircraft, they tend to be set up in a way so that they have failsafes. Electric pitch adjustment, for example, use long screws, since they hold position without power to the motor. Fixed wing aircraft seem to use oil pressure to actuate the prop pitch, and in the event of loss of oil pressure (engine failure) the prop's failsafe position is full feathered: Minimal drag to aid in safely landing.

So, there's a need to engineer for failure here. Strong return springs might be out of the question, as it's additional force for the servo to overcome, but it's the best fail-safe option, as failure will, ideally, revert back to stable flight. 

Another possibility might be worm gears, as they hold position without any power input, similarly to the screws mentioned above. They're in the same ballpark for speed, even: A tiny bit of research puts servo gear reductions in the 100-600 to 1 range, with a tiny, low torque motor running at 10k RPM or so. Worm gear reduction is dependent on the number of teeth on the gear you're driving. At a guess, leaving the gear on your props unchanged would result in a 50:1 reduction.

  Are you sure? yes | no

Peter McCloud wrote 07/23/2017 at 18:23 point

Mal'oo, thanks for the feedback. I completely agree, flight critical systems need to have fail-safes. Since this project is in the early stage, there is a balance between adding fail-safes and just trying to get something to work. Honestly, I had considered the failure scenario that broke the blades before it happened, but I felt that the risk was low enough to move forward.

I like the idea of using worm gears to hold the blade positions in the case of a power failure. I did a quick search, but I don't see any off-the-shelf hardware that'd be a quick replacement. I'll be sure to keep it in mind for future iterations.

  Are you sure? yes | no

Gravis wrote 07/05/2017 at 13:10 point

I like your concept but I have some tips to help.

1) Gear both rotors so that they can never go out of sync.

2) When in flight, it will need significantly more torque than a typical servo can provide.  Changing the gear ratios in a continuous servo might work.

  Are you sure? yes | no

Peter McCloud wrote 07/05/2017 at 14:55 point

Thanks for the feedback.

1) Not locking the shafts together actually leaves open some intriguing design possibilities, such as the ability to act as a virtual swash plate.

2) The airfoils were chosen for their low pitching moment and the servos have more than sufficient torque for the current application. This is covered in one of the early logs.

  Are you sure? yes | no

vsohal2 wrote 07/05/2017 at 05:37 point

You might look at the magnetic awash-late concept too:

What sort of power draw do you think the servos on your design will have? It seems that you will also have losses from wireless power transmission as well as holding torque for the servo. You might dramatically boost efficiency if you added some sort of mechanical locking mechanism to allow holding torque to be zero when you don't need to change pitch.

  Are you sure? yes | no

Peter McCloud wrote 07/05/2017 at 14:49 point

Thanks for the swash plate info. That's a whole nother level beyond what I'm trying to do, but I'll be sure to keep it in mind in the future.

The two servos draw about 40W at stall. You're right, a locking mechanism or spring mechanism could reduce the power consumption. Once I've demonstrated the concept works, then I can l look at improving the efficiency.

  Are you sure? yes | no

Yusuf Khan wrote 05/08/2017 at 20:22 point

Hi. This is a fascinating project, and congrats on becoming a finalist.

I was curious about 2 things. Why not slip rings for transferring power and control signals?
Also, I see the torque required has been calculated, but what about the servo's angular velocity and acceleration . What's the formula for rotor rotational speed to servo pitch speed?

I may be using the wrong lingo...

  Are you sure? yes | no

Peter McCloud wrote 05/08/2017 at 20:48 point

Yusef, thanks for the compliments.

I haven't been able to find any off the shelf slip rings that can handle 3000-4000 rpm. There are some aerospace grade models that can be custom ordered, but they cost thousands of USD.

I haven't documented the servo details yet as I'm still working that out. Ideally I want 20 deg of blade pitch rotation for the full servo travel. The servos I'm using right now will travel the full range in 0.9s

  Are you sure? yes | no

EngineerAllen wrote 05/01/2017 at 09:49 point

im going to be using variable pitch props on a future version of my asymmetric uav

having large rotors around CoM to generate 100% of vertical thrust eliminates the issue my current design has with asymmetric propulsion on pitch axis control.

since smaller variable pitch rotors can then control pitch axis without surrounding CoM.

it also maximises efficiency 

so im interested to see how yours works out

especially with the control system side

  Are you sure? yes | no

Peter McCloud wrote 05/01/2017 at 14:59 point

Cool, glad to hear others are interested in it. I'm trying to keep in mind scalability as the design proceeds. How big are your smaller rotors?

  Are you sure? yes | no

EngineerAllen wrote 05/04/2017 at 08:53 point


  Are you sure? yes | no

Daren Schwenke wrote 04/03/2017 at 19:12 point

This idea scares me.  You are introducing multiple single points of failure into a system where you already have no room for any.  I would look at using near field communication instead if you insist on going wireless for your control surfaces.  There is just too much traffic in the 2.4 Ghz band to make any system 100% reliable.  First time this powers up at a Makerfaire, you'll soon learn the entire band becomes a really small place.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 04/03/2017 at 20:26 point

My head spun a few times when I read that too... People just put 2.4GHz gizmos everywhere !

If you inject power through HF fields, ike contactless smartcards do, you can also modulate them to transmit data.

  Are you sure? yes | no

Daren Schwenke wrote 04/03/2017 at 22:04 point

In this case, he could just modulate it directly with the inverse of the PWM signal the servo requires anyway.  A couple of analog bits would do it then.

  Are you sure? yes | no

Peter McCloud wrote 04/03/2017 at 20:59 point

Daren, I'm not sure where "multiple" single points of failure are being added. I understand that the wireless data adds one extra single point failure. If the 2.4 GHz band is being relied upon to provide primary control remotely, via the transmitter, it doesn't seem too much of a stretch to use it for intra-vehicle communication.

I went with Wifi to start with because it's cheap and easy to implement as it's already part of the ESP32. I think your right that the NFC might be a better choice, though it would require 4 TX/RX pairs. The nice thing is that once the hardware and firmware are in place, it should be easy to implement other wireless technologies. Having two different ones would probably be best for redudency.

  Are you sure? yes | no

Daren Schwenke wrote 04/03/2017 at 21:39 point

Each rotor will rely on it's own connection.  4 rotors.  4 single points of failure. 

The law enforcement way of bringing down drones is to flood them with wifi/false GPS signals.  In the case of your drone, that would also result in compromising flight stability and a pretty much instant uncontrolled plummet to the ground.

  Are you sure? yes | no

daigakusei wrote 03/21/2017 at 11:10 point

Hi Peter,

is the power generator not a little bit over engeniering. The generation of electric power in the hub reduce the rotation for the rotor. Every change of magnetic field in the coils produce an reverse force on the magnet. 

Why not an Qi power induction like the loader for mobilephones. 

The sender coil axial around the axis and receiver coild in hub parallel.

The AC of the system whouldn't interferenc with the rotation of the hub.

P.S.: Excuse my bad english its not my native language.

  Are you sure? yes | no

Peter McCloud wrote 03/21/2017 at 18:53 point

I had steered away from wireless power induction because I thought it'd be less efficient. Looking at Qi after you mentioned it, that may not be the case. I'll have to look into that more.

One advantage to a generator based system is that it could potentially be more fault tolerant. If the vehicle suffers a power loss the rotor could still operate and a backup flight control system could attempt to autorotate by feathering the rotors.

  Are you sure? yes | no

Benjamin Hab wrote 04/08/2017 at 20:59 point

When talking about wireless power: I am not entirely sure if this would work, but how about tying the pwm line of the servos to V+ and using a pwm signal on the Qi? At least for analog servos that sounds like a feasible idea to me. 
Anyway, is there any particular reason not to take the rotor head of a big model helicopter? It is at least proven to work and would greatly enhance your yaw dynamics (I havent understood by now, how they are supposed to work with variable pitch anyway?)...
Best wishes,

P.S.: Your projects are really impressing!

  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