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.
Replies
I was wondering if anyone knows what is the sensor chip which is used in GV1, is it US5881?
https://www.melexis.com/en/product/US5881/Unipolar-Hall-Effect-Swit...
This information will help us use our own controller using the sensor already installed in the heli.
I spent a little time on this on the weekend and sort of got the timing program setup and working. I was playing around with Eagletree magnetic sensors, and sort of got them working, but not quite. I have been doing some research and apparently completely misunderstood how the signal comes out of a hall effect sensor. Hopefully tonight I can apply what I learned and get it working properly.
I assumed the sensor would output 5V on the output when in the presence of the magnet, but apparently the "output" is actually typically a current sink, so one must apply 5V through a resistor to the "output" leg, and then it gets pulled down to 0V in the presence of the mag field.
But I was able to fake the tach signal by using a digital output on the Uno to generate pulses, and then feeding that into the RPM sensor input. It correctly measured the RPM, and printed to serial so I could see it working in the serial monitor. I also had it repeating the input on the built-in LED so you can see it's getting a signal input.
At this point, the first goal will simply be to reliably measure the rotor RPM, and try to feed that back to the APM so the APM can be aware of the rotor RPM, and we can think about error-handling. I would love to have the APM output a spoken "Rotor Speed Low" warning from MP!
At that point, it may be easier to have the APM do the PID and ESC control directly.
I wonder if it would be feasible to run this on a Nano or Mini, and have it simply talking back to the APM via I2C?
An additional thought on all of this is that I spoke with Jani about it, and it may be possible to have this circuit running on the JDrones IO board. So the IO board would be doing the measurement, and sending it to the APM, which controls the ESC. It also opens up the possibility of using the IO Board to control LED lighting in sync with the rotor position.
I've seen it done where LED lighting is used in sync with the rotor position to create some neat effects. One example is to use red and green LED's, facing up at the disk, which pulse on at the right time to create an effect where the rotor is stationary, red on one side, green on the other. Helps for orientation at night.
An additional note: Some of my research indicated that other people had poor results using the EagleTree RPM sensor which attempts to get timing from the motor wires. It's a noisy signal.
Just to update everyone on the latest status of all this:
I have been working on implementing motor speed control directly into the Arducopter code. The intent at this point is to offer a few basic modes which fall well short of built-in speed control, but, get us part of the way there simply:
1) Ch8 Pass-through: This mode, quite simply, takes whatever the APM sees coming in on Ch8, and sends it out to Ch8. The main purpose of this is to allow helis to fly when using CPPM signalling. Otherwise there is no way to get the signal to the ESC. You basically will use this pass your throttle curve directly from the Tx to the ESC. Or, you could use it to simply drive an external governor such as is built into most good ESC's.
2) Input-less Governor Driver: This one only works with an external governor. Basically what it does is feed a setpoint out on Ch8, according to a setpoint. Simple as that. You could set the setpoint at say, 1800, which means a pulsewidth of 1800uS. Your external governor will act upon that just as if it was seeing it direct from the Rx. The key to this function, is that it requires no Tx input. As soon as you arm the motors, and raise the collective pitch just off the bottom, it starts ramping up to the setpoint (default 10 seconds, will be adjustable in the future). Once the setpoint is reached, it will simply hold it there until the collective pitch is on the very bottom.
3) Simple 3-point curve: This is not functional yet, I can't get it working until we have more parameter space. This one is similar to 2), it also operates without a Tx input, but is meant to drive an ESC or Throttle Servo via a simple 3-point curve linked to the collective pitch. You would set up the 3-point using 3 parameters in MP, similar to how you set up the throttle curve on a heli Tx. It's completely dumb. This one will also ramp from 0 to the setpoint once armed, but the setpoint is variable according to the collective pitch and the 3-point curve.
I've also recently purchased an Arduino Uno, which I will be tinkering with to see if I can get an external motor speed governor going. I also just ordered these speed sensors to play with:
http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=...
http://www.hobbyking.com/hobbyking/store/uh_viewItem.asp?idProduct=...
I've started a new code repository here:
https://code.google.com/p/ardu-heli-gov/source/checkout
Pretty much just a placeholder for now, I'm still fleshing it out.
I had another look at this thread to try and figure out where it went off track. I think partially what happened is my interest in designing my own governor system made me overlook the key point that Ron is trying to make. It's not that I disagree, I just didn't see what he was really trying to say. That being that if nothing else, step one in this project should be to get some code going in the APM that will allow us to control a governor-equiped ESC without any external sensors or anything like that.
And I think this is the right approach. We need to figure out the logic to have the APM control a stand alone ESC before we can even think about designing our own governor, because the logic to control my governor will be the same. And I'm sure there will be people out there that would prefer just to stick with their built-in governor rather than going with some open-source thing.
I still do think that an APM controlled governor function could potentially outperform any ESC-native governor. The main reason is the ability to feed-forward load information (collective pitch, etc.) which would then allow us to use softer PI settings to eliminate any potential tail wag that would occur with tight PI controls necessary on a non-load-aware ESC governor. This is exactly what VBAR is doing with their system. That's not a new idea, it's what I had in mind all-along, I just didn't know somebody (Mikado) were doing it already in a FLB controller.
But as I say, the first step is getting the APM code to safely control an external governor ESC. And staying with this simpler level of functionality could always remain an option for anybody who so desires.
So with that being said, let's get on with it and talk about safety, and how we want it to work. Luckily, I think most of this is already figured out in the quad code.
-Absolutely motors_disarmed = low ESC signal
-Setting motors_armed will arm the ESC circuit, but not spin up the motor
-Motors will not spin up until motors_armed==True, AND throttle stick is raised.
-Option for a parameter which is the signal to send to the ESC. 0-1000. Or, Ch7 tuning functionality which slaves the aux input channel to the ESC signal. This allows those of us with "dumb" governors to set rotor speed.
Do we all agree? Anything else?
Now, questions:
After raising the stick, does the throttle go to the setpoint and let the ESC soft-start do it's job? Or ramp it up?
Obviously after disarming, the motor will shut off. But do we shut it off at any other time? After arming, and lifting the throttle, the ESC spins up, but then if you drop it to the bottom again, shut off the motors? I believe not.
And on another note:
I found this chip:
http://www.digikey.ca/product-detail/en/LM2917N-8%2FNOPB/LM2917N-8-...
Which I think will help with the APM governor idea. Converts pulses into voltage. This could be used to send an analog voltage signal into the APM, based on a hall effect sensor pulse output. Analog input is very easy to work with, and if this worked well (clean signal) it would eliminate the need for an Arduino Nano to handle the RPM measurement due to the need for interrupt function.
Oooh, lotta stuff to comment on here.
Why not use Castle/Align? Well, when I bought my Heli, Align didn't have an ESC that would do what I wanted. I knew I wanted to run 8S, and the one they had for the Trex 600 could only do 6S. I ended up getting a Turnigy Super Brain 100A for only $90. It has full logging capabilities to boot. It's actually been pretty good.
The Castle stuff... about twice the price, and frankly I don't believe the quality is there. I know that may sound funny coming from a guy using a Hobby King ESC, but I just saw WAY too many "burst into flames" threads. And Castle doesn't really seem to stand behind their product when that happens either. I just didn't see the value in the Castle stuff.
My current ESC does have a governor mode, but I'm not happy with how it works. I'm actually not sure if they all work this way or not. What it seems to do is simply hold the rotor speed constant. But you don't actually input an RPM and it holds it. What it seems to do is just maintain a constant speed. So for example, I have my throttle channel set at 80%. How fast is that? No idea. But when I change the collective, it maintains whatever RPM that is. That's fine, except that when the battery runs down, that 80% setting also runs down. So the rotor speed sags as the battery runs down.
I want to be able to set a speed, say 1800rpm headspeed, and have it hold it until it can't anymore (due to battery going flat).
Is that how the better ESC's work? Do you input an RPM and they hold it? Or is the speed output sort of arbitrary number, and it drops as the battery goes down?
Another reason for doing this is to control a nitro/gas engine.
As for APM usage, two things. First, I was looking at doing this off-board. On an Arduino Nano. It would only get some reference signals from the APM which it should have no trouble handling. Also, we have just freed up a whole bunch of processor on the APM, it's now running much better. I do almost wonder if the APM could do this all internally.
For sure, if there's a governor available that does the measurement already, and just outputs a PWM signal, then it's easy.
As far as the failsafe is concerned, I do have my receiver hold the throttle up, and set the APM to RTL mode. For me, it's not an issue. I have seperate radio and power batteries, so I don't plug in the power battery until I'm ready to go. If, at that time there's something wrong with the APM or radio and it's sending a throttle signal, the ESC will NOT power up. It won't do anything until it sees a low signal first, then it "arms".
The only risk is if I turn off my radio after the ESC is armed. Why would I do that? Furthermore, the APM would be set to RTL to exactly where it is sitting, assuming home has been set. If home is not set, it won't even go into RTL.
To have the heli hurt me, or fly away would take some seriously weird set of circumstances.
The only risk in my mind is if something should happen while I'm approaching the heli after flying. Then I still have the option run away, likely before it can take off, or if I'm really close, stop the rotor with my foot. (not sure about this, though). I'm already in the practice that when approaching it to disconnect the flight battery, I get my body inside the disk to stop it before it gains any speed while I'm reaching for the Lipo connector.
Hi Robert,
I'm back from my 3 month trip so starting to get re-engaged....
I'm never one to reinvent the wheel and having used the governor's built into nearly all the good ESC's on the market can I ask have you used them (Align and Castle) and why wouldn't we want to use them? They are already very well thought out - although maybe not perfect. It seems to me the APM is already at a fairly high utilization for stabilization and autopilot functions and is it a good idea to add yet more functionality to an already complex component that still has a ways to go to be fully debugged with existing functionality?
Ok, I know, it's like throwing a wet blanket on your project - not intention to do that - but you should at least ask yourself why you shouldn't use the governor's built into the ships ESC and whether there truly is sufficient compute power and memory in the APM to take that on.
ALl the best,
Ron
Well i went ahead and had a go at reading the digital on the AN0 pin and looking at it in the serial monitor.
The low is 44 and the high is 1041. Its attached to the engine, but removed the head, piston and liner so it made it easier to rotate. So if anyone would like to help me out with the code, then i would be gratefull :)
Been Googling and reading about Schmitt triggers and Arduino analog AN pins. I have tested the Sensor in the pic and it reads 0 Volt until it sees the the magnet and then rises to 5 volt, (supply voltage is at 5volt).
Anyway of programming a Schmitt trigger?
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....
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.
-
1
-
2
of 2 Next