Close
0%
0%

EVPR: Electric Variable Pitch Rotor

An electrically actuated variable pitch rotor with a wireless interface

peter-mccloudPeter McCloud
Following
Liked Like project

Just one more thing

To make the experience fit your profile, pick a username and tell us what interests you.

Pick an awesome username
hackaday.io/
Your profile's URL: hackaday.io/username. Max 25 alphanumeric characters.
Pick a few interests
Projects that share your interests
People that share your interests

We found and based on your interests.

Choose more interests.

OK, I'm done! Skip
Public Chat
Similar projects worth following
13.8k views
22 comments
90 followers
View Gallery
Public Chat
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 the rotor hub. Power is provided via batteries, also contained inside the rotor.

The EVPR could enable new multi-rotor vehicle designs and enhance current multi-rotor designs. The design could potentially be used to create more efficient conventional light aircraft and hovercraft or to make inexpensive rotary subwoofers.

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

THE LATEST VERSION OF THIS PROJECT IS AT

#Electric Variable Pitch Rotor Mk. II 
Background

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 main idea behind the EVPR is to put all of the components inside the rotor hub, eliminating the need for swash plates or slip rings, which can cost upwards of a thousand dollars. Servos inside the hub are used to actuate the blade pitch and power for the servos is provided by batteries. Control of the servos is provided via wireless signals. The first application of the EVPR will be on #Goliath - A Gas Powered Quadcopter.

EVPR Hub
EVPR hub containing the microcontroller, servos and batteries

Currently, the nominal battery life is 30 mins. In the the future, an axial flux generator will built into the hub and the batteries will act as a backup. In the future, the design can also be used to create  variable pitch propellers for small aircraft that can simply be bolted on and require minimal modifications to the aircraft. Hovercraft could also be fitted with a with a variable pitch fan that not only increases efficiency, but could also provided a braking thrust to slow down. The EVPR design could even be used to create cheaper low frequency subwoofers!

In an effort to make a design that was more easily manufactured, off-the-shelf components are used when available. The design utilizes servo mounts, pillow blocks and servo gears available from Servo City.

Mechanical

Each blade is mounted to a shaft, held in place by two pillow-blocks which carry the radial loads on the shaft. The shaft is actuated using a geared servo. To counteract the centrifugal force pulling the blades outwards, two thrust bearings are utilized and heavy-duty retaining rings hold the shaft in place.

Servo and gears for actuating the rotor blades
Servo and gears for actuating the rotor blades

Gear drive in action

The EVPR design uses standard size servos. The specific application will drive the servo and gear ratio selection. For #Goliath - A Gas Powered Quadcopter, the required torque and a variety of servos considered are shown in the figure below.

Required torque for the Goliath quadcopter and the servos considered

Almost all of the servos considered have sufficient torque with a gear ratio of 5:3. However, required torque isn't the only consideration. Early testing with the Hitec HS-5685MH found that while the servo had sufficient torque, the gears would strip. The brass gears were unable to handle the the shock and vibration environments and so a steel or titanium gear servo was required. The HSB-9475SH with steel gears was then selected since it's one of the cheapest servos with the required type of gear.

Electronics

The heart of the EVPR is the ESP32 micro-controller. Currently a Sparkfun ESP32 Dev Board is used. The electronics are placed as close to the center of the hub as possible to lower the centrifugal forces experienced.

For now, a minimum of two ESP32s are required for the EVPR. The first is connected to the flight controller via a UART connection and acts as a master node. It's purpose is to act as the access point and broadcast the servo commands from the flight controller....

Read more »

View all details

rotor_assembly.stp

CAD file of the EVPR assembly (minus electronics)

stp - 7.91 MB - 10/19/2017 at 15:24

Download

  • 1 × Adafruit Huzzah32 Dev Board
  • 1 × EVPR Breakout Board Custom board (see instructions)
  • 2 × Standard Size Servos Torque required based on specific application
  • 30 × Socket Head Screws Black Oxide 6-32 3/8" long (91251A146)
  • 4 × 1/2" Bore Side Tapped Pillow Block SKU: 535138

View all 17 components

  • Closing Project, New Mk. II Rotors

    Peter McCloud • 01/14/2020 at 05:26 • 0 comments

    It's finally time to close up this particularly project and it's now been marked as completed. If you've been following, you might have seen the news about creating a newer, updated Mk. II version. With all of the major updates, it made sense start a new Hackaday project #Electric Variable Pitch Rotor Mk. II  and save the old Mk. I info here for future reference.

    Thank you to everyone who followed and supported this project. I'm particularly grateful for the prizes the project got during the 2017 Hackaday Prize (Wait, that was almost three years ago?!?). Please follow along at the new project if you're interested.

  • Four Rotors Completed and Mounted on Goliath!

    Peter McCloud • 06/08/2018 at 02:18 • 0 comments

    The full set of four variable pitch rotors is finally ready. Above is the video showing the control system working. The wireless data protocol appears to be working with no issues. There's still some remaining work to be done on the PX4 Firmware, but the rotors are ready to go for powered testing!

    Be sure to come out and see the vehicle at OMSI's Robot Weekend!

  • OMSI Robot Weekend June 16th and 17th

    Peter McCloud • 06/01/2018 at 20:05 • 0 comments

    In the Pacific Northwest and want to see the EVPR protoypes or #Goliath - A Gas Powered Quadcopter  in person? Come out to OMSI's Robot Weekend on June 16th and 17th. This will be the first time Goliath is displayed with all of the controls integrated into the vehicle. The last of the variable pitch rotors has been assembled and is ready to go on the vehicle.

    In order to demonstrate to event-goers how the EVPR works, a see-through prototype is being built. A potentionmeter will be added to allow attendees to manually adjust the pitch.

  • Testing With Two Prototypes Has Begun

    Peter McCloud • 04/04/2018 at 15:20 • 1 comment

    The first two rotors have been fully assembled, painted and now are mounted onto the vehicle. Below is a HD video in 4K showing the movement of the rotor blades during a pre-test checkout.

    Since the second prototype is brand new, the goal of the initial tests is simple to check that the new prototype will hold up to the environments. After conducting a short test, a longer 2 minute test was conducted at a moderate RPM and with the blades in a neutral position.

    Nothing fell apart, so it was considered a success. One lesson learned from the test is that leaving the rotor blades in a neutral position minimizes the tension on the belts, increasing vibrations and making the throttle much more sensitive. Something to consider for future testing. 

  • Firmware using ESPNOW seems to be working well

    Peter McCloud • 02/08/2018 at 06:30 • 0 comments

    Most of the recent work has focused on the Fiirmware,  particularly the protocol for communicating the servo positions between the master and the slaves. TCP was used for the prior iteration of the firmware, but led to less than satisfactory performance. Spurred on by @Jarrett's suggestion, I wrote a version of the firmware using the ESPNOW protocol. While it using wireless data, it doesn't require a WiFi network, but instead uses  IEEE 802.11 Action Vendor frames (as I don't follow this either, assume *magic*). The idea is that the ESPNOW protocol requires less overhead than sending UDP or TCP packets over a WiFI network that has to be established.

    So now the master node reads the servo positions from the flight contoller via UART and broadcasts the servo positions for all of the slave nodes over a single packet. Each slave node receives the packet and only uses the data for the servo it requires. This simplifies the work done on the master node, since using sockets over WiFi required a separate connection for each rotor.

    Testing thus far shows that the connections appear reliable. out of 9000 packets sent at a rate of 50 Hz, the slave node missed only three packets (0.03%). The servo movements are visibly improved from before, with none of the jerkiness. I've gone ahead and merged the updated firmware into the master branch.

    As always, there's more work to do. The slaves are setup to send out a heartbeat packet every second, and the master node is setup to receive them, but nothing is currently been done with the information. Eventually the idea is to have the master get a status confirmation of the rotors and sharing that information with the flight controller to prevent arming the vehicle with less than the required number of working rotors.  There are a few other error checking tidbits to add to make the system as safe and reliable as possible.

  • Two operating rotors

    Peter McCloud • 01/18/2018 at 06:00 • 2 comments

    There are now two operating EVPR prototypes. This week I finished assembling the parts for the second rotor. Both are using the new Adafruit Huzzah32 boards. 

    While both rotors respond to the controller inputs, there is an unacceptable delay in the responses and a jerkiness to the servo movements. The firmware uses TCP to send the servo positions from the master to the slave. I had chosen this method so that the connection status could be monitored. However, using TCP appears to be having side effects that I don't understand. More work is needed on the firmware.

  • New Adafruit Huzzah32 Boards are working!

    Peter McCloud • 12/06/2017 at 05:24 • 1 comment

    In the last few weeks, I found that the Sparkfun ESP32 Thing was not working well with the ESP-IDF due to the 26MHz crystal. In particular there was issues sending data packets between two of the boards. Therefore I ordered a batch of Adafruiet Huzzah32 that have 40 MHz crystals and they arrived a few days ago.

    The Adafruit board is slightly smaller than the previous Sparkfun board (0.9"x2.0" versus 1.0"x2.25"). Functionally there are almost identical. The Sparkfun board has an extra push button, but the Adafruit board is shielded. The battery connector on the Adafruit board is definatly more solid and has additional attachment points for strength.

    The first thing I did was to load the performance examples and runs some tests. Both the UDP and TCP tests worked as expected with the UDP throughput in the Mbits vs. the few Kbits I was getting with the Sparkfun board.

    Next I flashed the latest EVPR firmware onto the boards and swapped out the electronics in the EVPR prototype. There were no connection issues and the TCP data packets were sent correctly.

    The next step is to design and print new board holders since the Adafruit board is too small for the current ones. The pin layouts are different as well, so I'm going to need to find a different method of attachment. 

  • Issues with Sparkfun ESP32 Thing

    Peter McCloud • 11/25/2017 at 19:35 • 0 comments

    Over the past month, a lot of work has gone into testing out various communication methods between the master and slave nodes. Basic UDP, mulicast UDP and TCP have all been tried out, with each having various issues. Digging deeper I went back to some of the ESP-IDF examples that test performance and found that even for the basic examples, something is not right with the Sparkfun ESP32 Thing dev boards I'm using.

    Apparantly, the ESP32 Thing has a non-standard crystal frequency of 26 MHz, whereas the vast majority of the other ESP32 products have a 40MHz crystal frequency. The ESP-IDF seems to be tested against products with 40 MHz crystals and there appear to be a lot of bugs when the examples are run on the ESP32 Thing. Like getting very slow UDP speeds (0.4 Mbit vs 130 Mbit) and for TCP, the connection disconnects after a few seconds.

    I'm going to contact Sparkfun about getting some tech support about this, but I don't really have any expectations that it'll get resolved. In the meantime. I'm going to order a pair of Adafruit Huzzah32 boards and try those out.

  • UDP Unicast vs. Multicast

    Peter McCloud • 11/10/2017 at 05:21 • 0 comments

    With the basic EVPR hardware working, the firmware needs some work to support multiple rotors and add some redundancy. Right now only the single rotor is supported and if the rotor resets for whatever reason, both the master and slave need to be rebooted to re-establish the connection.

    Doing some research on what's available on the ESP32, it seemed like UDP Multicast might be the solution. A single data packet would be sent out to all of the rotors. Using the ESP-IDF example, it was straight forward to create a branch of the firmware to support multicast.

    The end result was less than satisfactory. Multiple devices were able to receive data and if a device got disconnected, it was able to pickup the data packets successfully. However, the latency was unacceptable. There was sometimes delays of one to two seconds using multicast. It'd probably be fine for other applications, but for trying to control a quadcopter, the delays are really unacceptable.

    Thank goodness for version control and branches. Now it's back to the unicast method to add the required support there.

  • Working Prototype!

    Peter McCloud • 10/29/2017 at 21:37 • 0 comments

    The prototype is finally working! The video above shows the prototype in action. Changes in the blade pitch correspond to changes in the thrust direction. The rivets were replace with AN470 1/8" diameter rivets (AN470-4). These rivets have 350 lbs of shear strength for a total of 2100 lbs of strength. The new blades have been tested 4 times now without the blades coming loose.

    One of change was made to the batteries. It turns out the old batteries didn't have sufficient current capacity and the micro-controller would brown out while the gas engine was started. The new batteries are a similar form factor and have a 20C rating (20x the battery capacity). The capacity is slight smaller now (650 mAh vs. 900 mAh), but no more brownout issues!

    More testing needs to be done on the physical hardware to ensure the design is adequate for flight testing. Additionally more work needs to be done to develop the firmware to add reliability. Once that's done the the other rotors can be completed and flight testing can begin!

View all 33 project logs

  • 1
    Prep/Design Work

    Rotors/propellers are designed for specific applications. The airfoils and blades need to be designed to work with the chosen engine/motor. One the rotor blades are defined, the required torque to actuate the blades can determined and the appropriate servos selected.

    The following instructions up until the rotor assembly can be done in any order. However, they are listed with the longer lead time items first for a more efficient build process.

  • 2
    Build the Rotor Blades

    In addition the the following instructions, the rotor build process is also documented in a video.

    • Cut the rotor core
    • Layup the fiberglass around the core
    • Machine the axle
    • Epoxy the axle into the rotor
    • Rivet the axle in place
  • 3
    Print the Battery and Board Holders

View all 11 instructions

Enjoy this project?

Share

Discussions

Phil wrote 12/29/2017 at 06:02 • point

Hi Peter McCloud,

Ever realized that there may well be a huge need for electrically adjustable pitch propellers in the new, so-called eVTOL industry that will emerge in the coming years? Cheers, Phil

  Are you sure? yes | no

Peter McCloud wrote 02/08/2018 at 19:59 • point

Hey Phil,

So sorry for the slow reply, I never got a notification on this. To answer your question, yes, absolutely! The idea behind this design is that it can be bolted onto another. Gas motor, electric motor, eVTOL, airplane, etc.

  Are you sure? yes | no

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: https://www.rcgroups.com/forums/showthread.php?969632-The-MAGNETIC-SWASHPLATE-4-Coil-Push-Pull-Concept-Experiment

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

6"

  Are you sure? yes | no

MasterOfNull 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

MasterOfNull 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

MasterOfNull 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,
Ben

P.S.: Your projects are really impressing!

  Are you sure? yes | no

Martin wrote 10/18/2017 at 08:38 • point

Regarding inductive power transfer (transformer) vs. generator: AFAIK the application is a "drone" powered by a gas engine. So you need a generator anyway. In such a system with a variable pitch rotor the rotor speed is fairly constant. So I think the generator in the hub is a very good solution. It does also not rely on high frequency electronics with stressed components, just some magnets and coils like in any old boring motorcycle generator.
These permanent magnet alternators are regulated with a phase angle control. Of course this does not give a very stable power, so this only works together with the battery.

In aviation the first priority is reliability. This goes that far, that engine have twin spark plugs per cylinder, just for redundancy and use (or used for very long time) old fashioned magneto ignition, so it does not depend on the battery and related systems.
The considerations regarding single-points-of-failure are very important, but in an unmanned system probably not that highest priority than in manned flight.

I would consider optical data transfer in the hub to eliminate the 2,4GHz vulnerabilities. If the hub is sufficiently shielded against external light this should be possible. Distribute some IR LEDs between the magnets and modulate them with the PWM or a data signal. In the middle of one of the generator coils a receiver (photo diode) is placed.

Of course inductive would also be possible, like in old fashioned VHS recorders. The transmitter coil positioned around all of the magnets and the receiver around the the outer circumference of the generator coils. In this way these two coils do not interact with the magnetic fields of the generator.

  Are you sure? yes | no

Similar Projects

A BIG Gas Powered Quadcopter
Project Owner Contributor

Goliath - A Gas Powered Quadcopter

peter-mccloudPeter McCloud

- A new take on a 9g Servo Biped Walker
Project Owner Contributor

Tension Biped - A new take on a 9g Servo Walker

hooptie-jHooptie J

This drone allows for the high-speed transport of covid-19 tests and vaccines to hard to reach areas and people without mobility.
Project Owner Contributor

Corona Virus Test/Vaccination transport Drone

fin-meadFin Mead

GPS Guided Parachute Recovery System - Making Radiosondes Reusable
Project Owner Contributor

R2Home

yohan-hadjiYohan Hadji

Does this project spark your interest?

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

Going up?

About Us Contact Hackaday.io Give Feedback Terms of Use Privacy Policy Hackaday API

© 2025 Hackaday

Yes, delete it Cancel

Report project as inappropriate

You are about to report the project "EVPR: Electric Variable Pitch Rotor", please tell us the reason.

Send message

Your application has been submitted.

Remove Member

Are you sure you want to remove yourself as a member for this project?

Project owner will be notified upon removal.