Sport Air/Engine Data Collector

So I've written a new "firmware" (yeah it's just an Arduino sketch) based on the old SportVFR sketch.  This is designed specifically to be a generic data collector/emitter.  The idea is that SportVFR board when paired with an ATMega32U4 Pro Micro dev board is a multi-purpose data collection tool.

Here's how it works.  There are 25 "Channels", 3..21 are numbered after the actual channel (see picture)

0,1,11-13,16,22-24 are not usable as such.  22-24 are "virtual" and represent the Tachometer, Altimeter and Compass virtual output channels.

It is entirely commanded externally via 9600 baud serial.

Commands:
* NAME- Name channel
^ Val - Set Max
v Val - Set Min
< Val - Set channel value (for output)

All channel configurations are saved into EEPROM and are restored on reboot.

Channel names are 4 character and the first denotes its purpose.


Channel 1st character enumeration:

> Digital Input

$ PWM Output

~ Analog Input
< Digital Input
^ Input w/Pull-Up resistor
| Virtual (for internal only, don't use)

Overall grammar:

{MsgId}{Command}{Channel},{Parameter}

Example:

1*1,~TST    Names channel 1 to "~TST" which an analog input field  
3^2,100       Calibrate max 100 is the mapped output value of current reading

For its part the device serially dumps the polled data in this format;

-HDR-<TST-DAT-32

Here's the CodeBender Source

Avare update and Pitch

Early on in the AP idea, I thought I'd need a standard pitch servo for the AP function.  I've discussed and I'd like to try using the pitch trim to drive the hand-flown trim as well as the vertical autopilot functioning.  A good R/C servo is strong enough to set the tab and fast enough to control the pitch axis.  So I'm going to start there.

Avare..  I've posted to the group and found they are very receptive to the changes I've proposed.  I'm going to make my changes to that project, either directly or through an Avare-aware Add-On.  Either way, it's a good Android app platform to start from.  It already supports much of the functionality I'm looking to leverage.

How's this all going to work together?

I've been throwing around a lot of boxes, boards and ideas... but I hadn't really technically nailed down how all these parts fit together and if they do actually fit together.  Good news... it does, and very simply and I can leverage existing software for 90% of the functionality.

The key to this are two Arduino Mini ATMega32U4 based controllers.  The first is one is obvious... SportVFR's, collecting engine and airspeed data.  That data is sent to Android device via serial communications on a dedicated USB.  This could potentially be Bluetooth, that is a future development.

As I started composing this architecture, I found I was missing two interfaces... First, the pilot's joystick input to the CarPC (programmable stick buttons).  Second, the interface to the Naze was not very robust.  Sure, I can connect via USB and run in a pseudo config/command mode.  But ideally, you want a dedicated processor feeding serial inputs to the Naze acting as though it is a R/C receiver.  This is perfect for translating the high-level AP commands form the Android to the Naze... I'll have a post on the AP commanding next.

More AP specifics

Controller: Naze32

Firmware: CleanFlight iNav (specifically for UAV with improved navigation function built-in)

Interface: Multiwii Serial Protocol

So here's roughly how it will integrate... I'll flash and install the cleanflight iNav to the Naze32.  I'll use cleanflight iNav configuration software to setup the controller.  The Controller will not take any servo channel inputs, but it will drive the aileron trim servo and the pitch stepper servo via a RC PWM to 4-wire Stepper translation IC (probably arduino).

The Android 4.4 CarPC will have a dedicated permanent USB connection to the Naze32.   I'll run the configuration software on the CarPC.  I'll write my own Autopilot command app that will send Wii Serial  command (MSP_SET_RAW_RC) to the Naze32 via the USB.  These command will engage/disengage the AP modes on the Naze32, trim the aileron (when disengaged) and steer the AP for navigation mode.

Let there be Autopilot!

Back in 2002-3 I experimented with a roll-axis autopilot that used a single axis solid state gyro on my RV-3.  Ultimately the project failed for several reasons.  But mostly the technology was not ready for my level of knowledge.  It is no-longer that way.  You easily access 10-dof Quad Copter controller boards which can be reconfigured for the larger mass and inertia of full-scale.

Roll/Pitch - Heavy-duty sealed waterproof metal gear digital R/C Servo.  Connected to an aileron/elevator trim tab.

Integration is where it gets messy.   So you have an Android Car PC, which has USB output.  You can directly connect the Quad Controller to the Android PC.  Normally this would be done to run the setup of the quad controller.  But it could be permanently connected and there should be a way to command the quad board between normal flight and autopilot mode from the USB via this configuration mode.  Normally this would happen via an Auxiliary transmitter channel.  Furthermore, there should be means to steer the autopilot for navigation on that same usb connection.  There are three AP modes; off, steer and hold.

Steer - Generally keep the vehicle flying upright, but use the various channel inputs to direct the vehicle

Hold - Ignore the inputs and keep the last Altitude and Heading.

I can see both of these modes being utilized by the high level Autopilot function in the EFIS.

The roll axis can be directly controlled by the quad controller.  When AP-mode is disengaged it will act as roll-trim getting input from the Arduino PC via USB connection.

The pitch axis will require a controller that can translate the servo output PWM signal to stepper motor.  I'd build a small board to do that.  Probably us a Arduino Mini or an ATTiny88.


At the end of the day.. What I want the pilot to have is completely naturally intuitive integrated autopilot.  So ahead of time, you plan your flight on a third party Android app.  We'll upload the plan to our app.

When you take off at 1000 AGL, an AP-FP button pops in the corner.  You press it,  it uses your airspeed to drive climb rate (constant airspeed) and steers you on flight plan.  Let's say you're not ready to go on flight plan heading yet.  You fight the roll to wings level.  A button pops... AP-HH.  Press it, your on heading hold... still climbing.  You fight the servo and push the nose over... button pops AP-AH, altitude hold.

So now you're flying along.  And there's Class-C airspace at your altitude.  Pop-up... AP Airspace [Through] [Over] [Under] [Left] [Right] (This would be icons as depicted below, not words).

AP: Airspace
       ^
    < 0 >
       v

Flying along.. ADS-B finds a traffic conflict

AP: Traffic
       ^
    <   [>]     [recomended]
       v

Keep flying and you get to the vertical intercept.  Where you need to descend.  Pop up, AP-DES.