Adapting the coaxial copter mode to a contrarotating dual fan setup

ArduCopter
1

I’m designing a drone that uses two contra rotating (rim driven but that’s probably irrelevant) fans in a single duct; with (current planned) 3 ‘flaps’, arranged 120° around the exit of the duct, that rotate into the duct, presenting the leading edge of a low reynolds, high lift airfoil profile into the lift stream to provide lateral control authority. Combinations of amounts of pairs of ‘flaps’ give 360° translation control; with the redirected airstream providing small translation authority at small openings and the resultant rotation around the CoG and or Col, causing the main lift stream to vector for larger, faster translations.

All of which is not for discussion here, but to ask if there is an experienced copter (preferably: coaxial) setter-upper and pilot, that would talk me through (or talk me out of) trying to use the four swashplate servo controls from a coaxial copter (plus speed control of two motors) to control two motors and three ‘flaps’.?

Am I completely off my trolley?

Cheers, Buk

2

Yes. It seems I am of my trolley as I just got pointed at (by someone on a completely different site) to SingleCopter and CoaxCopter — Copter documentation.

The coaxcopter mode (as opposed to the coaxial mode of twin helipcopter)whatever, seems to give me (almost) exactly what I need.

Thanks for all the help I didn’t get here.

3

Occasionally, some posts do get missed by relevant people. Sometimes tagging posts with vehicle-related tags helps, but the situation here was that you were not sure which vehicle names to use, I understand.

I have built some machines like the one you seem to be working with, and I am now also in the process of rewriting the frame code for coax-copters (and single-copters too), so probably I can offer some help to your project. You may probably find this youtube channel useful (https://www.youtube.com/channel/UC-3IBECWHPQS8kWOrreJjsg/, mostly about coax copters, but with some other machine types too).

4

Thanks Max. I enjoyed the SN1 vids. Looks to be fun. Also reassuring that coaxcopter is in active development. I’m a ways short of being ready to actually put mine together, I’ve only just started looking a what electronics I going to need. I’d always assumed (as I have no RC experience or knowledge) that it would involve starting from scratch with an arduino or raspberry pi. It is really nice to know that ArdiCopter and related hardware offers a near plug and play solution.

Reading the setup notes, it say’s the the FC should be mounted horizontally and close to the CoG. How much trouble am I in as the physical lay out of what I’m looking at would require it to be mounted vertically and roughly 50mm away from the central axis?

Think of a dronut size and shaped thing (without the $10k price tag) with the two fans inside a duct one above the other and everything else distributed inside the walls of the duct.

A hiding to nothing or a plausible scenario?
Also, is any particular flavor of FC a best starting point?

Cheers, Buk

5

the FC should be mounted horizontally and close to the CoG

It’s rather “the default orientation is horizontal”, and if it is not, AHRS_ORIENTATION is the parameter you need to adjust. In all of my coax builds, the FCs are mounted vertically. It seems that at least in the prototyping phase, the best position is on the back wall of the machine, so that you can do the easy line-of-sight piloting and see all the status LEDs. It appears that in some FCs with an integrated compass, that compass would feel worse if the FC is not in the default horizontal orientation, but you can always use an external one coming with a GPS module - or even no compass at all, and manual modes will still be OK.

The CG offsets can be set up with INS_POSn_{X,Y,Z}, where the small n is the number of an IMU (just 1 if the flight controller does not have redundant IMUs). It will still work in the basic scenarios if you don’t, but altitude hold may get confused, so in the case of a reasonably large coax, it’s better to set it correctly.

The drawback of a non-CG location will then be increased measured vibrations along the axis which is far from CG and less sharp tuning in that axis. In a coax, a non-CG location for the entire FC would rather mean it’s above the motors, and the battery is even higher, which is definitely not a dronut design. In a big costly project I would probably use an external IMU chip positioned close to where the CG really is, but I don’t do big costly projects. So, in short,

to be mounted vertically and roughly 50mm away from the central axis

is OK.

Think of a dronut size and shaped thing (without the $10k price tag) with the two fans inside a duct one above the other and everything else distributed inside the walls of the duct.

Exactly the way I did things before SN1, and this works. There are aerodynamic quirks to it, such as the inflow variation of the Coanda effect, which wants to re-orient the machine back to vertical. Unless you have a better airflow simulation capabilities than I am, and unless you know what to do, you would need really sizable flaps. You may see the flap sizes in latest CX7 and SN1 videos - even these are not quite enough (probably for slightly different reasons though).

is any particular flavor of FC a best starting point?

I would say “go H743”. CX7 uses one of Matek H743 wing controllers, which is small enough and does a very good job, and its PDB will have a good choice of power for your servos.

For smaller builds, any Ardupilot-capable AIO with enough current and enough servo pins would also do. SN1 flies FlywooF745-AIO, but it’s explicitly not the best choice, because the 2nd revision you can buy lacks servo outputs, and I had to play with pad assignments and sacrifice a UART for a pair of servo outputs. If the machine is really small, some whoop boards, such as FlywooF405S-AIO, can do the trick, and this one has a plenty of pads for everything. These are not H743, however, so you might (eventually) feel constrained on flash size, RAM and CPU speed.

(I assume you are not afraid of soldering. For small machines, you kind of have to, because connectors etc become a huge overhead)

6

Thanks. Not yet sure what H743 means, but I’m pretty certain I will be going that way.

With regard to flaps. The concept is (was) to have sections of the wall of the duct, at the exit, smooth to the output stream when closed, and hinging from the trailing edge of the flat-bottom hi lift, low Reynolds airfoil profile (eg, Selig S7055), into the airstream, opening a outlet in the outer wall of the duct.

the idea is that in hover, for small translations, small opening of the lip foils, will give low AoA and exert a gentle pull in the direction of the lip foil away from the axis, with necessarily tipping the vertical axis much. Just for low speed translation. For higher speed translations, the lip opens further into the stream at a greater AoA and rotates the bottom edge at that point around the CoG to redirect the main lift stream (*1). There were to be 3 such lips 20mm deep, 70mm arcs around the 90mm Ø ID duct ay 120° spacing. Pairs of ducts used in convert to control the direction of translation through 360°. But from what I read, there are only two independent channels for flaps, so this idea may be a bust.

*1 It also just this minute dawned on me that my low speed maneuvering method would act in the opposite direction to the large opening. Can’t believe I did see that before now. Seems I going to have to re-think the flaps issue.

Are your flaps airfoils, or just flat plates?

7

what H743 means

The STM32 CPU on the flight controller. Typically if you look up the information about the flight controller, which CPU it is based upon, is nearly the first thing they say.

there are only two independent channels for flaps

There is a concept in Ardupilot called the “frame”, which is the actual code that translates the autopilot’s desire of RPY moment changes (and also thrust) to motors and servos, and which linearizes the control laws to the extent possible. For the coax-copter, which was developed quite early and then was left essentially untouched, the only supported frame configuration is a “roll flap” and a “pitch flap”. Similarly, for the single-copter the only supported frame configuration is four flaps arranged in a “+”.

This is not a fundamental limitation though, and I am (too slowly) working on a rewrite of these frames, which will among everything else add support for more elaborate types (such as three flaps for a single copter). Actually, SN1 already has a different layout: it has two flaps, but they are arranged in an X. Not that it is better than the standard + arrangement, but there was a reason behind, and I am planning to make this available as an option.

That said - if I got your design right, essentially flaps on the duct that only open inside - you can model this with the existing code (which has two fundamentally different outputs but four individually configurable servo channels) and carefully set servo trims, so that each physical flap only responds to half of the range of the logical flap. (I know this because there once was a bug in servo outputs once, that kind of resulted in the same behavior).

Are your flaps airfoils, or just flat plates?

I used flat plates up to CX7, then tested out airfoils on the single-copter, then transitioned to airfoils also on SN1. They do involve more manufacturing efforts, and I am not sure I see any benefit from better aerodynamics, but airfoil flaps actually appear to be sturdier because of that heavy-end part.

And anyway, if your design goes towards not currently supported directions, I may try to adapt the frame code specially to your purposes, and maybe incorporate some of that into the final contribution.

8

Thanks again Max. The " I may try to adapt the frame code specially to your purposes," offer is very generous indeed. I’m no where near to needing this yet. Still trying to work my way though the math involved in choosing airfoil profiles, camber, taper, twist, solidity, blade count for my two fans. I found a paper that lays it all out step by step for a CR RDF, but it is very dense math.

I noticed one (maybe two) on screen comments in a couple of your vids that suggested that 3 flaps “should be enough”, and you were considering making a modification the the single copter frame that allowed the use of 3 flaps. If you’ve made that change by the time I get tot he stage I need to starting setting up flight controllers, great. But don’t go out of your way just for my benefit. I might never get there yet. I am waay outside my knowledge base here. No guarantee I’ll ever reach the end.

One thing I did learn. It really matters where you go to buy the Matek H743 wing controller; their official site on aliexpress lists £80. Amazon offere £200+.

9

The exact FC used for CX7 was the WLITE one, which is around £80 in one of the UK shops I use (Matek H743-WLITE Wing Flight Controller – Unmanned Tech Shop). It might be even smaller than what is called WING.

As for the CPU resources and peripheral pins, it offers all the same things, might be a bit less powerful for peripheral current, might support less motor current… you just check the items against the idea of what you are going to fly, and then the thing changes all over again, the usual design process that eventually converges.

10

Thanks for the heads up.

The specs on that say: " * 1x ESC power pads", I have two motors, or am I mixing apples and dead cats?

11

You can solder two wires to one pad. There is only one current sensor on the board itself (also in the bigger WING variant), and usually you don’t benefit a lot from separate current measurement to each motor. (Bigger ESCs running BlHeli32 or AM32 can provide their current measurements over telemetry anyway).

For the expected wire size on a thing with prop diameter < 10 cm, these pads are quite sizeable, so this should be manageable and the result can be reliable and nice-looking too.

Actually, CX7 had the flight controller on the front leg and both ESCs on the back leg, so I took one + wire and one ground wire across the machine and then distributed them between the ESCs on the back side.

12

I guess I am missing the purpose of that ESC power pad. I assumed it was for the FC to control the speed of the motors - which would require two for my setup. Its sensing current draw?

13

It’s about sensing current draw. The signals to ESCs come from different pads.

S1 and S2 are conveniently located on the top circuit board on the bottom face, which would appear close to the power wires when you assemble the board. S3 to S10 are on the right face, S11 and S12 are on the top face. Unlike the very early years of Ardupilot, where signal pad and “motor function” were hardwired, now you can assign any motor and any servo to any signal pad.

The only limiting thing, however, is that pads come in groups, and all pads in each group should use protocols with the same timing. For coax copters, this means that you should use PWM for outputs to conventional (i.e. not super fancy) servos, and in the modern world you would likely use DShot for motor outputs (including the benefit of getting motor RPMs back via telemetry on the same wires, known as bidirectional DShot). Fortunately, the board designers are aware of this, and S1+S2 are in the same group separate from others (Flight Controller H743-WLITE – Matek Systems, the first table on the Ardupilot Mapping tab).

14

Thanks again. And sorry, I should have been able to figure that out for myself, but this is all so new.

An only slightly related question – that might be discernable from the telemetry on some of your vids, but I haven’t found it yet.

What speed are you running your props at on your contra-rotator? And what sort of speed differential do you see to effect yaw control?

I thinking about the fact that my rim-driven rotors will be substantially heavier than any skinny 3 blade standard prop; and whilst they will run at relatively low speed – somewhere in the 1000 to 5000 rpm range – with the lower the better my target, their inertia will likely make yaw control onset quite sluggish and the likelyhood is that by the time the yaw is actually detected, and the motor speed differential removed, they’ll over shoot and so the FC will be constantly hunting try to achieve the requested yaw.

15

For SN1, in hovering, RPMs are in the range of 15k to 20k.

One motor (the topmost if I’m getting it right) is closer to 19.5k, another one to 17k, the presence of such difference comes from the fact that the top motor gets clean inflow, and the bottom one gets the inflow disturbed by the top motor.

(It also uses 8-blade 3+" props, where this choice of 8 blades is probably poorly motivated.)

My understanding of physics is that everything is momentum-controlled, so a small change in RPM with a heavy rotor would do the same thing as a large change with a light rotor. The difference might be in that for very slow rotational speeds and not too quick ESCs the next change in the desired output power may come delayed, but I still believe it’s well within the sanity limits in your case.

That said, your overshoot concerns are exactly the reason why the PID control gains are not hardcoded, there are plenty of knobs and even the automated procedure (the AutoTune) of getting good gains, provided you found some “basically flyable” gains. Getting to flyable gains is a significant part of my videos :slight_smile:

And the final consideration: yaw authority in coax copters is usually pretty good compared to pitch and roll (because motors usually respond quicker than servos). In both CX7 and SN1, which survived long enough to get a decent tuning, maximum controllable angular accelerations in yaw are at least 2x bigger compared to the other axes, and other tuning quality indicators are also way better in yaw.