Propeller alignment for improved efficiency in a quad vtol

[Michail_Belov]

I made a relatively small, 6 kg Quad VTOL. The setup and initial test flights went very well until I did a first endurance flight. With 40 18650 cells (2.1 kg, and AUW of 5.5 kg) the plane managed to fly 90 km, with one VTOL takeoff and one VTOL landing, with battery remaining capacity of about 10 %.

This was much less than I expected, although I did not do a preliminary calculation, because I was more worried about the VTOL setup and transition.

I started checking out the numbers, and discovered the following:

At 65 km/h it flies on 250 W electrical power, and at 95 km/h on 500 W. That should be around 170 W mechanical power for 65 km/h

I estimated the extra losses for the VTOL part as follows:

Motor and motor mounts: 18 W mechanical = 25 W electrical (=10 % of the total power)

Props which are not aligned with the wind: 44 W mech = 60 W electrical (during test flight both front props were perpendicular to the wind, and I do not know about the rear ones…) (= 22 %, up to of the total power, on average, around 14 .. 15 %).

There is also the issue of the forward motor prop which is here SK3-3548 1050 kV with 11 x 7 prop.

To improve overall efficiency, I will change the motor to Sunnysky 3520 560 kV with something like 14 x 8 prop, expecting about 10 % of improvement.

I also printed 3D cowlings for the motors, and I hope to get about 6 % improvement on these. (they add about 70 grams weight, around 1.5 % of the total weight, but they should more than halve the power lost now on drag on these items.

[rollys]

Check out @Vince_Hogg Cruise efficiency on a 4+1

Good luck.

[Michail_Belov]

However, the most attractive point for obtaining efficiency gain are the VTOL propeller alignment.

My idea is to use LUA script (it comes at the end of this message) which would nudge the motors after transition until they are in correct position. The nudging part was rather simple and quite effective. On average, you need to nudge the motor 8 times for it to align. The program gives a short pulse of 1100 uS (about 10 % of power) for about 100 mS.

The nudging process can be done only in FBWA mode, only after FBWA mode was on for 12 seconds (in order not to nudge accidently during the transition), with a minimum ground speed of 55 km/h (just in case, no nudging in hover for some reason), and with a special button activated.

The nudging continues automatically until a signal from Pi Pico arrives stating that the prop is aligned or for a maximum 30 tries. The Pi Pico reads SOME ?! sensor and sends the information to FC using Serial communication.

So far so good, but initially I was thinking about using a small magnet placed either on the prop or on the motor. Reading it is very easy, I have modules which do it, and even a small magnet of 2 x 2 x 4 mm. activates the sensor at a distance of 3..4 mm. reliably.

There are round magnets with a diameter of 2 mm x 2 mm long which should activate the sensor from 2..3 mm distance, which is sufficient. The problem where and how to place them. One option are the propellers, where a hole can be made just near the TE and at about 25 mm. from the center on both blades. A 2 mm. hole where blade thickness is around 1.5 mm. should not affect significantly the mechanical resistance of the propeller. The width of the blade (it is a 13 x 6.5 APC thin electric) is about 20 mm and about 4.5 mm at the thickest point. So by drilling a hole near traling edge, the overall material thickness lost should be around 3..4 %.

That APC propeller is rated up to 11000 RPM, on average the hover RPM in my case are around 5500 RPM, and double thrust would result in around 8000 RPM, way below the 11.000 maximum RPM.

The 2 x 2 magnet weighs around 0.09 grams, and obviously one would place one on each side of the blade, but there is still the risk of slightly different weights, and especially of epoxy applied, which could result in vibrations.

I wanted an opinion about this idea…

LUA SCRIPT SNIPPET (Semi finished)

if not motor_number then
motor_number= {}
motor_status={}
motor_sensor={}
motor_delay={}
motor_number[0]=2
motor_number[1]=3
motor_number[2]=4
motor_number[3]=5
for i=0,3 do
motor_sensor[i]=0
motor_status[i]=0
motor_delay[i]=0
end

-- motor status: 0 - start, 1 - 29 attempts to align   ,  30 - aligned
-- motor sensor is the sensor code assigned to it

end

if port then
local n = port:available()

    if n > 0 then
        -- Read available bytes
        local str = port:readstring(255)
        local lastChar = string.sub(str, -1) -- we are interested only in the last = latest char
        local charValue = string.byte(lastChar)
        if  (charValue & 16)>0 then motor_sensor[0]=1 else motor_sensor[0]=0 end
        if  (charValue & 32)>0 then motor_sensor[1]=1 else motor_sensor[1]=0 end
        if  (charValue & 64)>0 then motor_sensor[2]=1 else motor_sensor[2]=0 end
        if (charValue & 128)>0 then motor_sensor[3]=1 else motor_sensor[3]=0 end
        gcs:send_text(5, lastChar)  
    end
end

– To do the alignment: Button must be activated, Flight Mode must be FBWA, Fligh Mode FBWA must have been for the last 12 seconds Ground speed must be above 55 km/h

– !!! DO NOT FORGET TO CHANGE spd>15 !!! and vehicle:get_mode()==5 and spd<15

if not FBWAcountdown then FBWAcountdown=0 end
if not vehicle:get_mode()==5 then
FBWAcountdown=0
else
FBWAcountdown=FBWAcountdown+1
end

if nudgebutton<1400 then
for i=0,3 do
motor_sensor[i]=0
motor_status[i]=0
motor_delay[i]=0
end

end

if nudgebutton>1600 and vehicle:get_mode()==5 and arming:is_armed() and FBWAcountdown>120 then
for i=0,3 do
if motor_status[i]<30 and motor_delay[i]<1 then – not all attempts were used up and no active wait delay is going on
motor_status[i]=motor_status[i]+1 – increase attempt number

	SRV_Channels:set_output_pwm_chan_timeout(motor_number[i], 1100, 100) -- move motor
        motor_delay[i]=10  -- 10 is 1 second!  -- set delay for evaluating
end
    motor_delay[i]=motor_delay[i]-1
    if  motor_delay[i]==0 then
        if motor_sensor[i]==1 then motor_status[i]=30 end            
    end
  end

end

[Michail_Belov]

The other option is to use the TCRT5000 visual sensor (a pair of IR LED and a phototransistor), and I am going to try that route first, although the programming and the setup is slightly more complicated due to variable light conditions (sun light / cloudy).

The idea is the following: glue two white vertical stripes on each motor (V3115 from T-Motor).

The sensor will be in a “tunnel” of 3D printed cowling, so direct sunlight will be excluded.

The sensors will be just the sensor module, not the complete board with digital output which most probably will have issues with variable light condition.

The measurement would use the following algorythm:

			Lua sends message START SPINNING MOTOR X through Serial to Pi Pico
			Lua starts motor with PWM of 1100 uS and timeout of 100..120 mS (Randomly set to prevent same positioning error which seemed to happen from time to time)
			Pi Pico receives START SPINNING MOTOR X
			Pi Pico waits 10 mS (At that point motor must be already running for about 10 mS)
			Pi Pico starts sampling ADC during next 80 mS, taking note of MIN, MAX, and average value, the last measurement would also be with motor running. The idea behind this is getting an averaged value of some 100 readins, and the result may vary greatly depending on sunlight/cloudy condition, against which we will compare the stopped motor value
			Pi Pico waits 40 mS (At this moment, the motor must be stopped already)
			Pi Pico samples ADC. If it is above average, prop is aligned, below or around average, prop is not aligned, Pico sends a message back to FC, saying Motor X is Aligned or Not Aligned
			Lua receives the message, if Motor X is aligned, than done, if not, Lua repeats the process up to 30 times

[Vince_Hogg]

Hi Michael.

Checkout my prop alignment system just using modified AM32 firmware.

I’m now getting about 1.9 Wh/Km.

[Michail_Belov]

Hi, I have seen your idea. There are a few potential issues about it… First, it uses AM32, so far I have been using 8 bit ESCs without any issues (with bluejay), so that is a limiting factor. I would also be quite cautious to upload something which potentially can bring down the plane. Finally, from what I got, there is a ring with ratchets, I assume it is 3D printed. That one worries me most. First, I assume you did not have any balance issues (vibrations) with that ring? Also, not sure if PETG is enough to withstand motor temperature. With the current setup I have, the motor temperature seems to be below 60.

I think that if you had good results with putting a 3D printed ring between the prop and the motor, I would just print a similar ring with space for magnet and then use the original idea of reading the position using hall sensor.

[Michail_Belov]

I have seen your other video, where you test the system on bench, but I still do not understand where the notches are, on the 3D printed ring, or not?

[Michail_Belov]

Your ring also covers the vent holes, does it cause temperature increase? I have been looking at my motors, and I think I would have a problem installing such ring…There is no space below the prop, and putting a ring under the prop is not feasable because shaft is too short.

[Michail_Belov]

I printed a small ring with PETG with walls 4 x 4 mm, I press-fitted it, and ran it at full power, the log showed just shy of 20.000 RPM. In flight, I have a maximum of 8500 RPM, so I would assume that this type of ring is safe…

[Michail_Belov]

Installed magnets. Tried again, worked pretty well. I installed that ring on two motors. On the first, there was a slight vibration, which could be perceived only by touching the boom on which the motor was mounted. Also, after running for at 12.000 RPM for about 90 seconds the motor was slightly warmer to the touch than the other one. I swapped the ring onto the other motor, and this time there were less vibrations and no warming of the motor, probably because I misaligned vertically the ring on the first motor.

Now I am not sure whether to stick with magnetic sensors. To me it looks like a safe option.

[Karl_S]

If I may provide some input:

• I would install something of same weight at opposite end. In that way it should become balanced again and take care of those vibrations.

• The speed at which those motors are running, can be problematic for such a detection system. Have you considered using a small fork light barrier instead? …..see images below.

  
  

In that way next to no issues at all with balancing as a simple notch in the disc will do. Also no risk of a magnet flying off due to centrifugal forces and potentially causing damage.

…..just a thought.

[Vince_Hogg]

Hi, yes fair comment that modifying the ESC firmware can cause problems. I have (on the ground) done many transitions . At first we had an issue that if the ESC was in its alignment procedure it would not respond to other commands. That was rectified. I would like Alakamotors to check it over and perhaps include it in release options. Yes itÆs a kind of ratchet that only moves into position when there is forward airflow. I think the disk stays cool. These is no evidence of then getting warm. I think the disk helps to turn the top of the motor into a centrifugal fan and directs the air into the ESC cavity. I wanted the tail booms to be easily detachable so I needed to minimise the connections which is why I chose DroneCan ESCs. I did initially look at doing it the same way as you but im not so great with LUA. Anyway the MAD Components 4112 pro motor is just about the right size for my VTOL and this is an indecing motor so I may change to that.

[Vince_Hogg]

Whichever way it’s achieved is it worth the effort?

You may want to check my last post, redundant prop alignment idea.

[Michail_Belov]

I also though about these, but again there is the ambient light issues. It will most probably intefere with the sensor. Also, there is no room to install such a sensor with the motors I have, there is little clearance between the prop and the ring. If I would go the light sensing route, I would stick to TCRT5000 sensors, there is a much more reliable measuring algorythm.

[Michail_Belov]

I see. Initially, I was very reluctant to do what I did so far (a thin ring placed over the motor with the magnets), because I thought that it would be impossible to print something which would not cause vibrations due to imbalance. I was also not sure about the magnet weight differences. So far the test was very positive, and I ran it up 20.000 RPM, which is way above working RPM of 8500, and all that without any glue, but still I am a little bit worried about long term implications and safety.

My motors do not have that form yours have. Your ring is much safer. If I had used motors like yours, I definitively would stick with the idea of magnets, because you can make the ring thick and high and of relatively low diameter. My case is exactly the opposite.

I am 100 % positive that this setup with magnets will work. But, after sleeping it over, I decided to give first a try at the visual sensing of a white stripe placed on the motors, which is very safe from mechanical point of view, but may not be as reliable as magnets.

By the way, the software safety is also a major concern. That is why the ESC intervention is a very serious project. My approach should not cause any potential problems, because it is a high level programming, with less risk of messing up with critical timing, backward rotation (that is a potential horror scenario), or similar.

With lua script, there is only the danger of activating the feature when in incorrect flight stage and the ability to disconnect it rapidly when you need urgently to initiate transition to hover. That is done with just one correctly formulated “if” sentence.

[Michail_Belov]

Today did another test flight. This time the results were much better. The power necessary to fly level at 65 km/h dropped to 195 W. That was due to the change of motor and the prop, which is now 13 x 10, at 560 kV.

I also did a cheating alignment lua script, where lua nudges each prop sequentially until I manually stop the process by means of a switch, i.e. I am looking at the front props through the camera until they stop in the correct position. I barely managed to see the tips of the rear props, but I was not able to meaningfully confirm their position.

I also tried to put the front props in perpendicuilar position, and indeed, the power went up by about 10..12 %.

So I managed to fly 110 km in 107 minutes and land (at 16.0 V or 3.2 V per cell, and then tried two short VTOL takeoffs, with the second takeoff the voltage dropping to 10 V (2 V per cell under load), although after landing, the no load voltage was 15.7 or 3.15 V per cell). There was moderate wind of 30 km/h at the altitude, so I think that in calm weather, the same setup would go toat least 120 km.

The results now look much more promising.

Improvement Methods:

A. The main prop. The best I could find was a 13 x 10, which is good, but there are better options. I even tried a 11 x 12 prop, and it seemed to draw a little bit less power than 13 x 10 for level flight, but the acceleration and climbing were terrible.

APC has a 14 x 12 prop, and that one accoridng to Ecalc should be about 7 % more efficient than 13 x 10. There is also a 14 x 14 prop, which would be 18 % more effiicient. Not sure how it would behave in climbing. Probably, one would put a prop depending on mission, for long climbs, I would use a 14 x 8 or 10, and for maximum long range a 14 x 14.

More square props (where pitch and diameter are equal) are even more efficient.

B. Still I will have to design something for aligning props. I estimate that there is still room for improved efficiency due to prop position, about 7 to 10 % compared to the flight I had (where I maanged to align the front props manually).

C. I installed one fairing out of three, and by installing all of them, I expect another 4 % increase. The fairing have room for sensors for aligning props, and depending on the final selection of the system I will print the other fairings.

D. The battery… I have a somewhat worn out battery which is 12 % below its nominal capacity (now at around 2950 mah instead of 3350 mah.

E. larger battery. The plane has room for 50 % more cells. I have a 10 cell battery, which would increase the total battery capacity by 25 % or I could make another battery with 20 cells (5S4P), that would increase capacity by 50 %. I estimate that a 10 cell battery would increase range by 18..20 %. That extra battery would increase plane weight from 5.5 kg to 6 kg, And the 20 cell battery would give 30..35 % extra range withg AUW of 6.5 kg.

So if I start with 120 km range as is now, I can expect a range of 160 km with 40 cells and all the improvements.

With 50 cells that should be around 190 km, and with 60 cells 210 km, all with a quick VTOL takeoff and landing.

Estimated flight times will be 2 h 15 minutes to about 2 h 50 minutes.

[Michail_Belov]

My sensors arrived, so I did some testing… Seems to be working fine. As a marker, I put a small white paper strip (autoadhesive for the time being) and started measuring dark versus white ADC values using Pi Pico.

In the room, a white strip would give a reading of 70 (out of 1024), and original black motor 900. So, this was extremely good.

The V3115 motors had a few shiny letters and these were giving about the same reading as white paper (70..90), so I covered them with permanent black ink (it worked, value around 850).

Tried to align props semi manually, and it worked quite well, but I had to increase the width of the white marker (to about 6..7 mm). I was then getting 100 % success rate.

Next test was the sun light. It also worked pretty well, under most conditions the black reading was between 700 and 850, and white between 50 and 70. There was one position with light coming directly from above where the black was 75 and white was 50. This happens with an angle of about ± 3 degrees, so it was enough to turn the plane just a little bit to get back to somehting like 60 and 500. There is a gap of 3.5 mm between the motor and the cowling, and I decided for the next, final version to put a small strip to protect from the light and reducing the clearancfe to about 1 mm at that strip.

[Michail_Belov]

So I am modifying a little bit the cowling to reduce the gap. Also, in the final version, I will change from Pi Pico to ESP32. Pi Pico has only 3 ADC channels, and I could not get a multiplexer quickly. ESP 32 has plently. There is also the Nano and other arduino stuff, but they all work with 5 V, so in order to avoid headache I would stick to 3.3 V logic, that is something like ESP32, Pi Pico etc.

The sensor, TCRT5000, is very common one, is supplied with 3.3 V, and in my case the Emitter diode is biased with 330 Ohm, and the phototransistor with 3.6 kOhm.

The sensor reading algorythm goes like this:

ESP 32 receives a message (byte with motor number) from FC that this motor started its nudging run.
ESP waits for 30 mS, then starts reading ADC values, obtaining an average value and a minimum value (low value =white).

Then, it takes this range between average and minimum values, multiplies by 0.05, adds this to minimum value and uses this a cutoff value.

As an example, if under a certain lighting condition the white marker reads 60, and black reads 800, the averaged ADC would be let us say 700 and minimum would be 60. The difference between these is 640, and 5 % would be 64. So the cutoff value would be 60+64= 124.

Then ESP waits for the motor to stop (after another 50 mS). Reads again now stationaty motor. if the value is below cutoff value, the ESP sends back a byte with motor number which is aligned. otherwise, it does not send anything.

[Michail_Belov]

I think that the magnetic system would also work. The magnets did not arrive yet, so I probably forgo them since I will be finishing the prop alignment using TCRT5000 today.

Still, I would share some thoughts about them. The best magnet size would be 3 mm diameter x 2. A ring with walls 4 x 4 with two small protrusions must be printed, with a pocket which has 0.5 mm bottom wall. The pockets are primed with epoxy, magnets incerted, and again filled with epoxy above, leaving epoxy flush. From the tests I did the vibrations are almost zero.

The diameter of the ring itself must be determined by test printing rings with 0.05 mm step to get the tightest fit.

I would also epoxy the ring when mounting it on the motor.

The safest material is probably PETG, since ABS printing is rather complicated. PETG has a maximum temperature of around 75 to 80. So this should be fine, but motor temperature after long hover should be tested before, ideally in hot weather, maximum load, and for at least 3 minutes hover time.

The programming is even easier with magnets, it is very straightforward. The Pi Pico would just transmit the status of the sensor, without the need to time when the motor is running or is stopped.

[Michail_Belov]

Finished the physical connections and ran preliminary tests with the visual sensors. After some timing adjustments (for instance, the motor starts about 150 mS after the command is given, not immediately), it seems to work fine. For the time being I was testing only in the room, tomorrow I will give it a try outside and then do flight tests.

It takes about 20 seconds to complete the run. In about 80 % of the cases all four motors are perfectly aligned, and in 20 % cases one motor may be off by 15 º. That is still acceptable and could be solved by moving slightly the marker.

One major issue are the shiny letters on the motor. I first covered them with permanent ink, but it is also reflective and comes off easily. Then I put black autoadhesive stickers, and that seems to work better.

The other issue is the size of the white timing markers. My slit where the sensors are is 4.5 mm wide, and I decided to go with 7 mm wide strips.

I also tried to shine a LED 150 W projector at the sensors, but they are not affected by it.

Here is the ESP32 program:

#define ADC0 25 // Rear Left Motor

#define ADC1 35 // Front Right Motor

#define ADC2 32 // Rear Right Motor

#define ADC3 33 // Front Left Motor

#define RXD2 16

#define TXD2 17

// 3241

int ADC = {ADC3, ADC0, ADC2, ADC1};

void setup() {

Serial.begin(115200);

Serial2.begin(9600, SERIAL_8N1, RXD2,TXD2);

pinMode(ADC0, INPUT);

pinMode(ADC1, INPUT);

pinMode(ADC2, INPUT);

pinMode(ADC3, INPUT);

Serial.println (" =========================");

}

// ---------------------------------------------------------------

void getposition (int channel)

{

long int resultmoving=0;

long int resultstationary=0;

int res=0;

int resmin=9999;

delay (170); // about 150 mS for motor to spin up

for (int i=0;i<150;i++) // 100 uS per cycle aprox. 50 mS = 500 cycles

{

res=analogRead(ADC\[channel\]);

if (resmin>res) {resmin=res;}

resultmoving=resultmoving+res;;

delay (1);

}

resultmoving=resultmoving/150; // About 170 mS,

int range=resultmoving-resmin;

int margin=range/3; // 50% 25 % 5 %

delay (360); // motor must be stopped by now

for (int i=0;i<100;i++) //

{

resultstationary=resultstationary+analogRead(ADC\[channel\]);

}

resultstationary=resultstationary/100;

if ((resultstationary<resmin+margin) and (margin>50)) { Serial2.write(channel);} // if true, propeller aligned

Serial.print (" Average:");

Serial.print (resultmoving);

Serial.print (" Min:");

Serial.print (resmin);

Serial.print (" Current:");

Serial.print (resultstationary);

Serial.print (" Margin:");

Serial.println (margin);

}

// ---------------------------------------------------

void loop() {

int res=1;

int Lua=0;

if (Serial2.available() > 0) {

  Lua= Serial2.read(); // Lua sends the motor channel number (0..3) which it just started

  Serial.print ("Lua:");

  Serial.println (Lua);

  getposition (Lua);

}

}