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?
^ Good point, I have never dealt with CTs at such a high speed, like over ~4k pps. I figured great precision wouldn't be required for this non-contact direction, it would be more of a "state" transducer with just enough detail to determine RPM and more or less a good/normal or bad operating condition, with some relative current amplitude info. Would not replace e.g. the AttoPilot for actual measurement.
Edit: the frequency is not a prob after all for what I'm thinking of, 20k RPM is fine.
@Craig.. very interesting alternative, as that method is used in a number of automotive applications (abeit low rpm needs present).
Nonetheless, good work Randy!
^ Yes, or use a donut CT (ferrite core with a few turns of wire) on one of the 3 motor wires...2 wires, but enough info to determine RPM and current. Main advantage is cheap and simple, commonly used for other (typically much larger) motors and doesn't depend on the controlling electronics (ESC) for anything special i.e. removes ESC from equation, only measures the results "after" the ESC.
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. :)
-
1
-
2
-
3
of 3 Next