26 replies to this topic

[Daniel Wee]

Hi,

This is another Open Source project brought to you by IF.

Project Brief

You know how we all always wonder about which motor is best for our planes, and then which prop works better. Along the way we get offered lots of useful data, and anecdotal advise - which is useful, but sometimes conflicting. Plus it is hard to choose because there are so many options available and combinations. Well, as you can guess, I'm one of those guys who can't live with too much ambiguity and guesswork. So, this project was born, out of a conversation I had with Mark late one night about how cool it would be to be able to settle this issue once and for all. For people who are into this kind of thing, who need actual numbers, I thought of calling this the Automated Normalizing Algorithm project (or ANAL for short). Okay, maybe not.

The device is an MCU controlled thrust test rig. It will be able to control the motor power, and at the same time, read out voltage, current, power, thrust, throttle, and perhaps some other data. (provision has been made for temp and RPM but not currently used). With the MCU controlling the test, hopefully there will be good repeatability.

The Project

One of the key components for this project is to have a digitally readable thrust sensor. If you look around in the market, you will find that this usually means some kind of load cell or strain gauge. These things are not cheap, however, and can be quite involved to set up and calibrate. Maybe a bit too involved for my liking. So, I went out to the shops and found myself a 5kg range digital kitchen scale (CAMRY EK5350) with the hope of hacking it so that it can be used for my purposes. This cost me some USD28 or so and was a gamble. In fact, you can probably find cheaper ones on e-bay by my impatience was getting the better of me.

Okay, so now the whole project hinged upon my successfully getting a digitally readable thrust sensor. I got home, put in the 9V battery and fired it up to test it. Sure enough - 5kg limit before giving the ERR message. Time to whip out the screw drivers and after a little examination, I found out how the case comes apart. Opening the case reveals a standard strain gauge used as part of a Wheatstone bridge implemented on one single PCB. The strain gauge feeds the bridge which is in turn processed by a quad op-amp. The output then goes to a MCU under a blob of resin so there's no way to tell what the part is. Measuring the voltage from the op-amp proved difficult since the output range was in the order of less than 100mV for full-scale, which will require a high-resolution ADC or a scaling-amp or both. I wasn't really intending to do so much work for what seemed like a relatively simple project.



So I figured, there must be more than one way to skin a cat, and no hacker worth his salt will get stumped so easily, or give up and start asking others! So, out comes the oscilloscope and after some probing, I found an unusual square wave around a CD4066 switch array. This was interesting because it looked like some kind of PWM. Following the signal through the switch got me a nice clean PWM signal inversely proportional to the weight! Bingo! Got it. This will work perfectly for me. Simple tests reveal that this will do the trick so my 28 dollar gamble paid off and we're in business.

<to be continued>

Daniel

Edited by Daniel Wee, 18 November 2007 - 08:48 AM.

[Daniel Wee]

So, now that we've ascertained that the project is doable, and economical - I need to come up with a way to add intelligence to the test rig. This will take the form of a controller (dsPIC30F4012 since I have a few of that lying around) on a small board that will interface with the ESC, Current sensor, Voltage sensor, the hacked kitchen scale, and some other stuff. I also thought of adding a wireless serial link to the PC but this proved to be more expensive that I was keen to spend at the moment so that was scratched for a normal wired serial link. Of course, I would like to re-use as much code and hardware as possible so if you've built a DragonOSD, this project should be easy to do since the ICSP programming header is the same, and you can use the same mikroC compiler, the same USB level converter and so on.

Other than that, I will need to built a rig that will be suitable for testing the motors. For this I used an idea I got from seeing Mark's rig. Mainly glued together except for a few places which needed more strength, the rig was made mostly from wood (hardwood for the arms).



If you have the parts, you can probably make the rig in under 2 hours. For the fulcrum/pivot, I used a T-Rex steel main shaft, held together by retainer rings on either side, and supported with ball-bearings. I selected the arm lengths so allow clearance for the biggest prop size I intended to test. Both the arms should be the same length (more or less).

With that aside, I went to the drawing board for the schematics.



As you can see, it is very straightforward and simple - as is expected for a little project of this nature. The PCB is also pretty small, about 30x50mm or so. Some of the things I put in there may not be used, for example, I felt that I didn't really need a temperature sensor so I didn't put those parts for it in the PCB. You can use them for different purposes, for example the RPM sensor can be re-used as an input button for example. Or as Mark would say - "Whatever floats your boat."



Daniel

[Daniel Wee]

Okay, that's the easy part - the hardware. Now we need to do some actual interfacing to see if the theory behind the project pans out. I threw together some quick and dirty code and managed to get the controller reading th PWM from the kitchen scale. Unfortunately, as it turned out, the relationship between the weight on the scale and the PWM signal was not a linear one. The PWM signal was in fact inversely proportional in a non-linear way. At the lowest weight/strain, the PWM had a period of about 0.380s or so, so you get some 3Hz readings at the slowest, and much faster at higher weights.

The major problem that presented itself to me at this point, 2-days into the project, is how to characterize this relationship so that I can meaningfully convert the PWM reading into actual weight. The first thing I had to do was gather some data, and so I did - some 40-points of data from 0g to 5kg (as read from the scale readout). With this data, I did a scatter plot between the weight and the reciprocal of the PWM reading. The resultant curve didn't fit any of the simple non-linear functions so I had to resort to some heavy duty curve fitting. After about a day's work - I finally got a reasonably accurate fit over the desired range using a 12th order polynomial function. Okay, so now, I implement this function in the software and after some adjustments, walah!, I have now reasonably accurate weight readouts. There was some inaccuracies but nothing more than about +-10g or so either way, depending on where on the curve you found yourself.



As you can see from the curve, it remains fairly linear (Y = 1/weight) until you reach very close to the limit (5kg). This is good for us because we have limited mathematical precision with the built-in math functions. In fact I had to scale the polynomial function so that the coefficients fell into a more optimal range and didn't keep suffering from rounding errors.

In the process, I found that there seemed to be some jitter in the PWM but it was due in part to my excessive PWM resolution. After converting to grams output, it was still a bit jittery but nothing too disconcerting. Okay, we've now overcome one of the major hurdles so things can start moving real quick.

Daniel

Edited by Daniel Wee, 18 November 2007 - 08:15 AM.

[Daniel Wee]

Next I had to hook up the current and voltage sensors. For this, I had a IF current sensor that Mark sent me. I had to remove the little resistor on the current sensor side (same as I had to do with the conversion for DragonOSD use) because that resistor really shouldn't be there in the first place IMO. With that out of the way, I hooked it up (bearing in mind that the colour of the ground wire is RED here). It's a small mistake but someone could easily assume that red is positive. I also added a wire so that I can read the voltage off the Deans connectors.

I also had to add a level converter between the MCU and the PC serial port (since I wasn't using the USB converter, which is much niftier but I don't have one yet). In the process I decided to use the linear regulator on the underside of the sensor board to power the level converter. This resulted in some issues since it looked like the output was the wrong voltage. As it turned out, one of the resistors in the voltage divider was bad. No problem, I've got lots of resistors lying around and it was easy finding the right value and I fixed the problem so now we have +5V for the level converter.

A quick write of more code allowed me to verify communications with the PC (not after some hours of debugging my wiring). At this point, the hardware is confirmed to be working and correctly wired up. The basic code is written but needs refining, which should be easy since I'm under no memory space constraint for this project.

The current sensor reading algorithm is interesting because you have to realize that the output from it is actually some kind of AC signal with a DC bias component. This is because the ESC is actually using 3-phase PWM for the motor. If it was a simple DC, it would be easy to measure but as it is, it requires a bit more consideration. Since the frequency was about 8kHz or so (as viewed from the scope), I picked a sampling frequency way above that so as to avoid aliasing (above the Nyquist limit). Then you had to basically average out the readings over a range. I did this using a simple moving average filter and now we have a very stable current reading, which along with the stable voltage reading, meant that we have good power measurement.

I spent half a day writing and refining all the basic functions in the software, and added a simple text interface so that I can test the working of the functions through a serial terminal software (HyperTerminal in this case). Man, it's exciting seeing all the stuff coming together and the software working. After some basic debugging, the core functions were all ready. I could, for example, just issue a command to hold the motor at 50W, and it will strive to do that, dynamically adjusting the throttle to compensate for voltage sag. This was very cool

Now I had to go back to actually building the rig since we're ready to put everything together.

Daniel

[Daniel Wee]

The test rig itself, as alluded to in one of the earlier post, is made mostly of wood. I'm no mechanical genius and really like to keep things as idiot proof (that's me) as possible. Made of cheap wood I bought from the $2-store (except for the hardwood used for the arms) it is held together mostly with epoxy. It took me about 2-hours of sawing and cutting up stuff to get it all together. Once this was done, the only thing was to mount the motor at the end of the arm, which I did with four large cable ties (can't be too careful in this department). Once I was satisfied with this thing, I quickly hooked everything up. There are some additions I'd like to make to the rig, such as a restrainer to prevent the motor from falling back if the propeller was turned the wrong way, for example. In any case, that will have to wait because right now I can't wait to test the thing.



The first thing I did was to make sure that the motor was pulling and the prop was turning in the correct direction for that. A low throttle command from the computer showed that it was turning the wrong way so I had to swap some motor wires to get it right.

At this point, I should mention that when I tested the motor earlier, without a propeller mounted, the motor (AXI 2808/24) would max out at around 0.9A (uncalibrated), which meant that the maximum power without load was about 11W. Now, I had the rig set up, I put a MasterScrew 7x4E propeller on the motor and sat myself down at the computer and started issuing commands manually.

Lo and behold, everything works, like magic. I was getting thrust readings as expect and all control functions are working correctly. Amazing. Now I have to come up with a test protocol and to calibrate the rig. Then I will be ready to start testing motors and props in earnest. Currently I am using a TP2100 3S 15C battery for the test. In actual testing, I should be using a regulated power supply so prevent voltage sag issues. This I will start looking into this coming week.

I will be posting the source code and EaglePCB files (schematics and PCB layout) soon so stay tuned if this floats your boat!

Daniel

[Daniel Wee]

Thrust isn't everything

I had a chance to talk to Andre (Kilrah) about props and realized something important about testing this stuff - air speed. Basically the idea is this, that for a given motor, propeller, and power system, you can only generate a certain amount of air movement that is measurable as air speed. So at full power, you can move air at a certain speed and no more. For the lack of a better term I'd like to call this the Vlim for limiting velocity.

What this means is that as your plane goes faster and approaches Vlim, the thrust generated will approach zero and current drawn will also drop. This is because the relative airspeed that is around the prop approaches zero. Of course, I don't think you will actually reach Vlim but this is something to think about. Measurement of static thrust does not take this other aspect into account - ie. you can start with a certain amount of thrust but how fast will that thrust decrease as you start to move faster. As such it is conceivable that you have two propellers, A and B, which both have the same amount of static thrust (Ts) (putting aside power consumed at the moment), but at 50kph, find that prop A generates only 20% of Ts, while prop B generates 50% of Ts.

I never thought about this problem before and now that I do think about it, it makes perfect sense, and I wonder why I don't see this particular aspect being discussed. There are also other factors that may be related but this is the one thing that has been bothering me, ie. what is the difference between a smaller but high pitch prop vs. a larger but low pitch prop, if both of them are drawing the same amount of shaft power. And the answer is that the smaller prop generates less thrust but will do so over a wider range, while the bigger prop generates more initial thrust but will drop off quickly as you go faster.

What this means now, is that we need to know Vlim for a prop, and to know how fast our planes normally fly, limited possibly by terminal velocity. If we find that our normal speed is close to Vlim, then the prop is going to perform badly even though it might have good static thrust. What I could do is to work out the relationship between Vlim for a given prop and RPM. This would be quite involved actually but for practical purposes, what I really absolutely need for the moment is to measure Vlim for the prop at full throttle. I think I will do this an anemometer placed very near behind the prop. Of course, this won't yield very accurate results due to uncontrolled air flow but all I need is a ball part figure of Vlim.

Now, to find a cheap digital anemometer that I can hack, or make one out of a brushless fan. Your thoughts on this whole post is most welcome.

Daniel

Edit: I took apart one of the DC brushless motor I had lying around. These are the types used in most CPU cooling fans. In side there is a small circuit that controls the DC commutation so I had to bypass that and solder wires directly to the coils. Having done so, I scoped the output of the coils (looks like 4 poles but only 3 are connected. My guess is that they're using 2 coils and the third is used for sensing position. Anyway, as expected, the AC current generated by the coils is an indication of the rotational speed of the motor (on in this case a generator). The peak to peak voltage was around 400-500mV at the lowest possible speeds. This isn't too bad, and I just need to find a way to amplify this so that it becomes a square wave. Either that or I could process it with the ADC but this will be a bit more CPU intensive (for the MCU). Time to hit the datasheets again, I'm sure there's an easy way to do this. If this gets too hard, I'll just hold a digital anemometer there and take the reading directly and make life simple (bit a little less elegant).

Edited by Daniel Wee, 18 November 2007 - 08:24 PM.

[ssassen]

Daniel,

Now, to find a cheap digital anemometer that I can hack, or make one out of a brushless fan. Your thoughts on this whole post is most welcome.

I actually have also built a test rig before for prop/motor testing, not an automated and fancy one like yours, but I did take the airspeed into consideration. How? Simply by using a Wemotec Midifan EDF with a Speed 600 brushed motor with is put in front of the prop/motor. This is simply hooked up to a variable 25A bench supply and can put out >1kg of thrust, but more importantly it will give you an airspeed range of 0 ~ 180km/u. I checked this with a digital anemometer which I use for my other hobby (kitesurfing).

Cheers,

Sander.

Edited by ssassen, 19 November 2007 - 12:31 AM.

[Daniel Wee]

Hi ssassen,

I don't think I will need to simulate the airspeed environment. Just putting an anemometer behind the prop going at WOT should give me the maximum air velocity. The thrust should scale non-linearly with the air velocity (I think), and we should be able to predict what kind of thrust we can get at any given air speed if we can characterize the relationship between thrust and airspeed. In this way, we could for example, derive the actual max thrust at speed X but multiplying it with X/Vlim. This is assuming a linear relationship of course but the idea is similar for non-linear relationships.

In the mean time, I thought I'd try some simple test protocols. Note that in these tests I was using a battery and the APC test was done last, by which time, there had been some voltage drop. For the moment, I am using 20 data points between 0 and 100 percent throttle. The charts below were also plotted against throttle. I should also generate charts which plot the thrust against power. But this is just to give you an idea of what's happening here so no need to get pedantic about this. Also note that I have not calibrated the thrust or the current. The voltage is calibrated though. From the setup, I'd estimate that actual thrust will be about 5-10% higher than shown in the charts below. I also need to re-calibrate the ESC end-points. Right now it looks like it maxes out at around 90% throttle and starts around 10%

First up - MasterAirScrew 7x4 for electric motors.


Next, APC 7x4SF


This is getting fun!

Daniel

[pseddon]

I would strongly recommend having a look at http://www.mh-aerotools.de/airfoils/ which has some very good reading about props.

As well as the problem of the thrust reducing as the airspeed increases there is also the issue that at high pitch values parts of a prop may be stalled at low or static airspeeds leading to erroneous results. Prop design and selection seems to have a degree of black art which is not helped by lack of standardisation such as how the ptich is measured.

I have used MotoCalc to assess various options and then test flown to see what works for me. A quick run on the ground with a wattmeter to confirm the theory and then off into the wide blue yonder!

Good luck,

Peter

[Doofer]

I'm with Ssassen & Pseddon - these are small props, the Reynolds numbers are very high, I'm very pessimistic about making predictions about the thrust obtained at a given prop tip speed (rotational, not just a function of forward speed) in dynamic air from measurements made in static air. What happens at the flow boundaries as you move from stalling to laminar flow seems (almost by definition) chaotic...

Ssassen, I'd love to see some pictures of your Home Wind Tunnel (Li'l Cyclone ™?).

[Daniel Wee]

Yes, it does sound reasonable to do the test in a wind tunnel. I could actually add one more channel to control the EDF motor for the wind tunnel. The trouble is that I don't have space in my humble abode for the whole contraption. We'll have to see if Mark wants to do it.

I have read the articles linked above and they are indeed very helpful and revealing. The basic idea is that tests under static conditions suffer from the possibility of tip stall. Furthermore, one of the articles also suggest that thrust obtained statically may be only 50% of actual thrust obtained. Now, this is very interesting because it would seem to suggest that if I provide an airflow over my test rig, I will get higher thrust. This seems somewhat counter intuitive. I'll have to read the stuff more carefully but if space wasn't a problem, it would be quite easy to make a wind tunnel and put the whole thing inside.

Daniel

[ssassen]

Daniel,

Static thrust figures are in my opinion just that: static thrust figures. They can be used to approximate the level of thrust for slow flying models. For example I've done some testing on 9", 10" and 11" props for my 3D planes, and found that due to the slow speeds these fly at and the fact that they're hoovering or otherwise not flying forward at reasonable speeds mostly the static thrust figure gives me a good approximation of the actual thrust.

I also have a few deltas, with very high KV motors which obviously will not be hoovering anytime soon and here the static thrust figure is a bit meaningless. I used a airduct made out of depron, balsa wood, a Wemotec Midifan and a similar scale like your to do my airspeed testing. Mostly on smaller 4, 5 and 6" props running in excess of 15K rpm. Like you I'm always cramped for space so I built it up quickly and took it apart after I selected a suitable prop based on the measurements.

Cheers,

Sander.

[Daniel Wee]

Hi ssassen,

In your tests with the wind tunnel - what kind of difference did you find? Ie. for a given test, what is the difference with and without an ambient airflow? Were you able to determine how the thrust changed when you added airflow?

I'm actually doing this so Mark, who has access to a lot of motors and props, can go about testing them easily and accurately. I see the wind tunnel as a related but separate project. My own interest at this point stems from performance issues. For example, is it possible for a prop with a lower static thrust to outperform another prop with a higher static thrust at some given wind velocity, all else being equal.

What I'd like to end up with is a performance curve across the expected operating range. This will probably take the form of several charts, one for each wind velocity test point. This way, I can compare apples to apples and come out saying, definitively, that prop A will out perform prop B under given conditions. And then we'll slap on various props and eventually say that for this motor and plane, prop X is the best so forget all the rest. We can also test different motors but usually that is easier than testing props. Ideally, you can have all the data and just specify your performance point, and you can be recommended the ideal combination, and then given charts to show the expected performance.

Bottom line, I'm trying to replace all the guesswork out there with empirical data.

Daniel

Edited by Daniel Wee, 19 November 2007 - 04:16 AM.

[Daniel Wee]

Okay, I did a few more tests, same set up but with different props so that the lack of calibration is not so much of a problem since we can have relative comparisons. The two other props tested are the APC 7x4E and the Aeronaut 6.5x4 (which vibrated badly). Here are the charts (Thrust on the primary vertical axis (g)):-

(Note that although the chart says APC 7x4E, it is actually an APC 7x5E. I misidentified the prop).





Note that the battery was freshly charged so it's a bit unfair to the earlier tests. In order to mitigate that, I decided to do a thrust vs. power plot with all the four props tested so far. Remember, I'm just testing the system so the data presented is just for the purpose of giving the test platform a going over. Vertical axis - thrust (g), horizontal axis is power (W).



In order to make things clearer, here's the curve fitted chart:-



There are a number of things one can surmise from this. It seems that the APC7x5E gives more static thrust for the same power input compared to all the other props tested, and notably the APC 7x4SF. Secondly, notice that the curve was relatively linear up to about about 30-40W or so and then it begins to taper off a bit. I wonder if this is due to the problem with static testing and the air flow separation. If so, perhaps by providing some airflow, this point will be pushed higher. The longer lines are indication of higher maximum power achieved but this could be due to different battery states at the start of the test.

Again, I know this is not perfect, but I'm fascinated by the test results. At this point, no prizes for guessing which prop goes onto my EasyStar.

Daniel

Edited by Daniel Wee, 19 November 2007 - 09:37 AM.

[Daniel Wee]

Also, as an additional point of interest - the APC 7x5E generate a maximum air velocity of 61.4km/h while the Aeronaut generated a maximum of 53.2km/h.

Daniel

Edited by Daniel Wee, 19 November 2007 - 09:39 AM.

[Daniel Wee]

I found my spare APC 10x5E and decided to give it a go to see how it stacks up with the rest. Well, it nearly lifted my test rig up! Lol! Here's the chart:-



and the comparison with the rest (note that APC 7x4E should be 7x5E):-



The top air velocity measured at WOT was 65.1km/h, close to that of the APC7x5E so not much faster air from the additional pitch. Top power was 197W (at 9.9V, 19.9A) compared to 116W from the APC 7x5E. The voltage sagged considerably (9.9V) at WOT so the battery I'm using doesn't seem to be quite up to the job. Time to consider a bigger battery.

Another thing to note is that the bigger prop is much more efficient than the smaller props. Compared to the APC 7x5E for example, which produced 531g of static thrust for 117W of input power, the APC 10x5E produced 734g of thrust for the same input power. The bigger prop was however drawing more current at a lower voltage than the smaller prop was to produce this same amount of power, as expected. I'm sure more can be said about this but I'm a bit tired to think right now.

Daniel

Edit: Also, as a matter of interest, I've calculated that my uncalibrated thrust measurements are actually low. Actual thrust should be 14% higher that what is shown here presently. On the other hand, the current figures match up quite well with MotoCalc's predictions.

Edited by Daniel Wee, 19 November 2007 - 05:50 PM.

[Kilrah]

Another thing to note is that the bigger prop is much more efficient than the smaller props. Compared to the APC 7x5E for example, which produced 531g of static thrust for 117W of input power, the APC 10x5E produced 734g of thrust for the same input power.

I wouldn't talk of "efficiency" there, it's misleading. All you can say is it provides more thrust at the same input power. But the actual efficiency (Pout/Pin) has nothing to do with this.

[Daniel Wee]

That sounds like efficiency if you assume that Pout is related directly to thrust generated. Am I missing something here?

Daniel

[twinturbostang]

That sounds like efficiency if you assume that Pout is related directly to thrust generated. Am I missing something here?

Daniel

Look at pitch speeds also. As you said, a given prop may give more thrust at low air speeds, but "run out of steam" at higher airflow numbers. whereas another prop may continue to pull far past the other one. It all depends on your application. Do you have a 3D flyer that you want to hang on the prop? Do you have a flying wing that you want to push to 150 mph? In both cases, it's possible they could be producing the same amount of power, just in a totally different way.

Edited by twinturbostang, 19 November 2007 - 12:45 PM.

[Kilrah]

Power = force * speed. So you'd need airspeed to calculate output power. But as that's pretty tricky to measure precisely unless you have a nice tunnel as the airflow is very disturbed behind the prop, the torque*RPM approach is usually preferred, even if by doing that you don't count prop efficiency and thus still miss something...

Edited by Kilrah, 19 November 2007 - 01:14 PM.