VTOL mixer for tiltrotor / vectored thrust

[maxvtol]

I need a little help refining my onboard mixer for my vtol project.

I would like to speed thing up a bit by having a separate processor capture 8 PWM signals and sending them to the mixing microcontroller via I2C.

The first 3 channels would be coming from gyros, so the pulses will not be front to back as they do coming out of the receiver. The 4th channel is the throttle and I need it as quickly as the first 3.

The next 4 channels would be for tilt and gyro gains, so even if I skipped a frame, it wouldn’t hurt, although I would like as smooth a motion as possible. The pulses may or may not come out back to front sequentially from the receiver but they will never overlap.

Got a couple of questions.

1) What’s the best, least expensive way to capture these pulses? I would like to maintain about 1 usec resolution, but I could probably live with 2 or 3.

2) Is I2C the best way to go about this?

I know what I want, I just don’t know how to do it. I’ll have to explain this someone who can build PC boards, so if you could explain it to me in noob terms, I would appreciate it.

If you want more info on my project, check out my website www.vertiplane.com (http://www.vertiplane.com)

[jeffs555]

1)I did a ccpm+revo mixer that would take 6 overlaping or out of sequence inputs and resolve to less than 1us using a 20mHz AVR(should work just as well with 8 inputs). The trick was to have all the inputs on a single port, and have a single interrupt for all inputs that triggered when any of the inputs changed. The only thing the interrupt did was to read the current state of the input port and save it in a queue along with the current value of a 16 bit timer. Background processing routines had plenty of time to pull the values off the queue and determine the input pulse widths.

2)If you have to use two processors, SPI is a better protocol than I2C when you have one dedicated master and one dedicated slave.

I don't know how complex your mixing computations will be, but you might be able to do everything with a single processor. The 20mS frame rate gives a lot of time for computation. Once you complete the computation, you can fire all the servo pulses at the same time, so the output phase won't take more than 2mS.

[maxvtol]

jeffs555,
Thanks for your reply.

1) How did you get all the pulses on one port? Would it be possible that the any edge of the pulse could happen at the same time and mess up your sequence?

Thanks for the info.

[AndyKunz]

Joe,

A port is 8/16/32 bits wide. The processors have an "interrupt on change" feature that lets you capture the whole port any time ANY pin changes state.

The software manages the state changes so that if multiple pins change at the same time, you still get all the info because you read the whole port at one time.

For example, let's pretend you have a 4-pin port (for sake of typing). It starts out at time T=0 with all pins low (no signal from transmitter).

T=0 0000

After a while, the signals start coming in

T=1000 1000

This causes an interrupt. The micro saves the value of a timer. About 1.5ms later (T=2500), the receiver starts outputting the next channel

t=2500 0100

Note that two pins changed state. Channel 1 went off, and channel 2 came on (this is how PPM transmission works). The micro saw the change because of the interrupt, stored t=2500. After it exits the interrupt it sees that there is a delta to consider. Doing a little bit-wise logic and working with the timers, it understands that channel[1] = 1500us.

Another 1ms later, channel 2 ends and channel 3 starts.

T=3500 0010

The interrupt causes this data to be stored then exits. The main loop notices the new entry and figures out that channel[2] = 1000us.

Channel 4 is actually coming from a gyro, so it is asynchronous with the other channels. 30us after channel 3 starts, channel 4 starts its arrival.

T=3530 0011

Ah, only 1 bit has changed! The ISR dutifully stores the new port value and time and exist. The main loop notices the new entry and sees that channel 3 has not ended, but channel 4 has started. The next interrupt will be interesting...

T=4750 0001

ISR occurs, stores the port value and timer, exits. The main loop sees the new entry, does its bitwise math and figures out that channel[3] = 4750-3500 = 1250us.

After a while, the gyro finishes its signal and we get interrupted for

T=5000 0000

This causes the main loop to figure out that channel[4] = 5000-3530 = 1470.

About 17ms after the first channel 1 pulse started, another comes in.

T=17666 1001

The gyro and channel 1 ended up starting at exactly the same time. The main loop will have no trouble with this because it can easily see that two pins are changed and handle it.

This is exactly how I implemented it in a PIC for one customer. Works great (I did 5 channels on PORTB - INT + RB4-7). BTW, the Atmel digital I/O peripheral is really nice.

Andy

[maxvtol]

Andy,

WOW!

Think I'll work on fuselage mold today.

[Darquewing]

Though, a programmer and not a true "engineer" yet by any means, I am looking at a Parallax "Propreller" chip for doing the mixing on my VTOL project. It runs 8 "cogs" which are 32-bit processers in parallel. Each has a small amount of individual memory and a slightly larger chunk of shared RAM. They run up to 40 pins and should do the trick for this kind of thing I think. Well, I hope.

As far as cost, they don't look too bad as far as Microcontrollers go. But they have their own programming language, and also can use Assembly.

[Daniel Wee]

Gyro aside, the good thing about the radio servo PWM signals is that they are sequential and the channels will not overlap in terms of pulse edges. One easy way, therefore, to do this would be to employ an edge driven interrupt that interrupts at both the rising and falling edge of the pulse. I know some PICs have this capture feature - which will also capture the timer count when the interrupt occurs. Then it's a simple matter of figuring out if it's a rising or falling edge by reading the port pin during the interrupt. That way you can easily calculate the pulse width from the difference of the timer counts. Just make sure you have enough timer counts to last more than the average 2ms max pulse width, and that you have enough resolution to resolve sufficiently the pulse. Since this is interrupt driven, it's pretty straightforward.

Daniel

[AndyKunz]

Gyro aside, the good thing about the radio servo PWM signals is that they are sequential and the channels will not overlap in terms of pulse edges.

Not necessarily. Some digital receivers will start all outputs at the same time.

Your method works great for measuring one or two channels (with a micro with one or two CCP modules).

The method I mentioned above is more general. It will capture as many channels as you can handle interrupts for (preferably on a single port), which is why I used PORTB on the 5-channel device I did. Some newer PIC generate IOC on more pins. The Atmel AT91SAM7 parts I use will do it for 31 pins at a time. With either type, though, the concept is basically the same.

I provided the method I did because it supports asynchronous devices as well as sequential ones. The bitwise math is extremely simple. Just provide a queue for the ISR to stuff deltas in (timer & new bit pattern data).

Andy

[jeffs555]

Though, a programmer and not a true "engineer" yet by any means, I am looking at a Parallax "Propreller" chip for doing the mixing on my VTOL project. It runs 8 "cogs" which are 32-bit processers in parallel. Each has a small amount of individual memory and a slightly larger chunk of shared RAM. They run up to 40 pins and should do the trick for this kind of thing I think. Well, I hope.

Darquewing,
That is a very interesting looking chip, and the prices seem very reasonable. However, I see that a C compiler won't be available until the end of 2007 and will be $200. I would find it hard to start on a project that complicated without having a C compiler.

Have you looked at the ARM7 based microcontrollers? It seems like every chip maker has one, and they are about half the price of the Parallax. The price difference wouldn't matter for a "one of" but for a production item it might. The ARM7's run 50-60 mips or more, so slower than the Parallax, but the big advantage is the availability of the free open source GCC C compiler.

Jeff

[Arthur P.]

One way to get all the pulses on one pin is by modding the Rx to export the PPM signal from the RX stage before it has been demultiplexed to the different channels. See for example: http://www.davehylands.com/Robotics/RC-Input/

This actually will allow you to use for example a 3 channel receiver as a 9 channel receiver if you have a 9 channel transmitter. This is how they did it for the www.mikrokopter.de project. The UAVP project does take the separate PWM channels, but somehow only measures the uneven ones and calculates the value of the even ones (saves on the ports needed). If you can read german you should be able to figure it out for both. They are working on translating the manuals, so if you don't read german you'll need a bit of patience. The sourcecode for both is also available there for downloading. In fact if you do a google search for ppm decoding you will find more examples, including some which are very minimalistic and just intended for glitch suppession (http://homepages.paradise.net.nz/bhabbott/decoder.html), or a very simple partially hardware based decoder (http://www.kronosrobotics.com/an139/DAN139.shtml)

For mikrokopter they have used a specially designed PCB. However, if you look around a bit you can probably get a microcontroler with everything you need to handle the different inputs. As you intent is to mix the control signals with avionic sensors, you probably are not too concerned about size, with 4x4 inch footprint possibly still being acceptable ? If so then for example this should fit into most mid-sized planes or helis: http://www.futurlec.com/ARM7024_Controller.shtml It provides an ARM7 processor, 12 channels of 10bit ADC, I2C, serial port, etc, etc. You probably would want to mount the different gyros on a prototyping daughterboard. There are free C compilers available. Programming is done over the serial port. And price seems quite reasonable and quite competative with the UAVP and Mikrokopter PCB which have less ports. If you do want a small footprint then something like this should be usable: http://www.futurlec.com/ET-ARM_Stamp.shtml or maybe a Basic-Stamp might even be usable.

[maxvtol]

Arthur,
Thanks for the links. Actually Devantech's SD 21 servo controller (1.75"x3.25")with a BasicX 24 stamp can read the PPM signal with no overhead (they claim) using interrupts, mix it and send it to 21 servos at 16 bit resolution and 20ms refresh rate. This is what I am using now, except I am reading PWM's because I am need the gyros between the Rx and stamp. It works, but the servo motion is a little jerky because the stamp has to wait for the pulses. I could go to analog gyros, which the stamp could read every loop without waiting, and use the PPM signal. But electronics isn't my strong point. Unless I can plug it in and use some simple language to make work, I'll just get someone who knows what there doing.

I haven't done this much programming since the days of COBOL and FORTRAN on punch cards!!

[Arthur P.]

I don't fully understand your layout. Maybe you can post some pics of your current setup, and some diagrams.

I-ve also sent Djago an email to alert him to this thread. He has developed his own tricopter which I-ve seen flying very stably. I think he's on a well earned vacation, but he should be back within 1 or 2 weeks.

[maxvtol]

I have the aluminum test rig in a state of disassembly, so I mainly just have parts laying around now. I hope to have the fiberglass model ready for transition flight in a couple of months. Here is an old picture with my custom 20x8 blades (which didn't work).
Test rig w/ custom blades (http://www.vertiplane.com/files/props003.jpg)

Some videos
Nov 2006 testing (http://www.youtube.com/watch?v=YcMP-kMy6xo)

Early 2007 testing (http://www.youtube.com/watch?v=7iGK_gr4HP0)

More info at www.vertiplane.com (http://www.vertiplane.com)

I'm thinking of starting a builder's blog now that my fiberglass materials are in. I also hope to bring the weight of the electronics down from about 7 ounces to about 1 ounce.

[maxvtol]

I contacted Devantech about why my servos were jittering on the SD 21, and they said that they had problems with the PIC 2220 chip and went to the PIC 2240 chip on later models. This is what started my search for a better system in the first place. I am pursuing other avenues, but I had considered getting another SD 21 just to keep things moving. Tonight I did some testing.

Arthur P,
I noticed on your other threads you were looking for sensors with I2c. After doing a little refining of my code, I found sending 8 PWM signals from my BasicX 24p stamp to my Devantech SD 21 took about 20msec over I2c! I was trying to speed things up by shortening the PWM capture and refining the mixing math. But it looks like the I2c is the short coming. No wonder my servo motion is so jerky.

I know the hard core programmers have better ways of doing things, but the Pololu chip looked interesting. Would anybody have an idea if comunicating with this serially would be faster than I2c? My guess is it couldn't be any slower.
Pololu 16 channel servo controller (http://www.pololu.com/products/pololu/0240/guide.pdf)

I actually need 12 channels to fly with my current setup. Maybe up to 16 in the near future.

Thanks for all the input.

[jeffs555]

What is your I2C clock rate? Sending 16 bits of data plus an address for each channel would still be under 3mS for 8 channels at 100kHz.

PS Not at all familiar with BasicX 24P, but it doesn't appear to have hardware I2C. If that is so, your processor will be spending a lot of time in the software I2C routines written in basic. Even though the Pololu only does 56k baud, if you can use a hardware serial port, it will probably be faster. Using software I2C, you are probably spending a lot more time in the I2C routines than you would just outputing the servo pulses direct from the BasicX.

[maxvtol]

What is your I2C clock rate? Sending 16 bits of data plus an address for each channel would still be under 3mS for 8 channels at 100kHz.
jeffs555,
Keep in mind, I don't understand alot about the stamp. But I know it doesn't have an I2c command. I'm using about 12 pin commands setting the clock and data pins high and low to start and stop, then using a ShiftOut command to send the data. The I2c procedure was written by Gerald Coe, the support guy for the SD21.
Here are the specs I could find in the manual.

------
Call ShiftOut(DataPin, ClockPin, NumberOfBits, Operand)

This function shifts out up to 8 bits of data from Operand through the DataPin output. The operating system automatically clocks out each bit by using the specified ClockPin. In order to be compatible with I2C devices, the bit rate is less than 400 kHz. Bit ordering is MS bit first, LS bit last. Before calling ShiftOut, the clock pin must first be set to the proper level (either high or low).
------

Also, here is the website. BasicX 24p specs (http://basicx.com/Products/BX-24/bx24specs.htm)

[maxvtol]

Using software I2C, you are probably spending a lot more time in the I2C routines than you would just outputing the servo pulses direct from the BasicX.

Thanks jeffs555. You were right. Using the PulseOut command on the stamp was 11 msec and the I2c procedure to the SD21 controller was about 25 msec.

I'm going to try using the PPM signal from a Berg 4L Rx with the InputCapture command on the stamp. If that doesn't add much overhead, and with a few tweaks to the mixing math (about 15msec), I might be able to get the refresh rate to about 25 to 30 msec (about 20 msec better than it is now)

I'll have to add analog gyros. But take away the SD21 controller and I'll be well under 1 ounce.

I'll update my progress once the Berg 4L comes in.

[jeffs555]

You are really at a great disadvantage using the BasicX as opposed to "C" or assembler, or even a Basic compiler. The PulseOut command appears to be a software timing loop, so the processor is tied up all the time you are outputting the pulses. With 8 ports, you could be wasting 75% of the processor time just waiting in the PulseOut routine.

Don't know the speed of a "For" loop, but you would be better off using that because you could output all the servo pulses in 2mS. What you would do is set all the servo outputs high, then wait in a "For" loop until the shortest pulse is sent, then set that pin low. Then go into a "For" loop again until time for the next servo pulse to end, and set its pin low. Continue til you have set all the servo outputs low. You would have to time a long "For" loop, then calculate to see how long it takes for each count in the loop.

[maxvtol]

You are really at a great disadvantage using the BasicX as opposed to "C" or assembler, or even a Basic compiler.
I know.

The for next loop is 120usec, so that wouldn't work on this chip. It can run 2 PWM channels in the background using Timer1, but it looks to be restriced to 2 pins, then I couldn't capture the PPM signals.

Is there a free Basic compiler that work on a more powerful chip? I wouldn't know where to start.

I was just looking into the OOPic chip.

[jeffs555]

Don't know anything about them, but this place has 60mHz ARM7 modules that program in Basic. This would give you more horsepower while still using the Basic language. http://www.coridiumcorp.com/Products.php

Not sure if PulseIn and PulseOut commands work like BasicX but it does have them.
http://www.coridiumcorp.com/ARMhelp/index.htm

It should also have hardware I2C.

PS Have been browsing the Coridium site, and this appears to be the equivalent to the BasicX 24p except with a 32bit 60mhz ARM7. Also, the Basic is compiled so makes it much faster than interpreted Basic. It claims 10 million lines of code/sec as opposed to the BasicX which claims 83 thousand lines/sec.

[Arthur P.]

Why do you want to mix the gyro's. Why not read the gyro values and mix in firmware, i.e. within your microcontroler.

I think a Basic stamp won't have the oomph. In fact if you read up on the different quadrotors, even witout tilt, if you want to really integrate everything, you probably do want to go to Amr7 or XScale level processors to get the speed and calculating capacity.

Even then offloading as much as you can to peripheral intelligence is always useful. For example for my own design of a quadrotor I've ordere the MLX90609-R2 300d/sec gyros from Sparkfun which provide the gyro and temp values on the I2C or SPI bus, so no ADC or programming overhead on the main processor needed to convert.

Have you really done some searching for tricopters, quadrotors, quadrocopters, hexacopers, and octocopters? Loads of info on both the hardware, the microcontrolers used, and loads of source code for the systems out there both in thesis papers and on different sites (and yes most of the current open source quadrotor development sites are in German, but not all).

Personally I would suggest that you develop this thing in a more stepwise fashion. You're now trying to solve too many problems at once. I.e. stable hover AND tiltrotor control AND conversion to forward flight.

For stable hover your control will have to be either through variable pitch (unusual on current RC quadrotors), or through very direct motor speed control (using high speed ESCs either over PWM, or modified to be controled over I2C). I haven't read all the details, but looking at your prop sizes early on you are probably using larger motors than most current quadrotors. So that's already going to be reinventing the wheel even if you develop it without the tiltrotor capability. And for hover of a quad that is not needed.

In stable forward flight the controls would have to be mainly through rudder, elevator and flaperon and not through variable motor speed. All motors would be expected to run under throttle control and not be influenced by e.g. gyro inputs. The gyro inputs should probably influence the normal control surfaces. So we're talking about a very different configuration program wise.

Once you've managed stable hover and flight under quadrotor control, and have managed stable forward flight under normal propulsion, the final step would be very carefully introducing tiltrotor capability. This will be complex because you have to switch OFF the variable motor speed at some point during the tilt and got to all four motors running at similar speeds. But finding the sweet spot for the pitch is going to be an interesting challenge. I actually expect that this shouldn't be a hard switch but a gradual switch depending upon the amount of tilt and forward speed. In the oposite direction, going back from forward speed to hover, the same would apply, but the switchoverpoint / curve may be different.

All in all you are talking about probably 2x the amount of programming needed for a "simple" flight avionics system for a quadrotor and normal plane combinded because of the very complex transition phase. The first and second part of the "learning to fly" are probably easier to accomplish as a lot is available for either. The last is going to be the bigger headache but will very much depend upon sensing the motor tilt angles and airspeed and adjusting the level of mixing the two flight control modes according (assuming gradual switchover).

[maxvtol]

Arthur P.
It's obvious that your very knowledgeable and I hope for your continued advice. I have definitely used much of the information on quadrotors. I believe we're on the same page as what needs to be done. Even though my test rig resembles most quadrotors, the next phase is fuselage with wings (as I am writing this, my fiberglass fuselage mold is curing. The wings are next.)

I already have the mixing math written to go from hover to cruise, and it works fine on the bench. The phasing of the controls really isn't that difficult. I'm using the motor tilt control as a multiplier (from 1 to 0 on the hover controls and 0 to 1 on the cruise controls). The roll gyro will always control the roll controls, the pitch gyro the pitch controls, etc. The best curve may not be linear, but I plan on giving the gyros some authority up to cruise flight by using the tilt multiplier (or tilt curve). And yes, I plan on tweaking the control curves at different phases of flight before a complete transition from hover to cruise and back.

Variable pitch props are the next item to tackle. They're going to be a bit more complex and expensive. I want to transition to forward flight first, so I am taking this step by step. As you may have noticed on my videos, I am hovering with 16x10 blades (I realize not as nearly as good as your quadrotors), but I believe I can do better with improved electronics (and practice). I had to go to larger blades because of the disk masking by the wings made the smaller blades less stable. Also, these blades will allow me to cruise at 47mph after transition to forward flight. I could probably approach 70mph or more with these blades and motors. The wings will be optimized for cruise flight, though.

Just so you know, this won't be another quadrotor. My engineering background is mechanical, not electrical. I know the mechanical side will work out. I just need help with the electronics.

[maxvtol]

Don't know the speed of a "For" loop, but you would be better off using that because you could output all the servo pulses in 2mS. What you would do is set all the servo outputs high, then wait in a "For" loop until the shortest pulse is sent, then set that pin low. Then go into a "For" loop again until time for the next servo pulse to end, and set its pin low. Continue til you have set all the servo outputs low. You would have to time a long "For" loop, then calculate to see how long it takes for each count in the loop.

jeffs555,
Could I get the code for the loop? Wulffy has a Coridium chip that uses the ARM7 chip at 60mhz and he can only get about 90 to 95% accuracy with that method. That wouldn't be close enough for my application.

[Arthur P.]

Instead of repeatedly doing the "create PWM pulse for servo channel x" routine, why not offload part of that to a servo controler. You only set the servo value if it changes by writing a serial byte. The servo controler does the PWM loop to that value as long as it doesn't change. This serial one is very small (about the size of a quarter):
Serial:
* http://www.robotshop.ca/home/products/robot-parts/electronics/servo-controllers/pololu-micro-serial-servo-controller.html
Or over I2C:
* http://www.min.at/prinz/oe1rib/I2C-Servo/#Pictures
* http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=42

Alternatively, but more expensive, modify each of your servos to be addressable over I2C:
* http://www.openservo.com/moin.cgi/DocAboutOpenServo

There's a lot more servo controlers out there, varying in price and size.

[AndyKunz]

Arthur,

That's exactly how I'm doing it for maxvtol's thing. The servo pulses are both measured and generated in an FPGA, with resolution set by the micro via a clock input (it can go to hundreds of MHz so it can be quite accurate). The micro asks for status and commands pulses using a SPI bus (which can also run to about 120MHz). The micro is used only for doing calculations, and if he has any analog inputs he can read them there. I have it set up for 32 inputs and 32 outputs right now but they can be expanded further if necessary.

Andy

[jeffs555]

Could I get the code for the loop? Wulffy has a Coridium chip that uses the ARM7 chip at 60mhz and he can only get about 90 to 95% accuracy with that method. That wouldn't be close enough for my application.

That method would depend on the speed of the For Next loop, and also on the interrupts. If the For Next loop is short enough to get the resolution you need, the variation is most likely coming from interrupt routines happening while you are outputing the pulses. You could synchronize the outputs so they happen during the PPM sync period, and disable interrupts while in the loop. However, disabling interrupts that long may affect other things like timers and serial communication.

If you can do the low level programming of interrupts(ie programming in assembler), it takes very little processor time to do the pulse inputs and outputs. You could save the cost, size and weight of adding a dedicated pulse I/O chip. However, if you have to use a Basic Stamp type chip it would be best to find one with hardware serial communication and use another chip to offload the I/O.

[maxvtol]

Does anyone know any problems I might run into if I run my ESC's at 125hz refresh rate? I have tested them to 250hz for a minute or so and they seemed to be happy. The only thing I could get out of Electrify was that the operating frequency is 8.5khz?

I've re-assembled my test rig with the smallest fastest code I could come up with on the Basicx stamp, and ditched the SD-21 controller. I now have a 40-45hz refresh rate instead of the 18-20hz I had before. I won't be able to use this for transition flight because I had to remove the tilt channel and some cruise flight code to get the stamp to run this fast. It flies pretty well even in light winds. With a faster refresh rate, I should be able to fly at the grass farm with the other guys where the winds tend to be a little stronger.

I plan on toying around with some electronics to get my 125hz rate, most all of it from the info you guys have contributed, so THANK YOU VERY MUCH! I'll need some more help, so I'll post more later.

Here is my latest flight. Hover with electric blades (http://www.youtube.com/watch?v=wz3-SeviMZE)

[maxvtol]

Thought I might try asking one more time before flight trials.

Would there be any problems with updating an ESC at 6 to 8 msec if it seems to work at that rate? The main reason I ask is the GY401 gyro I have mentioned not to use it on servos that couldn't handle the frequency, or the gyro would burn the servos up. Didn't know if that applies to ESC's too.

Bench testing is complete, and I'll make an enclosure for the electronics. Weight for the control will probably end up about 3.5 to 4 oz (I think 3oz of it is solder), about 3 oz lighter that my previous setup.

I ended up using the Coridium ARMmite and Devantech SD-20 servo controller with Melixis gyros and Berg 4L Rx. The ARMmite is so fast, I'm using the Do Loop to capture the PPM signal from the Berg 4L and doing the mixing math in between ONE of the pulses, with plenty of time to spare. 8 channels are being updated with gyro inputs every 6 to 8msec, and info from the Tx updates all 16 channels every 25msec.

I have all the channels and speed I need to use this setup for my transition to forward flight. I should be able to make some test flights on the aluminum test rig within the week. And work continues on the fiberglass model.

Thanks Jeff and Andy and everyone for the help.

[jeffs555]

Glad to see that the ARMmite worked out. I think Coridium needs to do some better advertising as I don't see too much on the internet about it. Just going by the specs, it knocks the socks off the Basic Stamp at comparable prices.

As for the update rate to the ESC, I wouldn't think it would hurt anything. If your ESC's will accept the higher rate it should be OK.

[maxvtol]

Thanks Jeff, I really had no idea about how esc's work. I expect to do some flying this weekend with the new setup.

The Coridium is wicked fast. I could really have done all the servo controls with the Do Loops you mentioned, but just in case of loss of signal, I put an additional servo controller on there.

I'll give an update on the setup after I test it.

Thanks again.

[maxvtol]

Version 2 mixer flies!!

After much bench testing of the hardware and software, it finally flies. Even though it concludes with a crash, I would consider it mostly a success. The gyros work great, and so does the software. Flight in moderate winds was no problem. I added an IR sensor to this version, but didn't use it the whole flight, just on and off to test.

From what I can tell about the crash, I think an ESC got overheated and quit. Nothing acted funny before, and everything seems to work after the crash. I'll do more extensive testing before the next flight.

The IR sensor seems to work, but it's critical to get it level on level ground before turning it on in the air. I'll have to come up with a way to easily trim it in flight. Since it really didn't seem to add to the hovering stability, I'll probably just use it to get out of an unusual attitude in an emergency.

Version 2 mixer, IR sensor test flight (http://www.youtube.com/watch?v=GLMoKYmFsLY)

[shanghai_fool]

Just some thoughts on your digital servo BEC problem on your other thread.

It looks like you are using them to tilt the motors. If not, then disregard this post.
From the photos, the motors look like they are mounted from the back and your servos are trying to swing them fore and aft. Try this with a (wood) baseball bat. Hold it at one end and try swinging it and notice how much power it takes not only to move it, but also to stop moving it. This will create a lot of oscillation for the servos as they are tring to move it and it will overshppt so they move it back and so on.
Now hold the bat at its cg point near the middle and do the same thing. It will be much easier. You are halving the mass you are trying to move/stop so its less load.

In flight, this is happenning also but in much smaller increments and the digital servos are drawing lots of current trying to make small changes. I understand that the digital servos at fast rep rates will be the most stable but at a heavy price. You can reduce this up to 50% by moving the axis to the cg but it still will fight the overshoot.

Analog servos do not have as much problem as they slow down as they approach the selected position so don't have as much overshoot. A little slower but not as much oscillation.

[maxvtol]

Donald,

I am tilting the motors for stability in hover, so your spot on. I tried it just using the motor speed for hover control, and it's not as stable.

When I first designed the model, I had to dig out the old engineering books to get the numbers for torque to move a spinning motor and prop at the end of my motor mount. I think the number was between 300 and 400oz-in to rotate it as fast as I thought I needed.

That was the first criteria. The second was, I needed minimum 110 degrees of travel, prefferably 120 degrees, since I wanted to rotate 90 degrees and also have plenty of travel for hover control.

The only thing that fit the bill was the digital servo.

And for stability, as you mentioned in your thread, the CG needs to be in the center of the motors in hover, but forward of the neutral point in cruise. That, and needing prop clearance from the wings, is why they have to be that far out on the motor mount.

All the above was decided on before I bought the servos. A couple of things makes me want to keep these servos for transition flight:
Precision - even small deflections of the prop in cruise flight will make a big difference.
Holding power - the amount force it will take to hold the motor in place will be substantial.

The spikes and overshoot you mentioned concern me, but if I can make these work, I want to give it every chance.

[shanghai_fool]

Well I certainly can't fault the design as your video shows great stability in hover. I have the same problems with prop clearance because of the forward swept wing and if I add the dihedral, it just compounds. I will need a swashplate type of bearing on the servo tray, I think.

I think adding surge protection resistor may solve your BEC problem.