Replies

      • Hi Glenn,

        that what i imagine, something like that, but i don't have skills in coding :-(

        i can confirm that you can access to the Storm3 param via MP ( parameter tree), as say OlliW you can make change, but not stored by the end,that should change in next future, if i well understand.

        i'll have a look on the idea of same System ID and different component ID, i saw that on the ardu code but not sure about the storm (there's no reasons)

        thanks for you answer and investigation! naturally, i'm volunteer for test.

        @Luis:

        don't have to much flight with the last rc4 (none, to be honest) but with the rc3 some, and i don't see any difference on my Taranis.i could be wrong, i don't really have the time, in this moment, to fly :-(

        Do you really think that the Mavlink on 3.3(final or 3.4) and the OpenTX2.1 are going at light years of the present? candid question, don't have time to follow the OpenTX dev, but crazy about to use it ;-)

        • @Vic 33

          The changes on OpenTX 2.1 are very significant regarding the telemetry (complete refactoring), and break everything :). 


          a few notes about the telemetry

          A few keypoints of the result:

          • Each value sent down is treated as a separate "sensor" with its own properties (unit, decimal precision, ratio/offset) and options (auto offset, filtering, persistent storage at power off, logging enabled). Each sensor has its own user-defined name and keeps track of its own min/max value.
          • In the case of the FrSky system, these sensors are auto-discovered anytime the radio and receiver/sensors are powered up.
          • Sensors can be duplicated, so for example a given value e.g. altitude from the same vario sensor can be displayed/announced/logged simultaneously in different units, or with different options (absolute altitude and altitude above start point with auto or manual offset,...)
          • Multiple physical sensors returning the same value are supported as long as there is a way to differentiate them. With the FrSky S-port system it means you can connect any number of identical sensors as long as you make sure to change the IDs of sensors with the FrSky SBUS servo channel changer (SCC) as required so each ID is unique in the smart port chain (explained in the sensor's and SCC's manuals). If you want to measure individual motor currents of your octocopter with 8 FCS-40A sensors, no problem. 
          • "Calculated" virtual sensors can be manually created to combine values or extract extra data. Values can be added, averaged or multiplied, the minimum or maximum of a set of up to 4 values van be extracted. This also takes care of "special cases" like calculating GPS distance (2D or 3D), getting the value of a particular cell of a lipo cell sensor, calculating mAh consumption etc. For example Power can be calculated easily by multiplying the related voltage and current, total voltages of multiple lipo cell sensors can be added to get the total voltage of series-wired packs, the minimum cell of each of them can be extracted and the lowest of all can be found using the Minimum function.
          • Each sensor can be reset individually with a special function, so no more losing all your min/max values when you just want to reset altitude offset to start point.

          http://openrcforums.com/forum/viewtopic.php?f=45&t=6887

          • waahou!

            ok thanks for the informations.

            I'm going to cry a little, and back again.

      • The Teensy parsing code must be revised for the 3.3 release (3.3 is still Release Candidate). But considering that also OpenTX 2.1 is near completion and changes the telemetry system, I believe is best to wait....

        Luis

        • The teensy/lua code (I'm using the wolke branch) works perfectly for me on 3.3rc code except for the storm32 issue.

          Looking forward to seeing the new opentx 2.1 telemetry.

          • You think it does, and it appears it does, but it doesn't :)

            Just a small example. There is a new flight mode on 3.3 which is not captured (yet) by the parser....

            • Yes granted it won't support the new features, error message formats etc, but it works just great for basic usage.  The rapidly switching flight mode is a real PITA - I've had to rename the sounds directory to shut it up for now and it makes the direction arrow unuseable as well - if someone can make a quick patch to filter a single system ID that would be great.

              Thanks to everyone who has contributed to this teensy/frsky system, it really is awesome.

              • The error codes.... ah.... that's another issue :)

                Have you tried to "manipulate" the Storm32 SystemID ?

                Luis

                • I just tried setting the systemid to 1 (in the storm32 config) instead of 71 and kept the component id as 67, but it didn't help the teensy telemetry, I still get flashing mode changes on the tx screen, and then the pixhawk couldn't control the gimbal anymore - it must be hardcoded to talk to systemid 71 maybe.

                  wolke pretty please, could you possibly put a filter in your code to just listen to a single systemid?

  • you do not have to buy this adapter. you need to google up APM code adjustment - you can reflash UART chip in the APM to understand SBUS. It can work directly with no issues.

This reply was deleted.

Activity

DIY Robocars via Twitter
How to use the new @donkey_car graphical UI to edit driving data for better training https://www.youtube.com/watch?v=J5-zHNeNebQ
yesterday
DIY Robocars via Twitter
RT @SmallpixelCar: Wrote a program to find the light positions at @circuitlaunch. Here is the hypothesis of the light locations updating ba…
Saturday
DIY Robocars via Twitter
RT @SmallpixelCar: Broke my @HokuyoUsa Lidar today. Luckily the non-cone localization, based on @a1k0n LightSLAM idea, works. It will help…
Thursday
DIY Robocars via Twitter
@gclue_akira CC @NVIDIAEmbedded
Nov 23
DIY Robocars via Twitter
RT @luxonis: OAK-D PoE Autonomous Vehicle (Courtesy of zonyl in our Discord: https://discord.gg/EPsZHkg9Nx) https://t.co/PNDewvJdrb
Nov 23
DIY Robocars via Twitter
RT @f1tenth: It is getting dark and rainy on the F1TENTH racetrack in the @LGSVLSimulator. Testing out the new flood lights for the racetra…
Nov 23
DIY Robocars via Twitter
RT @JoeSpeeds: Live Now! Alex of @IndyAChallenge winning @TU_Muenchen team talking about their racing strategy and open source @OpenRobotic…
Nov 20
DIY Robocars via Twitter
RT @DAVGtech: Live NOW! Alexander Wischnewski of Indy Autonomous Challenge winning TUM team talking racing @diyrobocars @Heavy02011 @Ottawa…
Nov 20
DIY Robocars via Twitter
Incredible training performance with Donkeycar https://www.youtube.com/watch?v=9yy7ASttw04
Nov 9
DIY Robocars via Twitter
RT @JoeSpeeds: Sat Nov 6 Virtual DonkeyCar (and other cars, too) Race. So bring any car? @diyrobocars @IndyAChallenge https://t.co/nZQTff5…
Oct 31
DIY Robocars via Twitter
RT @JoeSpeeds: @chr1sa awesomely scary to see in person as our $1M robot almost clipped the walls as it spun at 140mph. But it was also awe…
Oct 29
DIY Robocars via Twitter
RT @chr1sa: Hey, @a1k0n's amazing "localize by the ceiling lights" @diyrobocars made @hackaday! It's consistently been the fastest in our…
Oct 25
DIY Robocars via Twitter
RT @IMS: It’s only fitting that @BostonDynamics Spot is waving the green flag for today’s @IndyAChallenge! Watch LIVE 👉 https://t.co/NtKnO…
Oct 23
DIY Robocars via Twitter
RT @IndyAChallenge: Congratulations to @TU_Muenchen the winners of the historic @IndyAChallenge and $1M. The first autonomous racecar comp…
Oct 23
DIY Robocars via Twitter
RT @JoeSpeeds: 🏎@TU_Muenchen #ROS 2 @EclipseCyclone #DDS #Zenoh 137mph. Saturday 10am EDT @IndyAChallenge @Twitch http://indyautonomouschallenge.com/stream
Oct 23
DIY Robocars via Twitter
RT @DAVGtech: Another incident: https://t.co/G1pTxQug6B
Oct 23
More…