Most of the pro multicopter set-ups have feedback from the ESCs so the controller knows the status of the motors. This is useful for all kinds of reason including:
1. debugging the causes of crashes - the controller could log when a motor has stopped running.
2. allows faster and better reaction to a motor failure perhaps saving you from a crash at least for hexas and octas.
3. automatic generation of a linear thrust curve which makes life easier for the attitude controllers.
As a first step towards trying to make that functionality available for the hobby/diy market I've managed to hack a hobbyking RedBrick50Amp and load it with a modified SimonK firmware so that it sends back timing information using the SPI bus to an APM2. This modified SimonK firmware is in my clone in the spi_feedback2 branch and the changes were pretty minor as you can see here.
Here's a picture of the set-up:
Now, it's really a first step, there are a few issues:
- It only works on the RedBrick50Amp because that's one of the few ESCs that is not using the SPI bus's slave select pin to control one of the FETs also you can see I needed to do some careful soldering to attach a pin directly onto the Atmega8. To make it available to all we'd need specially manufactured ESCs.
- Using the SPI bus would mean a lot of wires to the APM2. 5 wires from each ESC (mosi, miso, reset, slave select, clock) and 4 wires + 1 wire per esc on the APM2 side. I might look into trying to use I2C instead which would be just 2 wires per ESC.
- the feedback is the timing (in nanoseconds?) from when the ESC last switched the polarity of power to one of the wires. So the feedback is non-linear..you get very accurate feedback when it's moving slowly, but lose accuracy as it gets to the high end of it's range.
Still, a step in the right direction I think. All feedback and advice welcome!
Comments
Looks like I'm waking up a pretty old thread - just wondering where this got to since I just started playing with wii-esc for fun. (C based ESC firmware: https://code.google.com/p/wii-esc/)
I'm thinking of putting an RPM controller in the code that converts the PWM input to a desired RPM that linearizes static thrust through some interpolated lookup table.
The benefits here would be that the commanded rpm would be independent of the battery voltage droop and the rpm controller could be tuned to dynamically adjust the power to hit the desired rpm quickly.
But here's the question I have for the thread - is controlled rpm (static thrust) the right thing to do? As the quad starts zipping through the air, the dynamic thrust from a constant rpm prop will drop, essentially reducing the effective gain of the rate controllers. Anyone have experience here?
@Craig.. very interesting alternative, as that method is used in a number of automotive applications (abeit low rpm needs present).
Nonetheless, good work Randy!
Hardie, actually this is how it is done :)
Just something to think about, not sure how applicable it is:
The AC motors I use with variable speed drives at work, when first setting them up we have to do an "autotune" which. You need to take all the load (belts, gears, etc) off the motor and run it completely unloaded. The drive does a bunch of things I don't understand. Has to figure out a whole bunch of stuff that a brushless DC doesn't, since these motors don't have permanent magnets. The field being applied to the armature also has to magnetize the stator, which is really complicated stuff...
Anyway...
Idea is the "autotune" with no load. You could set up a proceedure where you do that. Now you should have a RPM/throttle for no load. Then you could do the same thing with the props on. Now you should have two curves, and it should be very easy to distinguish when you've lost a prop.
Another thing to think about, is to put a PID between the commanded prop RPM, and the throttle or torque. That's what the big drives do too.
Rob,
You must be right. It's probably microseconds not nanoseconds. It can be a very large number (takes 20 bits of 3 bytes) when the motor is spinning slowly.
Yes, it'd be nice to capture those kinds of issues. I was thinking flagging an error whenever the throttle deviates too far from an expected throttle for a given pwm.
I was also hoping to use it for other kinds of testing like engine reaction time. how quickly does the motor speed up vs slow down, etc. Currently the spi is only running at 50hz but it can probably go faster at least when running tests (i.e. not flying).
Robert, it should be possible for a autopilot to find a broken prob simply by using existing sensors and deduction. If excessive vibrations suddenly appear, the AP triggers a "broken propeller" failure function. This "broken propeller" function would then slow down each motor on at a time for or a short time period, and look at how the vibrations change to decide which motor has a problem. If this can be done fast enough, at least there would be an theoretical chance for a hexa or octo to keep flying. :)
Randy, you think that timing data is in nano seconds? That's a really short time period. I thought Atmegas can only measure microseconds? Or is that only a limitation of the Arduino programming language, but not the Atmega itself?
At 16MHz, it's running 1 cycle every 62 nanoseconds, by my estimation? So I don't think it's physically possible for the resolution to be faster than that, and even that might be a stretch?
The Arduino website says the resolution on millis() is 4 microseconds.
Just doing some math here... a 2830-740KV motor has 10 poles. At full throttle on 4S it should be turning 12,432 rpm. That is 207.2 rps. It has 10 poles, so that would be 2072 hz commutation? That means a period of 482 uS per commutation.
I don't think we need nS resolution here?
Now, one way to detect propeller loss would be to compare the loaded throttle/rpm to the unloaded throttle/rpm. When the prop goes, the motor will lose it's load, and will run must faster for a given throttle setting. You should be able to program to detect that.
But something even nicer would be to detect the loss of half a blade. This will set up really nasty vibrations that will surely cause the DCM to fail. It would be nice to pick that up, and kill the motor so we can regain control.
@Crashpilot,
Thanks for the link. I've heard of the AutoQuad ESCs but never looked much into them actually. This is a tactical step ahead of an Open Source (hardware + software), ARM based ESC. I really hope one of those appears soon. I've heard someone will make them but not yet apparently.
I think the $50 price per ESC for the AutoQuad ESC is going to make many people stick with the regular $10 hobby grade..having feedback adds value..but does it add $40 of value?
@Hardie,
A number of people have suggested using a hall effect sensor, monitoring the wire to the ESC or using an optical prop tachometer. Those solutions would likely work and I've tried using an UNO to monitor the wire but the results were quite noisy. I also don't want to add more failure points by adding more hardware. The ESCs know the state of the motors, they're just not telling us.
In whatever form it finally takes, this two way communication between controller & ESC opens up other possibilities..I learned today that for a hexa to keep flyign with a failed motor, it needs to be able to reverse the direction of the opposite motor..this kind of thing can probably only be handled smoothly with an ESC that's well integrated with the controller.
BTW, what I've done here is totally a hack.. not the best solution, but it's got some potential.
What's up with these ESC: http://autoquad.org/esc32/
Still missing driver for canbus and I2C but they are programmed in open source C. (And they have much more cpu power than APM - and that's a shame)
So long
Kraut Rob
Yeah, this one. $20 + shipping sounds expensive to me for this.
Anyway, your idea could go along with Randy's - they won't disturb each other and can be complementary.
-
1
-
2
of 2 Next