A few months ago, I posted some video and pictures of a tilt-rotor quadcopter called iQuad. Since then, I've been working on building a new version of iQuad which is lighter, has a cleaner design, and adds FPV. The new iQuad weighs 1600 grams w/o batteries (down from 2260) thanks to a carbon fiber body and custom-built rotation mechanism and landing legs. My goal for this version is to achieve faster forward flight and eventually add 3D-printed wings to get airplane-like flight characteristics.
The previous iQuad used unmodified arducopter firmware, with the tilt servos being directly controlled by one of the channels on my radio, which limited the tilt angle at which the APM was still able to produce stable flight. For this version, I am going to control the tilt servos directly from the APM, for which I'll need to write some custom firmware. (any help would be appreciated as I am new to arducopter development)
Here are some more photos:
Comments
perhapse you could add rectangular wings to the arms,they are flat when hovering but when the arms fold they become wings as well
Jared, I agree... I think just keeping the body at a slight upward angle might generate some lift during forward flight. I'll give this a try once I make some progress on the sw. I'm also going to try covering the sides with tape to make the aerodynamics a bit cleaner.
My thinking was very similar to what leonard suggested. I just got 3.0.1 running and compiling last night, so I'm going to hack that a little bit to see how it goes. With regards to roll control, I'm still really hopeful that the current setup will work for tilt angles up to 30degrees. Beyond that (and with added wings), I can see how aerodynamic forces may become too strong for that to work. Maybe I'll have to go back to a configuration with four (or at least three) servos. Thanks everyone for all the encouragement... I'll post again when I have progress (or problems that I can't figure out).
have you thought of making the center body aerodynamic , less weight than adding wings but with lift in forwards flight.
Also, if you limit the tilt to 30°, I would just tune the PIDS to worst case scenario, and don't worry about transitioning the gains. In the best-case motor angle, it won't be quite as sharp as it could be, but probably good enough.
Leonard, after having slept on it, I see what you're saying. Makes sense. However, I would limit the tilt angle to a much lower amount. 15-30° max. While you're correct that simply rotating the body frame into motor frame will have the desired effect, you still have to think about the physical aspects. If you consider the case where the motors were tilted 60° or more, the bulk of the true airframe roll control would have to come from motor torque. I just don't think that motor torque can control the roll against aerodynamic forces. We get away with it with multirotors only because the aircraft are fairly well because the frames are "round" around the yaw axis. That's not the case with roll at all.
I think it could still work for an airplane however. If you tilt the motors forward 30°, you can still build up quite a lot of airspeed, at which point you can use the wing control surfaces for stabilization, then *snap* the motors to full forward. So it would be a semi-smooth transition. Take off with motors vertical, tilt them forward 30° until you're going at least 15 m/s, then snap them all the way forward for full airplane mode.
That would be a good idea Nicholas if we weren't also out of Flash RAM.
I'm new to this mulicopter stuff, so I am just getting familiar with the code. I was thinking about the trig calculations mentioned earlier - consuming too much cpu. Has anyone considered using Lookup tables with hash algorithimns to speed up the sine/cosiine calcs? After all how accurate do they need to be: 2, 3, 5 dec pts? The less the faster the lookup could be. The accuracy has to be enough to get to the next calculated point in the next time interval. Take a look at this http://en.wikipedia.org/wiki/Lookup_table . Many, many moons ago I was writing base graphics functions to draw line segments for a Hercules video card on a pc XT. This cpu was too cpu intense to be effective. We then used Look up tables instead of sin/cos functions and freed up massive amounts of CPU.
Hi Ilya,
I have been thinking about this after talking to Rob this morning. This is what I would suggest you do.
Rotate the earth frame body frame translation by the angle of the motors (in pitch). Then rotate the Rate measurements that are used by the rate controllers by the angle of the motors.
Basicly what you are doing is making the frame behave like it is a quad tilted at what ever angle the props are tilted to.
Ok, now the tricky bit.
The problem is the effective frame dimensions change as you tilt the motors. Basicly the frame becomes shorter and shorter as the motors tilt. At the extreme the frame is zero length and the motors become coaxial. So you will need to do a tune at your maximum motor tilt and minimum motor tilt and transition the gain between the two. Hopefully this can be done with a simple trig function or something similar.
As for what version to use. I would suggest using 3.2 (yes, the next one). This will have what we are calling the onion implemented that will make implementing control changes like this MUCH easier. Currently the earth frame body frame transition thing is a bit of a mess.
The more I think about it the more I am thinking this shouldn't be too hard (provided you don't intend to rotate the props by more than about 60 degrees maybe 45 degrees). If you haven't made any progress by the release of 3.2 I should be able to give you a hand to implement what I just suggested.
Hi Ilya, did you have a look at the Quadshot?
http://transition-robotics.com
They are using Paparazzi instead of APM though.
-
1
-
2
-
3
-
4
-
5
of 6 Next