I'm starting this thread in order to begin a discussion on potential Governor systems for use with Arducopter.
Malcolm Churn started talking to me about it a few days ago and it seems like something that is worthwhile pursuing if the AC system is ever intended to be used for truly autonomous sUAS, particularly any Helis with engines. External systems are already available, but this seems like the perfect opportunity to use the power of the APM to build-in a dedicated system.
Currently, my thinking is to use a small Arduino board which will be connected to a hall effect sensor, and relay a speed signal back to the APM. The APM will take the speed feedback, and use a tunable PID loop, with feed-forward from the pitch control system. The reason that a seperate Arduino would be used is because I believe the sensing needs to be done on a very fast loop, and interupt driven. I'd rather not burden the APM with this.
I'd also like to add some functionality for automatic soft-start.
Other features would include rotor speed telemetry. And in the future, the possibility of rotor speed droop warnings and maybe even automatic auto-rotation (yeah, we can dream, right?)
One big question I have it how to get the signal between the Govern-Duino and the APM. Analog 0-5V would be easy and is somewhat of a standard in industrial use, but subject to noise. I'd prefer something like PWM. But I'd like to do it without "wasting" one of the 8 radio channel inputs, so need to investigate is there is an open PWM input we can use.
We may also discuss third-paryt governors already on the market for ideas, or potential use if they make sense.
Here's a hall effect sensor I am considering:
I'm curious to know a bit more about the existing governor systems. I assume they use some sort of collar that clamps on to main shaft? Is it steel, alu, or plastic? 1 magnet or 2? etc.
They all use a magnet which you drill in to the cooling fan attached to the motor. The GV-1 has a sensor which needs the magnet to be aligned to the correct pole. The others have sensors which the magnet poles have no influence on (they just see it North or South). Then you set The correct gear ratio and the AMP does the maths. You cant attach it to the Rotor mast as they can spin freely due to the one way bearing. Most Engine Helis come with a pre drilled hole in the fan. As the magnet is so small there is no real weight issue with imbalance.
You have to teach the system the throw of the servo, the correct direction, servo type etc
the switching works as.... anything below 25%collective throttle the system switches off, as soon as you hit 25% throttle and the rotor speed is at a set amount, the governor takes over and slowly speeds the engine up until the setpoint is reached.
There are other things like a 3 speed setting but we wont need that on UAV's.
Ah, you keep it on the motor side just in case the rotor speed is greater than the engine speed. Why is that needed? Shouldn't we care more about rotor speed than engine speed? If the engine stops, and we have any hope of doing an auto-autorotation, we need rotor speed.
It might be possible to do both actually. I also want to protect for Tandem rotors, that could mean 4 inputs.
Now, one question is, some of the Arduino boards (the Pros) are smaller than a Uno, but they don't have a built-in USB connector. So to program them, you'll need an FTDI cable or an "FTDI basic" board from Sparkfun? Which would be preferrable?
I should probably just buy a Uno for now. Easier to use, and it's the same chip as the pros, so while we're playing around...
Its on the motor side because it so much easier to control that rather than the rotor mast, which can spin freely, so if it over speeds the engine will back off so far it could go to tick over, and when the mast slows its got to come from idle, back to speed, If you control the engine it will always be at the right speed to keep the rotor head at the set point even if its under no load.
Keep the board as small as possible, i'm running out of room now :)
I can't find the link now, but I believe I saw that Hacker demoed a brushless motor with a magnetic rotary encoder. It didn't specify which, but it probably was an AustriaMicrosystems AS5040 or similar. I've worked with an AS5040 and Arduino for low speed position control, but it will also do high speed (up to 30,000RPM I think), so it would be perfect for a governor. I purchased some boards from MadScientistHut.com, and used the Arduino PID library. I imagine you could 3D print an adapter to hold a magnet to the shaft...
Seth, that's interesting, but... I think it's WAY overkill for what we need. We don't need angular position.
Ah hah! I'm going to go with the Arduino Nano.
It's the same as the mini and pro mini, but has the built in USB. That will just make it way easier. The Nano runs at the same 16MHz as the 2560, so if the 2560 has enough HP to run the Arducopter code, it should have more than enough to manage some motors. There's less flash ram to hold the program, but I don't think that will be an issue.
I'll probably also get some of these to start with, since they're available at the same place.
Now, as for communications with the APM, I don't know if it can just be done over serial, or can we do it on the I2C bus? I'm pretty weak in that area.
One of the things to decide early on is if we are going to do this with interrupts or not. Interrupts are probably the easiest way to do it (which is why I wanted this to be stand-alone board). But I believe the 328 in the Nano only has 2 interupts. That means it can only monitor two channels (motor and rotor, or 2 rotors). The Mega has 6 interrupts, but seems like it's really just too big for this project.
I think its best to try and keep it small. Your really don't need to monitor the rotor speed. Just a magnet on the engine or motor with the gear ratio programmed will give you rotor speed. if the rotor mast fails there is not much you can do. Its much better to know that the motor has failed. Auto-rotation as you said before.
I've played around with the eagle tree brushless rpm sensor and did very much like what you're saying. I attached it to an uno and used an interrupt pin to have it increment a counter. I then ran a main loop which counted the number of pings that had been received in the last second and printed them. Then graphed it with excel.
I moved the throttle from 0 ~ 25% ~ 50% ~ 70% then to full and you can see that in the graph. I found the results were a bit bumpy and I didn't think they would be good enough quality to built an external govenor.
I now think the best approach is to actually put custom firmware into an existing ESC. There is actually a little atmel inside of the standard jdrones, 3drobotics, turnigy ESCs (in fact they're all nearly identical designs), there's a discussion on rcGroups about reflashing them with someone's custom firmware and that firmware is available somewhere on the internet..i think it's maybe linked in that discussion.
The ESC knows how fast the engine is going better than an external hall effect sensor I think. The thing that's missing is the ability to communicate between the APM and the ESC...but I think..because the SPI pins for flashing the firmware on the ESC are there, it should be possible to communicate with the APM using the SPI bus.
I know this is all getting quite advanced....
Interesting (and a little disappointing) info Randy. Although I'm not quite sure about your implementation. That sensor isn't exactly what we're talking about here since it attempts to measure the electric pulses going to the motor.
I'm also not sure, is the error in the measured data, or the just the way it printed out?
I'll probably order a Nano anyway just to play with.