Does this forum apply to intermesh systems?

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

I am working on a combi-copter intermesh design.

It does seem similar to a coax in some ways.

After looking at the Arducopter code system, I am going back to planning for add-on Arduino boards.-
much simpler, and functionality and build is more modular.

My first issue is what to do with thruster and elevator controls. Direct intermix does not seem appropriate.
there are several elevator instances, for example: high angle thrust-assisted climb,
slight rotor-down, thrust assisted level flight,
“airplane” flightpath emulation,
Aerobatic manoeuvres with tail thrust,
low tail thrust, high rotor forward thrust.

how much intermix/ multiplex, and how much separate pots on the transmitter?

Can I do multi-input intermixes: thrust, pitch, level of intermix transmitter controls?

-Issue 2: feathering wings, with elevon/aileron and pitch control.
I want yaw control and low speed manoeuvring when vertical,
and possibly aileron and pitch trimming when horizontal.

I can do a servo following a sensor pot on an airflow paddle, or is a digital rotation counter a better bet? I also need a calibration input, and a trim input.

I can run a PWM output from the flight controller for pitch trim,
and another for mode switch to feathering.

I can set an angle point to allow low speed mode change, with multiplex to rudder and
fore and aft pitch.
when angle of attack mode is selected, then I can multiplex to roll pitch.
Questions:
Can I run some of these multiplexes as ardupilot output channels via PWM?
How many output PWM channels do I have with Matek F-765 Wing?
I need 2 motor channels- one can be ganged together for two main drive motors.
Is there anything I have missed out?
I don’t think I need gyro on the Arduino. A Nano would probably do.

Is there anything I have missed at this stage?
Feedback is appreciated.
I need to settle on a control development plan, and reduce my variables a bit.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

Add-ons

This shows how I want it to work.

controls:
Numbering in the same order as on the diagram.

7. Gyro bias. level of gyro assist for normal flight vs deliberate aerobatics.
8. Orbit-autopilot. Fairly standard.
9. Elevator pitch bias. I want to mix on the pitch stick, from mainly elevator, to mainly cyclic.
   cyclic can have a slight mix from thrust throttle as well.
10. Elevator macro trim. The Kaman uses elevator to oppose cyclic down-pitch, to avoid or reduce a nose-over. This can be used to allow rotor-driven forward speed.
11. Rotor RPM top limit - pot.
12. Thrust RPM/ throttle-pot.
13. Wing feathering - switch.
    12 Wing pitch trim- pot. This controls relative rotor and wing angles of attack.
    This is addition to the built-in 3 degrees down-rotor.
    Total channels = 12
    Pots = 6
    Switches = 2
    I have 3 pots and 2 sliders at present, so I will look at modifying my transmitter.
    Questions:
14. Does the existing Arducopter setup allow these adaptions?
15. Do any actual “hobbyists” hang out in these forums?

I tend to like a bit of a natter. Interactions so far are like talking to my old boss-
Not that much fun.

I have two Matek F765-Wing units here, and would like to get some use out of them.

The next stage for the Nano, is to represent functional blocks, and logic blocks.
I am familiar with decision trees, but did not use them in my work.
Do they have a use here?
Do you have a favourite diagrammatic method?

[hubble14567 (2lian)]

You are asking way too much complicated questions that need the dev/engineer who coded ardu to answer, no surprised they talk like your old boss, it’s there job and you are not under contract with them (nor anyone here).

Yes they are “hobbyists” here. But our hobby is not to answer the question of people asking how to build overly complicated craft that we cannot understand (nor even see, in you case, thanks for the wall of text that looks like the final exam of an engineering test I forgot to study).

Sorry for the rent,
Do any actual “hobbyists” hang out in these forums? and Interactions so far are like talking to my old boss- Not that much fun.
Pissed me off.

It is great that you know exactly what you are doing, but the best way to answer all of that (if you don’t want to talk with dev/engineer) would be to buy a board and see how it works or buy a board you know.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

Maybe I was a bit peeved at interactions so far? - maybe from somewhere else.
I now have all the build environment and a lot of info, but you are allowed to ask for clarifications.
I thought the box diagram wasn’t too hard to follow.
The actual aircraft is a combi-copter , with winglets that swivel, and a pusher tail prop, and
an intermeshing twin rotor setup.
If you want some pictures, just ask, and I will post some.
The main problem is I need some info on whether I can combine two input channels in a defined way.
ie:
1)set an upper rpm limit or scale factor with a separate channel input,
2) set a mixer-slider operation on pitch input, so it goes from
elevator output, mixed elevator and cyclic pitch( pitch only) to cyclic pitch only,
-as opposed to cyclic roll- there is a terminology problem there.

This is probably in the setup instructions somewhere,
but it sounds to me like something that wasn’t anticipated in the initial scope.

I want to keep using Arducopter to get use out of my f765 unit,
but don’t want to learn the the full system at a programming level.

An Arduino Zero is more my pace, but not so good for gyro stuff,
or number of output PWM channels, plus the 9 or so analog connections.

There is a nice helicopter app available, but probably not totally suitable.
It has is own desktop graphical interface than runs on Windows.

I need the f765 for:

1. s-bus connection to the receiver,
2. stabilised 5V output.

• a bit of overkill, but I have one on-hand.

If I try to pass-through up to 12 transmitter channels, and add up to 4 more outputs, the Zero may not handle it.
I don’t know if I can run the uarts purely as digital outputs, not PWM.

It is not a good idea to divide up channels that need gyro assist.

that means, only the tail motor is left?
Main motors , too, if I can set a scale factor on them.

I don’t think the Arduino has a bus system for control inputs.

It also only has 256K eprom, which is a little small.
The F765 has 2 Mb eprom.
the Zero is probably ok for speed, at 40Mhz,32 bit.- vs F765 around 500mhz…

Now this stuff is a bit outside the realm of model aircraft hobbyists, I suppose, and getting back to the arduino side of things…
Any arduino enthusiasts can chip in now!

[Yuri_Rage]

ArduPilot hasn’t had support for pure Arduino based builds for years. You are reinventing the wheel and apparently upset that no one is excited about it. Plenty of hobbyists and indeed Arduino enthusiasts (like me) spend time here. Most of us have moved away from Arduino as a flight controller because better (and sometimes cheaper) options exist today.

EDIT:
After reading again, I see that you are indeed trying to use a Matek flight controller but you are somehow convinced that it will not provide the functionality you desire (but then you also go on to discuss using an Arduino Zero in its place, hence my confusion). I think the problem is that your description of the build is extremely vague, and then you ask a long list of questions that are entirely too specific. It’s impossible to discern your actual goals by trying to interpret context clues from your rapid-fire questions.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

I am not excited about having to modify Ardupilot to get what I want.
I will have a bit of play on Arduino first, to get up to speed.
I am pretty sure no unmodified version of Ardupilot will do the job.
I have moved on since I posted this stuff.

I am now looking at a helicopter-style VTOL with contra-rotation, fixed pitch, and thrust diverter-type controls.
Functionality of the various buckets and butterfly flaps
varies depending on flight mode selected.
ie:
Hover,
forward flight,
transition,
thrust vectoring.
1)Roll reaction control is shut off once thrust vectoring is in use.
2) Forward thrust shutoff is converted to thrust vectoring, via two synchronised twin butterfly setups with four servos.

You may not wish to get involved at all,
but I am past being bothered about it.

[ppoirier]

Hello,
I am not specialists of copter but I am curious to see if thsi project could be feasible with ArduPilot.
Can you provide a picture of the proposed vehicle and a simple list of requirements?

You probably know exactly what the system needs to control but Your approach of cascading microcontrollers is not suited for ArduPilot as we use logical controllers embedded into the code in order to accomplish this goal. That makes the development much easier and efficient. I encourage you to read the different wiki that we provide so we can speak the same language and we can refer to common concepts.

Good Luck

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

I am not sure what you mean by a system of cascading microcontollers.

I have only a hazy idea about how a pitch, roll, yaw, and altitude control system should work.

Basic hover control is similar to a helicopter, only the 3-servo multiplex is done differently.

Vertical control is like a simple “fixed” pitch helicopter, by throttle.

vertical damping is done via a barometer module,

Pitch is done by a system of 4 thrust reversing bucket servos. 2 do pitch-down, and 2 do pitch-up.
this also interacts slightly with altitude control.

Roll is done by 2 sets of double butterflies, which are very non-progressive, and need to be cycled fairly slowly due to mechanical constraints and inertia.
It is likely they cannot be fully cycled in under 0.1 seconds.

Changeover needs to re-assign the the servos, in that forward motion activates a closed set of twin butterflies, then configures them as thrust vector flaps.
there are 2 sets which act like ailerons.
As this is done , the roll control butterflies are fully closed.

Hover yaw is done by butterflies as well, assisted by the rudder in forward flight.
Pitch is mainly handled by the elevator in forward flight, with “bucket” intervention if elevator response is lacking.

There is another flight stage: If throttle/rotor speed requirements drop below a nominated level, additional airflow may be directed to the rear thrust system via another pair of butterfly diverters, rotating through a fixed angle.
throttle is then increased to take this into account.
This may happen simply by level flight, or if dynamic lift is attained.

One can imagine that the lift rotors need to be backed off to such an extent that forward thrust cannot
be maintained. This could call for some redesign.

I doesn’t sound all that simple. I will attach a drawing, and you can find all the flap devices on it.

Much testing and tuning will be needed to get pitch and roll control to work properly, including
possible redesign.
I am trying to avoid using add-on EDF units , as they really eat batteries.
If I can use a number of units that draw less that 10A on 3S, I may consider it.

[ppoirier]

Ok first the drawing, it looks to me like a coaxial with vanes and trust motors configuration ?
Still, I am not specialist but vanes control is not optimal (dont think I have ever seen a successful implementation). I would ask @iampete and @bnsgeyer for comments if the concept is feasible.

Second the controllers, look here at the block diagram as an example how this is implemented on a quadcopter:
https://ardupilot.org/dev/docs/apmcopter-programming-attitude-control-2.html

Oh…BTW, here is a good start for this type of vehicle: SingleCopter and CoaxCopter — Copter documentation

[bnsgeyer (Bill Geyer)]

@ppoirier i had discussed this with @Owen_Bern in another thread here. Sounds like he decided to do more of a copter like aircraft (fixed pitch) rather than a helicopter type design (variable pitch). This is outside my expertise with the code.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

1. All thrust is run via 90 degree deflection of the main rotor thrust.
   This seems to be only about 50% efficient, but it will do for now.

2. I will have a read of Multiwii, which may be more suitable for direct hacks.

3. The kind of (twin, opposed) vane tuning I imagine is to set limits of initial blowby, upper and lower vane angle limits, say 30 degrees and 60 degrees, balance the two roll thrusters against each other, and work from there,
   in possibly stepwise servo motion requests- say in 5 percent thrust increments.
   This may be small enough to not produce high rates of roll angular acceleration and severe roll pitch.

Smoother increments, and velocity ramp-up-ramp-down may be applicable, as for electric motors.
They can tolerate stepwise inputs, but respond in a ramping fashion.

I may have to move away from strict emulation of an analog feedback loop to get good results,
but I can try that first.

I will have look through your block diagram as inspiration.

The Bucket deflectors are a whole other proposition, as I have to divide output into two parts-
pitch-down, and pitch-up.
They also are intended to work in a more oscillating manner to the roll flaps, as they are
likely to be quite “vicious” in action.

Tuning will involve calibrating dip swing and dip duration, then re-evaluation of angular velocity
and angle after each dip. This also departs from a strict analog feedback loop.

It also raises the possibility of creating an “autotune” feature. Do you use this?
Simulated “P-factor” adjustment, and more deliberate interval-based measurement and trimming.

Anyhow, the first job is to build a motor stand and run in the engine.

Then I need to build and test the contra-rotating drive.

Then I will build a “Flying Bedstead” test rig.

Then I will start programming and testing.
All this will take quite a while.

I may have other design ideas or refinements in the meantime.

[Yuri_Rage]

You’ve gotten the attention of the guys who can help get ArduPilot to natively support your control scheme.

I don’t think you quite grasped what one of the devs said above regarding “cascading microcontrollers.” In other words, it’s probably not a good idea to take ArduPilot output and manipulate/mix it with an external microcontroller as you suggest you’d like to do. Rather, it appears you might have some allies here to help get the ArduPilot controllers to directly provide the output required.

I think the question remains at this point:
Do you want ArduPilot to natively support your craft, or have you moved away from that idea in favor of developing your own controller?

In any event, it’s a curious set of concepts, and it’d be great if you shared progress/pictures as you go.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

I moved away from the dual system while I was doing the Combi-copter.
I did a study of EDF VTOL, then IC geared fans, now back at
a variety of combi-copter. The high thrust to weight o the 61cc two-stroke motor makes a direct-drive
contra-rotating lift propeller system viable.
I don’t think it is a good idea to try to force Ardupilot to support vane or bucket-style
stability control at this stage.

Really severe low-level hacking may be required,
which is better done with a more “flat” system.

I will have a bit of a potter about, and come back if some integration or programming language translation is needed.

First thing is to set up comms with my transmitter, and figure out what I want to have transmitter-level
handles on.

Possibly hover/forward travel should be ground-switchable.
Maybe by repurposing “throttle” input signals?

Do I need separate control of vertical and horizontal thrust at the same time?

I still have a lot of building work to do, and testing, them we can start working out how to actually stabilise things.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

Revision to the new mono-combi-copter layout.
Gyro stabilisation is now by 30mm edf units, 4 used.
Mechanical buckets are retained just to assist vertical stability, to compensate for slower response from the IC constant pitch lift system.
They can also be multiplexed with manual pitch control.
manual roll control can be assisted with the pairs of facing butterflies.
The remaining issues are:

1. mode changeover for the thrust system, from block-off to thrust vectoring.
2. shutoff to the roll butterflies when thrust vectoring takes over.
3. stage one lift diversion to thrust.
4. stage 2 blanking off parts of the lift aperture if aerodynamic lift is achieved, to maintain thrust.
5. changeover of stability control to flying surfaces from edfs.

These changes make it likely that arducopter or arduplane can be used for some initial flight testing,
if the stability output can be diverted to the EDF units.
The other issues can be dealt with in further development.
Vertical stabilisation could be partly assisted by the edf units, with about 100 gf each maximum.
Partitioning control between the edfs and the IC throttle could be tricky, as they are effectively two control loops trying to do the same job.

[Owen_Bern (Bernhard Owen Nieuwenhuyse)]

I had a look and single copter and coax copter.
My concept seems to be a class that combines plus quadcopter and singlecopter.
I don’t want the full thrust output to the pluscopter part, and I need to pull out yaw to a separate servo.
the pluscopter configuration gets a fraction of throttle, but all the pitch and roll.
This will get me hovering and handling like a copter.(stage one)
Then it starts to become complicated when I introduce transitional flight, and fixed-plane flight,
as two more stages.

My desired system looks a lot like what Joel Vlashof has done with his harrier.
I will post him another message.
He is also doing an F-35, which is quite a bit different, with a lot of thrust and yaw
going through the rear bending nozzle arrangement.

What is involved in getting to stage one?