Replies

  • Well... as a matter of fact I did note that going with a stiff breeze I was going 60 mph with my quad. That's probably a bit faster than normal however not exceptionally unusual for a plane. Thanks for looking into it.  

    Paul Atherton said:

    Richard, I have tested this tonight, and I can get the arrow outside the box, but only under extreme circumstances - like when the latitude changes vastly during the flight - simulating the craft having flown 40+km. I do agree that the arrow should never leave the box by design so will attempt to have a look at this, but as this bit was written by someone with a much higher grasp of trigonometry than me, it could take some time for me to figure this all out. It would be good to know the details of the flight which resulted in your findings. Such as the lat/long and vehicle heading prior to arming, (I.e. the home position/bearing), and then the lat/long and heading when you saw the arrow out of the box. Any ideas?

    Thanks, Paul


    Paul Atherton said:

    No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


    Richard Kennedy said:

    I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

  • Richard, I have tested this tonight, and I can get the arrow outside the box, but only under extreme circumstances - like when the latitude changes vastly during the flight - simulating the craft having flown 40+km. I do agree that the arrow should never leave the box by design so will attempt to have a look at this, but as this bit was written by someone with a much higher grasp of trigonometry than me, it could take some time for me to figure this all out. It would be good to know the details of the flight which resulted in your findings. Such as the lat/long and vehicle heading prior to arming, (I.e. the home position/bearing), and then the lat/long and heading when you saw the arrow out of the box. Any ideas?

    Thanks, Paul


    Paul Atherton said:

    No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


    Richard Kennedy said:

    I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

  • Tim,

    I have attached a spreadsheet containing details of the telemetry sensors and values contained in each, which are produced by using the passthru protocol you refer to. Thanks to Luis Vale for providing these to me and allowing me to share here. Hopefully this will be of help in writing LUA script etc.

    Best wishes, Paul

     
    Tim Painter said:

    Hi Paul.

         Thanks for the comprehensive reply .

       I have  been "out of the loop "  for some time how quickly things change.

    I am using a inverter to get data directly from pixhawk into Sport.

    the main reason for doing this was to save £20 on a teensy but the cost of craft and theory lua would cancel this out

    arducopter 3.4  also seems to directly output "repurposed " telemetry.

    I think this would be easier to use with a lua script with a few tweeks.

    Thanks again for the information

    Tim

    option10_APM.xlsx

  • No worries Richard. I'll check this on 2.1.9 myself and see if I can reproduce the issue. Cheers, Paul


    Richard Kennedy said:

    I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

  • I'm sorry my mistake yes 2.1.9   perhaps if I just waited it would have migrated back within the screen I haven't had time to try it again.... 

  • Richard, my solution is only provided for Opentx 2.1 and 2.2. The older Clooney82 repo has a 2.0 version. I wasn't involved in the project at that time Sorry.
  • Hi Paul

    I flew my quad yesterday W/ arducopter 3.4 and open TX 2.0... not sure what the triangular shaped thing is called on the far right in the main screen but anyway it works great except it managed to get almost %100 out of the screen. It does aim 'home' correctly. Any ideas?? Thanks

  • Hey Fnoop,

    The 2.0 master is the best one for now. I tested this just over a week ago with 2.2.0-rc11 - I didn't realise that rc12 was out already as have been away on holiday. I'll test with rc12 this week.

    Of course it works fine with 2.1.9 also.

    I re-created the wav files in the project also. Before, the project provided only the TELEM folder (to be placed inside the OpenTx /SOUNDS/en folder) which contained the additional wav files required for status text messages to be called, but as these files were only provided with the choice of Ava or Samantha voices, it meant that if you had the OpenTx sound pack installed initially, then these additional telemetry voices would not match the OpenTx voices. So to rectify this, I now also provide customised OpenTx sound packs (with some additional voice files - both OpenTx 2.1 and 2.2v6 versions) so that you can have all sounds either in Ava or Samantha. I just checked and can see that in rc12, they have released yet another sound pack version (v7), so I will need to check the differences and fix any changes to the standard voice files that have been introduced.

    Cheers, Paul

  • @Paul what is the current best version to go with - is it your master branch with opentx 2.2.0-rc12, or best to stick with 2.1.9 for now?

    I've got a lot of corruption with the status messages.  Unfortunately spending all my spare time on other projects at the moment so haven't had time to delve back into this one.

  • There's a third option I'd love to see implemented here which is to adapt these lua screens to the raw frsky telemetry output from ardupilot.  The likes of the pixracer have a dedicated port for this frsky output and includes the cable, so really all you need is the lua scripts.  This would be a great addition to the arudpilot project, I think it's almost irresponsible to fly without these telemetry screens.

    Paul Atherton said:

    Tim,

    The Teensy project is written specifically to provide Mavlink->SmartPort telemetry conversion, so only deals with the Pixhawk being configured to send out Mavlink over the telemetry port and so it is not designed as it stands to deal with the new passthru protocol. The new protocol would not actually require a teensy at all, but just a telemetry inverter, and by adding one of these and selecting the passthru protocol, as you suggest, the Taranis would see lots of new telemetry sensors, but unfortunately the LUA screens as they stand are not coded for these sensors, and to make this work, would involve a lot of research and coding, which I just don't have the time to do at this point. To be honest, this is of no practical use for my model setup in any case, as I use ULRS instead of FrSky Tx/Rx and I have the mavlink data sent over the ULRS radio link where I connect it into Mission Planner on the ground, but secondly I also have the mavlink feed on the ground connected to the teensy where it converts and feeds into the Taranis to provide the usual screens. So in my case sending down the passthrough protocol would be of no use as it would take away the Mavlink capability I would need for Mission planner.

    If you wanted to understand the passthrough protocol to develop your own LUA screens then I would suggest looking into the Ardupilot code where I believe the protocol is documented. This protocol was written by the guys at Craft & Throry to allow their commercially available LUA screens to function, so maybe that solution would be better in your case if you really want to take the passthrough protocol route.

    If you do develop something, please let us know on the forum as I would be interested in any progress.

    Cheers and good luck, Paul 


This reply was deleted.

Activity

DIY Robocars via Twitter
RT @TinkerGen_: "The Tinkergen MARK ($199) is my new favorite starter robocar. It’s got everything — computer vision, deep learning, sensor…
Monday
DIY Robocars via Twitter
Monday
DIY Robocars via Twitter
RT @roboton_io: Join our FREE Sumo Competition 🤖🏆 👉 https://roboton.io/ranking/vsc2020 #sumo #robot #edtech #competition #games4ed https://t.co/WOx…
Nov 16
DIY Drones via Twitter
First impressions of Tinkergen MARK robocar https://ift.tt/36IeZHc
Nov 16
DIY Robocars via Twitter
Our review of the @TinkerGen_ MARK robocar, which is the best on the market right now https://diyrobocars.com/2020/11/15/first-impressions-of-tinkergen-mark-robocar/ https://t.co/ENIlU5SfZ2
Nov 15
DIY Robocars via Twitter
RT @Ingmar_Stapel: I have now explained the OpenBot project in great detail on my blog with 12 articles step by step. I hope you enjoy read…
Nov 15
DIY Robocars via Twitter
RT @DAVGtech: This is a must attend. Click the link, follow link to read the story, sign up. #chaos2020 #digitalconnection #digitalworld ht…
Nov 15
DIY Robocars via Twitter
RT @a1k0n: Got a new chassis for outdoor races (hobbyking Quantum Vandal) but I totally didn't expect that it might cause problems for my g…
Nov 11
DIY Drones via Twitter
First impressions of the Intel OpenBot https://ift.tt/36qkVV4
Nov 10
DIY Robocars via Twitter
Nov 9
DIY Robocars via Twitter
Excellent use of cardboard instead of 3D printing! https://twitter.com/Ingmar_Stapel/status/1324960595318333441
Nov 7
DIY Robocars via Twitter
RT @chr1sa: We've got a record 50 teams competing in this month's @DIYRobocars @donkey_car virtual AI car race. Starting today at 10:00am…
Nov 7
DIY Robocars via Twitter
Nov 6
DIY Robocars via Twitter
RT @a1k0n: Car's view, using a fisheye camera. The ceiling light tracking algorithm gave me some ideas to improve ConeSLAM, and having grou…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: To get ground truth I measured the rug, found the pixel coordinates of its corners, calibrated my phone camera with my standard…
Nov 5
DIY Robocars via Twitter
RT @a1k0n: @DIYRobocars is back in December, but outside. Time to reinvestigate ConeSLAM! I rigged up a quick and dirty ground-truth captur…
Nov 5
More…