Artificial horizon indicator - possible GUI enhancement

[marksev1]

I'd propose also a artificial horizon indicator as an enhancement to your gui. Like the "major" autopilot gui's have, like taulabs gcs, apm-planner etc.

Just an idea!
Have fun & great work so far!

[stronnag]

On Fri, 16 May 2014 02:43:49 -0700
marksev1 [email protected] wrote:

I'd propose also a artificial horizon indicator as an enhancement to your gui. Like the "major" autopilot gui's have, like taulabs gcs, apm-planner etc.

Just an idea!
Have fun & great work so far!

---

Reply to this email directly or view it on GitHub:
#3

The original theory was that I would not reimplement MultiWiiConf,
rather just build a MW planner for POSIX OS. Then I discovered that
getting MultiWiiConf on my Arch ARM/Chromebook was harder than
reimplementing the functions import to me .... So one day, for sure.

btw, is there a specification for "Lighttelemetry"; after the pain of
extracting from Windows source code the MW nav functions, I'm in no
hurry to go done the reverse-engineering route again.

[marksev1]

Here's some info: http://www.wedontneednasa.com/2014/02/lighttelemetry-v2-en-route-to-ground-osd.html

https://github.com/KipK/Ghettostation/blob/master/GhettoStation/LightTelemetry.cpp

https://github.com/KipK/Ghettostation/blob/master/GhettoStation/LightTelemetry.h

https://github.com/KipK/baseflight/blob/LTelemetry/src/telemetry_ltm.c

Otherwise I'm discussing with the author of lightelemetry on a regular basis on irc, so I can ask him about specific things if you want?

[marksev1]

Was the above info ^^^ what you were looking for?

[stronnag]

It would have been nice to have a more general description e.g. as the MSP spec http://www.multiwii.com/wiki/index.php?title=Multiwii_Serial_Protocol and https://docs.google.com/document/d/16ZfS_qwc-rJeA7N5Tx0DA6wtgxl6HdGgaz-jE3lHBWs/edit?usp=sharing (out of frustration from having to generate an implementation for Windows source code).

And how is the protocol invoked, or does it just start on arming?

[KipK]

hi.

LTM is an air to ground telemetry, so it's one way only; No ACK & stuffs it just stream datas to the ground at low baudrates.

Depending of flighcontroller implementation & configuration it starts at boot or when armed.

Protocol is binary, using little endian.
There's 3 frames to consider:

.

• G Frame (GPS position) (2hz @ 1200 bauds , 5hz >= 2400 bauds): 18BYTES
  0x24 0x54 0x47 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0
  $ T G --------LAT-------- -------LON--------- SPD --------ALT-------- SAT/FIX CRC
• A Frame (Attitude) (5hz @ 1200bauds , 10hz >= 2400bauds): 10BYTES
  0x24 0x54 0x41 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0
  $ T A --PITCH-- --ROLL--- -HEADING- CRC
• S Frame (Sensors) (2hz @ 1200bauds, 5hz >= 2400bauds): 11BYTES
  0x24 0x54 0x53 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xC0
  $ T S VBAT(mv) Current(ma) RSSI AIRSPEED ARM/FS/FMOD CRC

values are:

• LAT/LON: int32 (cm)
• SPD ( speed ) : uint8 ( m/s )
• ALT ( alititude ) int32 ( cm )
• SATS ( number of sat visible ) 6bits
• FIX ( sat fix ) 2 bits ( sats & fix are coupled in the same byte )
• PITCH/ROLL/HEADING int16 ( deg , -180/180° range )
• VBAT( voltage ) uint16 (mv )
• Current uint16 ( ma )
• RSSI : uint8 ( in % )
• AIRSPEED : uint8 (m/s)
• ARM/FS/FMOD: uint8
  ARM armed status: 1 bit ( first )
  FS : failsafe status : 1 bit ( second one )
  FMOD: flight mode : last 6 bits:
  // Flight mode(0-19): 0: Manual, 1: Rate, 2: Attitude/Angle, 3: Horizon, 4: Acro, 5: Stabilized1, 6: Stabilized2, 7: Stabilized3,
  // 8: Altitude Hold, 9: Loiter/GPS Hold, 10: Auto/Waypoints, 11: Heading Hold / headFree,
  // 12: Circle, 13: RTH, 14: FollowMe, 15: LAND, 16:FlybyWireA, 17: FlybywireB, 18: Cruise, 19: Unknown

Each frame end with a CRC byte, it's a simple XOR from first payload byte to last one ( starting at 4th byte , headers are not xored )

Hope it helps

[stronnag]

Thanks. On the 'todo' list.

[stronnag]

Until the new horizon stuff is fully working, let's leave this open. Currently it highly experimental and not 100% reliable.

[stronnag]

The horizon and flight view items appear stable (with good GTK themes). The issue will be closed after the documentation has been updated.

[stronnag]

Completed, apparently stable (if dock items fail to update, it's probably a bad GTK theme). Documentation updated.