[TheOtherCliff]

Looks more reasonably controlled than earlier; without forward flight oscillations. 

Is hover mode (say in Attitude) fully controllable?  Looks like you use it very little.  Maybe for some test hovering, lock the wings into hover configuration if afraid it will transition otherwise?

Are you actually transitioning to hover and switching to hover before landing?

[trust]

Yes, hover mode is fully controllable and very stable. With the fairly large wing area it tends to drift a lot - note the backwards drift after take off in the wind. The tail tries to keep it pointed into the wind.

None of these flights have had transition back to hover before landing. From many other flights, I've found if the wind is more than 5mph or so, it's easier and safer to horizontal wing hover to land - pitch up until hovering, then back off on throttle till tail touches and cut throttle.

To get the wing to transition back to vertical, the plane has to be flying backwards relative to the airflow. In little or no wind, pitch up in horizontal wing hover until forward motion stops, and plane starts drifting backwards - usually at that point the wing will rotate. Immediately back off pitch and plane will go into vertical wing mode hover - provided you're in vertical wing mode!

So if the wind is lite enough, on final approach as I increase AOA, I'll switch from hrz wing to vertical wing mode. The high pitch angle prevents the roll oscillations. The process of hovering is similar to horizontal wing hover, especially if roll is coupled to yaw (as I have it set in the transmitter). Then the transition process is as describe above.

What I have not yet tried is dealing with wing transition if the plane is still in horizontal wing mode. In theory, it should still hover. Pitch is normal. If it tries to roll to the left, gyros will apply elevon that will try to yaw to the left - then the the gyros will tell it yaw to the right to compensate, which turns up the left side motors and it will roll back to the right.

It's the same reason why it sort of works with just one set of controls - not ideally with the oscillations however.

I'm considering automatic switching of modes - a sensor to detect wing position and automatically switching modes.
It could be "analog" and have gradations based on angle.
But for now I want to test the various planes with manual switching and see how well it handles.
I've flown 2, am modifying a fifth one now, and plan to test the other 3 as conditions allow. I've modified one of Chris and he wants another one modified too - more FCs on order. He also has two more planes (larger, size in between the micros and Hell8ious) we may modify.

[TheOtherCliff]

My vote, instead of a wing position sensor, have a wing position servo.  Without that, waypoint/FPV missions have the potential for getting into the wrong mode.  One Tx FMS position changes both the flight mode and the wing position.

They make slow and powerful servos for landing gear and sail winches, but something could also be home made like a something with a screw reduction and micro switches or screw reduction and servo pot/electronics.

[trust]

One of the principles of the Hellaplane design was NOT to have a motor/servo driven wing transformation device. So many of the eVTOL designs use some form of motorized device to rotate wings or motors - and they are a major source for failure and added weight, due to their high torque requirements. KISS has been the design philosophy.
  I do have a "wing lock" servo I added to V1 - when the wing is in hrz mode, activating that servo holds the wing in hrz mode. It has been a bit problematical - not always working. And not used anymore.
  I recently ordered a TX16 - hopefully I can get around too few channels and incompatabilities with receivers, so I can experiment with more channels if needed.
  Rainy wx here so no testing for a few days.
  One other minor note - when upgrading Micro V2 to bimode, I noticed one of the rear elevons was "twitchy" - something I noticed on M1 as well after a recent test flight. The elevon - usually soon after first power up, would jitter back and forth, sometimes moving fairly far. If you move the control surface, sometimes it would oscillate. Only happens on the rear elevons. Replacing the servo fixed it. Landing tail first with high AOA, sometimes the elevons hit the ground before the tip protectors (rods extending from the wing tips to hold the wing off the ground, away from the elevon) - and it can damage the servo. Not sure if its stripped gears or what. The tip protectors are made of bamboo on the micro (carbon fiber on Hell8ious) and also often crack or break - one test flight was marred by the broken stick being bent inward and preventing the elevon from moving properly. Pre-flight, pre-flight checks!

[trust]

Picked up this last week and programmed some settings. Some minor beefs on the wheel but overall very nice! Plus open source.

I'm doing some planning on incorporating a wing position sensor. I can use an IR LED and phototransistor pair with any one of several devices to control the light intensity based on the wing position. Example a piece of film with a gray scale pattern - black graded to clear, attached to wing. As wing moves it shifts the pattern, enabling light to dark full range of position sensing.

I can hook this up with a pair of resistors to an ADC input - I could use the sonar inputs on the Revo, or I could use the Orangerx receiver telemetry.
If I use the receiver telemetry, I could program the TX16 to interpret the values and set a threshold to automatically interpret wing position and send it as the switch value for bimode. Fairly straightforward.
But if I loose telemetry, it won't work properly. Not sure what range will be on Orangerx telemetry.

If I use the Revo ADC, can I translate the values to a 1/0 I can use to set the bimode? Can the ADCs be set as an Accessory input? If so I can use my existing code - it just thresholds on 0, and I have a flag I can use to invert states if needed.

[TheOtherCliff]

I'm doing some planning on incorporating a wing position sensor. I can use an IR LED and phototransistor pair with any one of several devices to control the light intensity based on the wing position. Example a piece of film with a gray scale pattern - black graded to clear, attached to wing. As wing moves it shifts the pattern, enabling light to dark full range of position sensing.

etc

I'd use an old servo.  Remove electronics, gears, motor.  You have a pot and an arm left.

If I use the Revo ADC, can I translate the values to a 1/0 I can use to set the bimode?

That sounds reasonable.  I have to shift my brain into realizing you will probably be having this sensor effectively change your flight mode.  Sounds scary but should work.

Can the ADCs be set as an Accessory input? If so I can use my existing code - it just thresholds on 0, and I have a flag I can use to invert states if needed.

Not that I am aware of.

IIRC the AccessoryX's only allow normal receiver channels to be assigned.  (I think you can have more than one receiver/type connected.)  That said, if you can have your sensor output PWM, it would look like a receiver.  (But then the default is to set up enough Revo PWM inputs to fly something and that eats inputs that you probably don't have.)  A $3 clone Arduino Nano or Uno and the aforementioned servo pot would do it.  There is probably some very simple Arduino code to do the analog to PWM that you could find on the internet.

Revo ADC sounds easy / already mostly coded.  You will have to write some code to do something besides look at it in telemetry.

Be aware that internally Revo runs on 3.3V and although some pins are 5V tolerant, some aren't, and maybe even some clone 5V tolerant pins aren't and some clone OP boards don't have the port protection circuits the authentics have.  More than one user has fried a servo connector signal by carelessly plugging in an ESC that has live 5V.  If the 5V and signal connect before the ground does, you have effectively driven the signal pin way out of range.  Solution is to use a spare output (6x outputs, only 4 used for a quad).

[trust]

I considered the servo idea - I even took one apart and prepped it to be used. But I don't have a place to input it.
I'm currently using 8 input channels as S.bus input on one pin of the main port. 8 outputs, split between 6 on the normal outputs and two on the 8 pin "receiver input", with 2 of those pins for the OPOSD telemetry. Flex port is GPS/mag. So I really don't have another input port I can use, unless it were inserted in the s.bus stream somehow as a 9th channel.

[jdl]

... with 2 of those pins for the OPOSD telemetry...

OPOSD uses just one (output) pin to passively receive data from FC, it does not send commands to FC.

[trust]

Thanks for the clarification on the OPOSD JDL.

I've added some additional code to implement the hardware wing position sensor, and assembled and tested a photointerrupter connected to the battery voltage input on the sonar port. I used a GP1S196HCZ0F from digikey with a 470 ohm R between the IR leads and 5V supply, and a 10k between the emitter and ground. 5V also goes to the collector. Clear drives it to near 0V, interrupted to near 5V. The input only registers up to 2.5V but it seems to be a 5v tolerant input.
This device is really way too small, but I'll try to use it.

The code has 3 "switch" options - Sensor, Switch, or SwitchOverRide - in Sensor position, if the voltage passes a threshold (float value set to 1.5v) then it switches. In Switch mode it uses the selected Accessory channel switch. In SwitchOverRide, if EITHER sensor or switch is 1 then it is 1 (logical OR). Both switch and sensor have an invert option.
  I'll likely use the SwitchOverRide mode at first - that way if anything goes wrong with the sensor, I can override to hrz wing mode. I can turn this off when landing, to ensure that when the wing swings back to vertical it will immediately go to vert wing mode.

Tested the code and the sensor - so far looks good, everything works but need to add sensor to plane and update plane firmware (testing on a spare FC).

Yesterday did a flight test in strong wind conditions - did a hand launch for the first time in 20+mph winds - 30 aloft. Some of my hang gliding buddies can be seen in the video as well (tiny specs but hey). Basically a 4 minute vertical elevator ride up and down. Needed a LOT of down elevator to get down - lift was very strong in the main lift band. Also turbulent.

[trust]

At the request of my buddy Chris, I've added another mixer type - ManualServo.
An output set to ManualServo ignores all the attitude and gyro settings and acts purely as a mixer for the roll/pitch/yaw receiver data. It can be used in bimode as well.
  Since these Revo FCs have as many as 12 output channels, its very useful to be able to use the FCs purely as mixers - and still use the gyro functions on output channels where needed.
  Seems to work in preliminary testing - one minor oddity - in the GCS Output page I can set the min/max/neutral settings fine, but it does not show the manuelservo assignment - it looks blank, but I can set items in it. Does not seem to affect being able to use it, but annoying I can't see it set.
Any idea where in the GCS code I would find this?

[trust]

As a minor issue, where should I change the firmware code name? having it always list as xxx-dirty is somewhat confusing.

[TheOtherCliff]

I've added another mixer type - ManualServo.
...
In the GCS Output page I can set the min/max/neutral settings fine, but it does not show the manuelservo assignment - it looks blank, but I can set items in it. Does not seem to affect being able to use it, but annoying I can't see it set.
Any idea where in the GCS code I would find this?

Any firmware change that you want to show up in the GCS GUI (that is besides automatically showing up in System) must be hand coded.  This generally requires hand editing QT files or using QTCreator to edit them.  Maybe you won't need to actually write C++ (GCS is C++) code if you only want to change UAVO field values.  I consider that this is something you do if you want to give a polished enhancement to the world.  Having done it before, I would just use System to edit the new UAVO stuff.

As a minor issue, where should I change the firmware code name? having it always list as xxx-dirty is somewhat confusing.

If you use git to commit your changes, the dirty goes away and you increment the RXXX number like currently next is 16.09+r796.  Or you can change the build system that does that.

[trust]

Update on testing - the latest version with the wing sensor and manualservo functions were upgraded in 4 Hellaplanes - 2 of mine and 2 of Chris. The first test of the wing sensor the sensor worked fine and transition happened as planned - but the wing transitioned at very low altitude due to wind, and the V2 model it was in had an issue with pitch oscillation at low speed transitions - and subsequently crashed. Parts tested - mostly all still working (only one bad servo), but frame wrecked so will be built into a new model. Chris tested his Mini V1 next - it worked very well using the manual servo modes and he had several successful flights. Some tweeking needed but an improvement over the non-bimode version. We also stripped both his planes down from two FCs to one Revo, which saved some weight. He did some hover testing of his Mini V2, which is a somewhat different design but no horizontal flights yet.
Today I got in the first solid test of bimode with wing sensor on my V3 which went very well. Very smooth transition - I couldn't tell when it switched. I added elevator on the front elevons, which seems to have eliminated the pitch oscillations (in so far as tested) - so I went away very happy. Clip of the week from that flight:

It's remarkable to me how robust this FC hardware is. I've had planes sustain multiple 35-50mph crashes - and the electronics still works just fine. Most common failure is ESCs after a crash. Servos also. Perhaps a testimony also to our fail softly designs, which have multiple breakaway devices (mostly zipties and foam!) which absorb impact.

[trust]

I've noticed that after some period of time, I get EVENT flag blinking slowly orange. Its not clear what conditions start it. I sometimes arm then disarm while checking system functions - it often shows up after a few of these. I use an accessory input from one of the switches on the xmtr.
Doesn't seem to affect operation.
I did find that using the batteryvoltage input on the sensor input, as it runs in the range of 0.3 to 3.3V, I had to change the alarm and warning limits to 0, or under some conditions I couldn't arm the system. Possibly useful as a warning of failure of the wing sensor.
What conditions cause the EVENT flag to blink like this?

[TheOtherCliff]

I forget exactly what to look at here, but I would start with GCS -> System -> DataObjects -> SystemAlarms -> *

I would also set up the Scopes to monitor similar things.