APM MavLink to FrSky X8R S.Port converter

Replies

- - Ben James > Paul Atherton December 31, 2015 at 8:07am
    
    OK, thanks Paul, appreciate your advice.
- Ben James > Ben James December 31, 2015 at 7:40am
Brandon Brown December 29, 2015 at 8:36pm

should i be updating my mission planner? i see 3.35 is out now. Would it affect the lua script im running now if i did?
- Paul Atherton > Brandon Brown December 31, 2015 at 7:27am
  
  Mission Planner has nothing to do with the LUA script on your Taranis. I always keep up with the latest version.
Paul Atherton December 28, 2015 at 5:36am

As far as the Cloney82 2.1 Master branch of the MavLink_FrSkySPort code, I have nearly all of the LUA screen functioning correctly - all apart from the radar display. In the radar, I do not have a moving pointer, either for heading or movement from the centre. I also only see 0m in the radar, to suggest that the craft is still in its armed location. So nothing in this panel is updating. Can anyone else running the current 2.1 code please advise if they have this radar display working?

I realise that the radar display acts upon two telemetry inputs. One is the "GPS" coordinate table itself, and the other is the heading value, read from "Hdg". I can see on the telemetry sensor page on the Taranis that both these values are being received from the X8R and being updated in real-time, and also see the heading value displayed on the telem1.lua screen, but the arrow does not move (even when armed) to reflect the Hdg - prearm heading offset as it should. And the arrow stays centred and pointing forward. I created a LUA page of my own to test the incoming GPS data, and my code suggests that the Teensy is not sending the GPS coordinates in a properly formatted table. If this is correct, then this would suggest why the pointer does not move away from center in the radar. This is my code for anyone wanting to take a look:

local gpsValueLat = "unknown"
local gpsValueLon = "unknown"

local function rnd(v,d)
if d then
return math.floor((v*10^d)+0.5)/(10^d)
else
return math.floor(v+0.5)
end
end

local function getTelemetryId(name)
field = getFieldInfo(name)
if field then
return field.id
else
return -1
end
end

local function init()
gpsId = getTelemetryId("GPS")
end

local function background()
gpsLatLon = getValue(gpsId)
if (type(gpsLatLon) == "table") then
gpsValueLat = rnd(gpsLatLon["lat"],4)
gpsValueLon = rnd(gpsLatLon["lon"],4)
end
end

local function run(event)
if (type(gpsLatLon) == "table") then
lcd.clear()
lcd.drawText(1,1,"Lat: " .. gpsValueLat,MIDSIZE)
lcd.drawText(1,20,"Lon: " .. gpsValueLon,MIDSIZE)
else
lcd.clear()
lcd.drawText(1,1,"no data yet",MIDSIZE)
end
end

return {run=run}

Sorry, its not easy to paste code in here, so I have attached the lua file also. All that is displayed is "no data yet", which suggests that the data provided in the GPS sensor is not formatted as type "table", as this data is provided by the Teensy code, this would suggest there lies the issue. Maybe Clooney or Wolke can comment?

Cheers all, Paul

gps2.lua

Clooney82/MavLink_FrSkySPort

This MavLink_FrSkySPort repository is discontinued! The development is moved to athertop/MavLink_FrSkySPort. Please do not use this repo, and follow…
- Kevin Guest > Paul Atherton December 28, 2015 at 6:33am
  
  It works for me and I did nothing special.
  
  Did you discover the GPS sensor correctly on your Taranis? Do you have GPS listed as a sensor and does it have a flashing star next to it when you should be receiving data? I question this as I think if you are discovering sensors when GPS is not available, like no 3d fix, then the sensor will not discover correctly.
  
  Kev
  - Paul Atherton > Kevin Guest December 28, 2015 at 6:53am
    
    Kevin,
    
    Thanks very much for your response. Now I know its my setup I have a way forward.
    
    Yes I have GPS listed - it is configured exactly as per Clooney's instructions here:
    
    https://github.com/Clooney82/MavLink_FrSkySPort/wiki/1.2.1-Telemetr...
    
    and I can see it being updated (flashing star etc), it displays a 5 digit numeric. Is this the same in your case? in OpenTX companion, it is displayed with the units set to Raw - is this the same as you have yours? The reason I ask is that Clooney's Wiki page says 'tbd' for 'unit of measure'.
    
    Can I please ask, just to confirm that you are using the current OpenTx 2.1 version? (mine is 2.1.6) Plus are you running APM 3.3 ? (I am running 3.3.2 - the latest quad version). Just trying to see if there are any differences which may explain my issue.
    
    Thanks again and hopefully speak soon, Paul
    - Paul Atherton > Paul Atherton December 28, 2015 at 8:05am
      
      I have just done some more testing, and I made a mistake in my original assertion that the arrow does not turn to reflect the heading. This does in fact work just fine on my setup so it appears. It is solely the distance counter, and the fact the arrow should move off centre in the radar window to reflect where the craft is located (in relation to the centrre/arming position), which is not working on my setup.
      
      So just to reiterate - the arrow head does change its angular direction, but it does not move from the centre of the radar when the craft flies away from its launch position, and neither does the distance reading change from 0m.
      
      Kevin, Can you please clarify if all these features work on your's?
      
      Thanks again, Paul
      - Kevin Guest > Paul Atherton December 28, 2015 at 8:48am
        
        Yes, I am using OpenTx, I'm just running some test now to see what the GPS is giving me, I wont get anything until it gets a true lock - maybe 10 mins in my workshop :(.
        
        In companion, when I look at the GPS sensor it is set as Custom, Id 800, Instance 4.
        
        I'm using Companion 2.1.6, I'm using OpenTx 2.1.5 EU version. EU version did make a difference on another similar project but it was to do with timing and it caused the sensor not to auto detect. I dont think this is our difference.
        
        I'm using APM:Copter v3.2.1, I've not tested it with v3.3.
        
        My arrow changes direction and place within the square, location relative to the pilot. in fact as it hits the edge of the square it will jump back a bit so it can continue to move towards the edge etc.
        
        I'm sure the distance was changing, I do have an issue on the top bar with distance, it keeps jumping from 0m to some huge number, not had time to look at that yet.
        
        While typing I got GPS lock, on the sensor page with all other sensors GPS reads 1 16'w 53 25'N, it also reads like that if I go to edit the sensor.
        
        If it was me I would use mission planner to check you have a good GPS lock and position. Then delete either the GPS sensor or all sensors and rediscover them.
        
        Kev
        
        Paul Atherton > Kevin Guest December 30, 2015 at 1:04pm
        
        Kevin,
        
        You are a star! Your advice fixed my issue. It appears that its not possible to manually create a GPS sensor, either directly in the Radio or on Companion - if you do, then it does not format it correctly, and there is no specific formatting for GPS coordinates. Like you said, the only way to do this and have it work is have the radio discover the GPS sensor itself. I did this and now the radar display is working perfectly. This is the first time I have seen this work on OpenTx2.1 and APM 3.3.2. I have asked Clooney if he will update the Wiki to reflect this configuration requirement.
        
        Thanks again, Paul.

of 186

Discussions

APM MavLink to FrSky X8R S.Port converter

Replies

Activity