Hi all.
I have made a long run at 'human flight level'.
The machine is basically EasyStar with FLEXIPILOT but the discussion applies to anybody using typical hobby grade ESC. The plane is equipped with RAY 2845 inrunner motor and RAY 25 ESC, same as JETI ECO 25. Runs on Kokam 4Ah SPLB 30C. The plane is equipped with humidity and external temperature sensor, as well as additional temperature sensor for barometer compensation.
The flight took place with average cruise speed 12m/s (46km/h), the wind was around 1m/s (4km/h) and took place late afternoon.
On one hand the humidity was increasing, very slightly decreasing lift conditions:
At the same time the temperature was dropping, making air thicker, improving lift conditions:
This meant that while Standard Altitude depending only on pressure was contant,
density altitude decreased by negligible 50m (lower is better, less is more and time is infinite):
Overall, thanks to very calm weather and excellent PID tuning also, long term altihold was within one meter (slightly above my head). The spike at the middle was temporary switch to RETHOME for pilot's amusement (got bored).
As time passed by, battery voltage was dropping
And total energy of the plane (kinetic+potential divided by mass) was like this (constant):
This meant, that with constant plane geometry and aerodynamics, roughly the same amount of power had to be injected to the engine - it was autopilot's job.
Indeed the PWM throttle output signal (10000=1ms) was rising gradually, 'ordering more ESC output' in order to compensate for dropping voltage:
Power injected is P=U*I, and one would expect P to be constant, yet... here comes the surprise
Looks like electric power input to the motor was jagged, because the ESC could command only larger jumps of throttle... You can see amperage sensor confirming the stepped amperage increase, compensating for smooth voltage drop:
As a final confirmation, the RPM sensor revealed that the throttle was basically jumping +/-60RPM what could be even heard (now I know where does this sound comes from)
if we assume that the whole span of RPM control of this ESC is some 0-15000RPM, you get 15000/60=barely 250 steps, what is some 8 bits! To be more precise, I would describe the situation, it is not ESC having problem with RPM hold (which is not even trying to do) but rather having stepped amperage output control that also drifts a little with voltage. Since this UAV flies only between 10000 and 14000 RPM (below 9000RPM the motor generates only a tiny thrust) you actually have 4/15*250=67 possible and useful output amperage values.
By sounds that I hear from the propeller, probably all popular ESC brands behave less or more like this (what few people have witnessed because few ppl are doing routine loiters that low). .
Now since you are at the end of this analysis, a question for 10 intergalactic points:
Which ESC behave like this and how to identify those that do better?
Comments
@Martin This sounds interesting could you clarify.
My point of view that all of us (correctly) assumed fast response rate is the key for good control loop tuning and flight quality. What I have discovered, that probably, there is a lot of sacrifice in ESC resolution in order to get fast response rate. In fact direct PWM drive at 20KHz in itself is a perfect control method with 1/20000s response time... but 1 bit resolution.
It appears that by asking for response rate we have sacrificed (or neved asked for) resolution, what means with better roll authority with quadcopters, you will have to give up some stady state hovering precision (and also roll precision itself, what translates to horisontal position precision). Winged platforms can compensate lost altitude resolution with elevator, what was the case in this flight, but in general do not need excellent thrust response rate.
If there is damping by a ESC manufacturer to a motor with accel and deceration rates with a given command pulse width there will be issues. There should be a Multilift rotor option the ESC manufacturers can do.
Krzysztof, I have had some experience testing motors on the benchtop measuring thrust and monitoring voltage and current. I used a Arduino for generating the servo pulses and displaying data and setting speed. My conrtol resolution was 0.1%. You could hear the motor pitch change only after a .4% change. Also could see current and thrust change the same. 100/.4=250, close to 256, 8 bits. It was a castle creations controller with is not the best, but a good quality ESC. My goal was to get thrust curves for the motor/prop combo and I quickly found out you thrust drops off rapidly with a full battery making it hard to get reliable data. So I scaled my output to the nominal battery voltage, 11.1 v and it worked beautifully. The thing would hover on its test stand(I was using an old lab balance) for the entire battery life until it reached 100% on the compensated output. I too thought that 8 bit is pretty low resolution.
video
@Richard In this case steps are so huge that even RPM magento sensor picked it up when plotted! But you couldn't just read it using any human-readable meter. The RPM sensor had resolution of 2RPMs in this case with 0.5s sampling period, I would say I trust him. This was only 6x4 3-blade windsor with very little inertia compared to heavy inrunner.
I mean ramping the throttle over that kind of time period.
Perhaps 20 sec is too short, however in your graphs the 'jumps' are clear and large with the very small throttle changes required to cover battery discharge so I would expect a current log to be able to show that.
I would agree that doing the measurement by hand may well have too much noise - plus you'll see the Tx and Rx steps as well. You'd want to drive this test directly from an MCU.
You would not see the jumps by eye as the momentum of the motor alone will smooth out the RPM changes, but I think it would probably show up in a log of current draw.
Blimey
Yes floating 2-3m AGL but very flat terrain and very calm weather. I was jumping to hit dangling RX antenna a few times, succeeded once. Normally I feel nervous at 5m, remember it appears to touch the grass 'on the other side' with every turn.
Did you say at 3m for the entire flight!!!!!!!
To continue on the resolution topic, typical RC controllers have 1024 positions (10 bits), some PC systems have 2048 positions (11 bits), FLEXIPILOT has 10000 counts per 1ms what is 0.1us (more than 13bits), many custom-made controllers have 1000 counts per 1ms (10bits).
Formally popular servos have 5us (or 8us) deadband what is about 200 counts BUT deadband is basically buzzing attenuator, while in movement thay are able to achieve much smoother running on 2048 futaba PCM systems than 1024 as reported by acro heli flyers. So there are good reasons for having the resolution.
@richard "slowly raising the throttle to a high-ish value over around 20 seconds. That should be slow enough to see steps if they really are only 8-bit."
Might be difficult since potentiometer noise on the transmitter would blur the picture, but should be visible below 9 bits. Remember you are looking at the logs from 38mins, 20s run would be zig and zags.
The most common way to generate the ESC commands is by using a 16-bit hardware PWM to generate the 1-2ms pulse length at 20ms period.
This method gives a resolution of ~3277 discrete levels, so I would expect at least 3000 steps to be available to a well-designed ESC - not the 255 discrete steps this one appears to have!
For fixed-wing aircraft the low resolution probably isn't that bad.
However, for multirotors and other 'throttle-stabilised' designs this matters quite a bit.*
For those who don't fly these, 8-bit precision of the rudder would mean 0.7 degree steps of physical position (assuming +/- 90 degree full mechanical swing)
It would be very interesting to learn if this result is common to many ESCs.
This could be tested by quite easily anyone who has a 16-bit or better current sensor on their aircraft - tie it down and log the current while very slowly raising the throttle to a high-ish value over around 20 seconds. That should be slow enough to see steps if they really are only 8-bit.
*Excuse the pun.
-
1
-
2
of 2 Next