Replies

    • Hi

      You really MUST update your Taranis to the latest version.

      When I was actively developing the scripts a very nasty bug on the Taranis was uncovered and subsequently patched.

      On the script itself, are instructions to match the flight modes you have defined on Mission Planner on slots 1 to 6 with the switches.

      --These must be changed to correspond to what is defined as Flight Modes 1 to 6 on the PixHawk.

      -- I didn't find a way to retrieve these automatically from the FC

      -- These can be set in the future by a function script. TBD

      Switches[1].FlightNumber=1 -- these correspond to the Logical Switches defined on the Radio - L1 is 1 =Stabilize
      Switches[2].FlightNumber=3 -- these correspond to the Logical Switches defined on the Radio - L2 is 3 =Altitude Hold
      Switches[3].FlightNumber=6 -- these correspond to the Logical Switches defined on the Radio - L3 is 6 =Loiter
      Switches[4].FlightNumber=1 -- these correspond to the Logical Switches defined on the Radio - L4 is 1 =Stabilize
      Switches[5].FlightNumber=17 -- these correspond to the Logical Switches defined on the Radio - L5 is 17 =Position Hold
      Switches[6].FlightNumber=12 -- these correspond to the Logical Switches defined on the Radio - L6 is 12 =Drift

      btw these are all the Flight Modes

      FlightMode[1].Name="Stabilize"
      FlightMode[2].Name="Acro"
      FlightMode[3].Name="Altitude Hold"
      FlightMode[4].Name="Auto"
      FlightMode[5].Name="Guided"
      FlightMode[6].Name="Loiter"
      FlightMode[7].Name="Return to launch"
      FlightMode[8].Name="Circle"
      FlightMode[9].Name="Invalid Mode"
      FlightMode[10].Name="Land"
      FlightMode[11].Name="Optical Loiter"
      FlightMode[12].Name="Drift"
      FlightMode[13].Name="Invalid Mode"
      FlightMode[14].Name="Sport"
      FlightMode[15].Name="Flip Mode"
      FlightMode[16].Name="Auto Tune"
      FlightMode[17].Name="Position Hold"

      • Hi Luis,

        thanks fo the explanation. I upgraded to 2.0.15 and set the variables but still no luck. I found out by some basic debbuging that the logical switches are recognized correctly. What is not set correctly is "FmodeNr=getValue(208)+1" (Line 531). It is always set to 1. I checked that the flightmodes in mission planner showed up correctly. For me that  looks like that getvalue does not work. However i receive values for (e.g.) compass, height and distance.

        I have the gut feeling that something very basic is not working in my case.

        Thaks for your help so far (and the others as well).

        Thomas

        • Hi

          I have no possibility of testing on a APM, because I only have a PixHawk, so I'll try to give you some clues on how the system is set and how I would go troubleshooting that issue.

          What switches have you set to use the logical switches L1 to L6 on the Taranis??

          getValue(208) is the same as reading the Fuel variable on current Taranis telemetry screens, and on the Flight Controller side that value belongs to the Heartbeat packet.

          On the radio on the normal telemetry screens you can check if the Fuel value changes when the Flight Controller changes mode.

          I mean not when you flick a switch on the radio, but when the Flight Controller Really changes to that flight mode, because as you might know, we might "ask" for a Flight Mode but the Flight Controller "can" decide not to engage it (that's why I have that audio message of the flight switch mismatch). On the top line of the Taranis screen the flight mode that is flashing when not armed and steady when armed is reporting the same flight mode as the Flight Controller, not what you might have set with the switches.

          Now to the Teensy side. You can enable a lot of debugging statements on the Teensy code and verify on a console what is being read by the Teensy. For that to happen you MUST cut the Vin pad on the Teensy so that you can have the Teensy powered by the X8R radio and the power from the USB isolated.

          But before messing with the code......Connections:

          I don't know how you might have your teensy connected but sometimes the telemetry values might not be conveniently sent, if on a different serial port. There are a bunch of parameters that control how the values are being sent on that serial (telemetry) port. There is a screen on Mission Planner that forces the sending of parameters when using a MinimOSD, that you can try to use to force sending the Mavlink data.

          Currently I do have a minimOSD connected in parallel with the Teensy, and both work fine.

          The parameters I was referring on the APM code are the SRx (where x is a specific COM port) parameters

          the parameters are something like this 

          SERIAL1_BAUD, 57 (telemetry output at 57600) 

          SR1_EXT_STAT, 2 ( 2hz for waypoints, GPS raw, fence data, current waypoint, etc) 

          SR1_EXTRA1, 5 ( 5hz for attitude and simulation state) 

          SR1_EXTRA2, 2 ( 2hz for VFR_Hud data ) 

          SR1_EXTRA3, 3 ( 3hz for AHRS, Hardware Status, Wind ) 

          SR1_POSITION, 2 ( 2hz for location data ) 

          SR1_RAW_SENS, 2 ( 2hz for raw imu sensor data ) 

          If you fly copter than you also need to set SRx also: 

          SR0_EXT_STAT, 2 

          SR0_EXTRA1, 5 

          SR0_EXTRA2, 2 

          SR0_EXTRA3, 3 

          SR0_POSITION, 2 

          SR0_RAW_SENS, 2 

          edit:

          One good way to check this would require putting the Teensy in Parallel with a telemetry radio, using only the RX input on the Teensy, then checking via a standard telemetry radio connection to Mission Planner and as the Teensy is receiving the same data as being sent via the radio, that should work.

    • Open up the .lua file in a text editor and look at line 42-47 . You need to change the flight mode numbers to mirror the flight modes you have set on your Pixhawk. 

      (if i recall correctly!)

      • Thanks Paul.

        Exactly that. Unfortunately there isn't a easy way to retrieve the flight modes set on the flight controller, without "asking" for data from the Flight Controller, and as the Teensy is a Receive only device......

        luis

        • Hi Luis, 

          What about prearm checks? Im using your fork of the code because i like the way it looks on the screen and i am used to it.

          The only annoying this is having to connect it to a laptop to find out what the issue is if i get a prearm error.

          Thanks

          Paul

          • Hi Paul,

            that issue brings us to the whole problem of what to do with the messages that are sent down.

            As you might have seen, at the moment, although I'm sending down the messages as a error code, on the script nothing is being done about them. I even have all the voice messages (the MSGx.wav files)  already defined for them, but still undecided......

            I've had some discussions with the APM devs about this subject, and there is an issue opened on APM about defining an simpler way to send shorter error messages that would avoid the crazy parsing that we have to do today. I'll have to check that issue tonight at the APM dev call.

            Also, when you'll try the new OpenTX 2.1 (unreleased at the moment) so many things have changed, that I'm sure you'll like, and will make life much easier for these scripts :)

            luis

            • Great stuff, So I will just need to wait to see if you have luck on the APM dev call. It good to know that you have it in hand.

              I will keep my eye open for OpenTX2.1

              Cheers

This reply was deleted.

Activity