Replies

        • The screen grab I have is only responding to roll angles for now :) but I'm not satisfied with my current solution because it requires "painting" several BMP's (and there's a bug with OpenTX painting odd width bmp's), but the objective is to have all the other flight relevant data on screen.

          I believe the Mavlink error codes would be great to have but the way to parse them from Mavlink is not trivial (at least from what I've seen).

          My plan to ditch the AccXYZ and use Roll/Pitch/Yaw angles is because they are not so helpful on casual flight and are already recorded on APM logs (I'm not sure of the situation on APM boards, my board is a Pixhawk) and at a certain distance knowing the multirotor attitude might be more important.

          And yes, I also think that the APM fork for FrSky might be PixHawk only, but I believe this Teensy solution might be better and more versatile.

          Just as a heads-up you can have now a Course to home with a few lines on the Lua script. I've opened an issue to have it natively but it can be calculated now.

          • Displaying the error codes could be really useful. Definitely worth checking out. 

            The yaw-angle should already be present via the heading-attribute? And having a nice looking arrow showing if you are traveling towards or away from the home position would be a nice feature. Depending on the number of steps you really need, you shouldn't need that many image-filesI think.

            • The Yaw angle might be different from the Heading :) and the Magnetic Heading can also be different from the GPS Heading :) :) and all different.....but in the end the Yaw might not be relevant, but Roll and Pitch are. At least to know how hard you're going to crash :)

              I already have some nice looking Photoshopped 3D arrows for the Course to Home I believe that 8 should be enough (N,NE,E,SE,S,SW,W,NW). That part is already done including the calculation for the Course to Home. Because of those arrows I filled a bug on OpenTX that Bertrand has already closed - Lua error with BMPs

              For the error codes I'm now looking at the Mission Planner sources to get some ideas....

              Error drawing BMP on telemetry LUA script · Issue #1579 · opentx/opentx
              This can be easily reproduced and verified using the attached BMP files. BMP won't paint the last column. In this case the BMP is 27x20 pixels, 4…
              • I understand the gps-heading and the frame-heading/orientation. But what do you mean by yaw angle? I wasn't aware of any other angle in that sense. 

                That sounds reasonable. How many pixels are these arrows?

                • Yaw angle as reported by the Mavlink Attitude. I believe is the true angle <horizontal> that the frame is, which might not coincide with headings. Think of wind pushing the frame and the vehicle moving in one direction but pointed to other...

                  case MAVLINK_MSG_ID_ATTITUDE: //30
                  ap_accX = mavlink_msg_attitude_get_roll(&msg) * 180/3.1415; //value comes in rads
                  ap_accY = mavlink_msg_attitude_get_pitch(&msg) * 180/3.1415;
                  ap_accZ = mavlink_msg_attitude_get_yaw(&msg) * 180/3.1415;
                  break;

                  the arrows can be any size. I've drawn them in Photoshop :)

                  They are concentric and only occupy a rectangular frame which encloses all the arrows.3702919995?profile=original

                  At the moment regarding the HUD display I'm still undecided on HUD resolution.

                  My target is to get something large enough to be seen at a glance but informative enough, a bit like the HUD from Google Earth, problem is that we only have 212x64 pixels and if we push for larger more visible/useful size we waste a lot of screen estate....

                  3702920142?profile=original

  • Would u mind building me one of those for my Quad? needed to be shiped to germany!

  • Very nice but is it also possible to use the 3DR Telemetrie set with this way? egen APM->teensy->3DR antenna or would it not work because of some data  traffic?

    • Will it be sufficient for the teensy to have only Rx connected? I assume only 3DR Telemetry radio may need to "tx" data to the bus, as commands may only be passed to APM by GCS, or am I missing something?
      • I have the following connected to my PixHawk.

        Telemetry port 1: the 3DR Radio

        Telemetry port 2: the 3DR Bluetooth kit and the Teensy with only RX+GND connected. 

        This allows data to be received on all 3 systems, and data to be sent via 3dr radio and bluetooth.

        • Do you use LRS or 2.4GHz rc control? And if 2.4 does Bluetooth interfere at all with the rc link?

This reply was deleted.

Activity