Adding MAVLINK support

[tomismrkolj1]

I still don't understand TmOK.
if TmOK=2 (=arduino to s.port working properly), but if all variables on telemetry screen are 0, apm is not sending data (=apm to arduino not wokring) despite TmOK=2?

tomi

[MikeB]

TmOK simply reports whether SPort (or hub) sensor data information is being sent by the receiver. Currently, the Arduino will send SPort data to the receiver, even if no data is being received from the APM.

I've found a 256 byte table that was in RAM that should be in the flash (it is in the flash anyway to be able to initialise the RAM). I've changed this to operate from the flash, so the RAM use is now 256 bytes less. There is now a much better chance this will fit in a '168.
I've posted this on the ersky9x test versions thread (viewtopic.php?f=7&t=4676).

Mike.

[LTMNO]

Mike, have you attached a compiled version of the Hex yet for APM_Mavlink_to_FrSky?
Could you just grab it from your compiled directory?
I also have a problem with compiling your folder and .ino file.

[LTMNO]

However, I did test the Teensy code with your latest ersky9X Code.
The compass works... some of the data is reporting...
If I could map out which screen variable was which data point... I could re-arrange that for you for a flavour with Teensy?
Then we can have a flavour for Arduino as I recall you saying that that would be different.
We know that the Teensy gets all the data from the APM and transmits it via SPort to the XJT.

Throttle as % (Rpm)
LiPo Battery Current (Curr)
LiPo Battery Voltage (Cels) and (Cell)
Power (Pwr)
Total mAH used (Cnsp)
Barometric Altitude (Alt)
Compass Heading (Hdg)
AccX, AccY, AccZ
Climb Rate (VSpd)
Auto Pilot Mode (Armed , Not Armed) (T2)
Analog Voltage A2 (if connected to A0 on Teensy, max 3,3V)

With GPS connected you also get:
GPS Status (Number of Satelites received, Lock Mode) (T1)
GPS Altitude (GAlt)
Groundspeed (Spd)
Latitude
Logitude
Dist from home position (Dist)

[MikeB]

I just posted the .hex I compiled and tested this morning (erksy9x test versions thread).
The values being sent by the Arduino over SPort currently are:
TEMP1 = APM mode
ALTITUDE
GPS COURSE
VFAS = main battery voltage
*BASEMODE
TEMP2 == # satellites
CURRENT
RPM = engine speed
*VCC
*CPULOAD
*HOME_DIR
*WP_BEARING
GPS LATITUDE
GPS LONGITUDE
FUEL
GPS_ALTITUDE
I've still to add other items.
Those items with a * use non-FrSky IDs
Lat. and Long. are probably in the wrong units, still to check them (I don't have a GPS).
In ersky9x I may be able to detect Teensy or Arduino depending on receiving, say, BASEMODE.
Alternatively, I could make the Arduino match the Teensy, which seems to use only standard FrSky IDs.

Mike.

[tomismrkolj1]

Hi,

I will not be able to test 16k mini pro for at least a week, since I don't have nano which has been used for programing mini pro at home any more.

I expect to get 32k version and my own FTDI programmer in 14 days. I will try also with 16k then.

tomi

[LTMNO]

I just posted the .hex I compiled and tested this morning (erksy9x test versions thread).
The values being sent by the Arduino over SPort currently are:
TEMP1 = APM mode
ALTITUDE
GPS COURSE
VFAS = main battery voltage
*BASEMODE
TEMP2 == # satellites
CURRENT
RPM = engine speed
*VCC
*CPULOAD
*HOME_DIR
*WP_BEARING
GPS LATITUDE
GPS LONGITUDE
FUEL
GPS_ALTITUDE
I've still to add other items.
Those items with a * use non-FrSky IDs
Lat. and Long. are probably in the wrong units, still to check them (I don't have a GPS).
In ersky9x I may be able to detect Teensy or Arduino depending on receiving, say, BASEMODE.
Alternatively, I could make the Arduino match the Teensy, which seems to use only standard FrSky IDs.

Mike.

Thanks Mike, I will give it a test...

[ladicek1]

Hi me and tomismrkolj1 were testing your firmware together and didn't succed with arduino mini pro 168. But I have many types of arduino., so I can test your .ino or .hex file on multiple arduinos just to see if it is the problem in RAM or not.

Ladi

[RCHH]

So far so good with the MAVLink display here with Arduino Pro Mini. But I think I have an unrelated problem (happens without any of the Arduino board connected)with control inputs all over the place preventing arming of the APM board. Will have to sort that out before continuing having a look at this.

But looking promising for sure Mike!

[RCHH]

Have everything APM issues sorted now.

Using T9X/Sky board with DHT and a D8R-SP RX. Arduino Pro Mini board with latest sketch on it.

Telemetry screen is showing, but no values are showing. Batt % = 0, No GPS in black (have 7 sats locked)hdop =99.9 flashing, RSSI showing 100 and flashing, Rcq showing 80ish and flashing. Other than those, all is zero or inoperative. Green LED on Arduino is flashing circa 1 second on/off.

Telemetry is being sent by the APM as it works fine with an OSD when connected.

Custom TmOK screen reports '2'.

[MikeB]

1 line down, under the batt %, do you have NODATA flashing, or do you see DISARM?

Mike.

[RCHH]

Ah neglected to post that! It happily shows 'Disarmed'Mike.

[MikeB]

Ok, you are getting some data then. I think I've fixed a bug relating to the number of GPS sats. Hopefully the number of sats and the GPS mode will now show.
I've posted a new test version for SKY and PRO hardware.
I've also added some debug values. There is a debug menu if, from the main screen, you go UP LONG, then RIGHT about 5 times.
This is displaying the raw values of various telemetry items.

Code: Select all

VCC        V_AMP    ALT_BARO BASEMODE
WP_DIST    HEALTH   MSG      HOME_DIR
HOME_DIST  CPU_LOAD GPS_HDOP WP_NUM  
WP_BEARING VCC      TEMP2    RPM

Do you have any values on the "GPS" telemetry display (LEFT from the new Mavlink display).

Mike.

[RCHH]

On it right now. Will post again when the new test ver is flashed.

On the screen to the left of the new one there is no info about GPS - as in Long/Lat etc?

This is looking to be a VERY useful addition! Saves me messing about with additional telemetry TX's! Can spend the money on something else now! heh heh!

[RCHH]

Flashed and running.

New Debug screen (6/10) shows all zeros except:

HOME_DIR = 005A
GPS_HDOP = 03E7
WP_BEARING = 00B4

Just a thought Mike - in the Mission Planner, there are options for setting various Telemetry protocols - (Telem1 Protocol selection Serial 1 etc.) does it need to be set (or 'can' it be set as another possibility?) to FrSky D Port, FrSky SPort or GCS MAVLInk etc?

Probably a dumb question but worth asking?

[MikeB]

I just got the same as you, when I had mission planner connected to the USB while looking at the telemetry on the 9X with SKY board.
When I ran the APM without the USB connected I got much more telemetry data.
Are you running with mission planner connected?

Mike.

[RCHH]

Up to now, with the USB connected. Will try it without in a few mins. Run out of TX batteries and having to charge them! heh heh!

Edit: Just tried without the USB connected and saw no difference. Debug screen reports the same numbers.

[MikeB]

You are almost certainly not getting any data from the APM to the Arduino. Those three values are the default values in the Arduino code. I'll ask the obvious two questions:
1. Is the APM baudrate set to 57600?
2. Does the Tx signal from the APM go to the Rx pin on the Arduino and Rx to the Arduino Tx pin?

Mike.

[RCHH]

Yes to both Mike.

[RCHH]

GRRRRRRRRRRRRRRRRRRRRRRRRRRR!!!! Found it! Brand new APM Telemetry cable ... dud! No hair left now and had way too much coffee!

Swapped out the APM for another one and it got results! Process of elimination found that miscreant cable. You have to bless fleabay lol!!!

Okies. Readings from Debug screen are thus now with USB not connected;

VCC=0031
V_AMP=006
BASEMODE=00D1 (and shows the modes selected correctly)
HOME_DIR=005A
CPU_LOAD=0058
GPS_HDOP=03E7
WP_BEARING=010E
VCC=0031
RPM=05A0

All others remain at 0000

Would that be as expected?

I have 7 GPS sats. locked in.

[MikeB]

Hmmm, Temp2 is supposed to return the number of sats and the sat. status. Maybe the Arduino isn't getting the data from the correct place. I'll investigate, but it may be a couple of hours before I'm back on this.
I assume you don't have any values on the LAT/LONG screen.

Mike.

[RCHH]

I do have some values on the LAT/LONG screen:

E = 269

and V1, 2 & 3 are showing LiPo cell voltages now for the 3 cell pack I am using.

Nothing for the co-ords, or speeds etc.

Edit: 'E' has now gone to 0 on the LAT/LONG screen.

Edit 2: 'E' has now gone back to 269 on the LAT/LONG screen.

[MikeB]

The 'E' is for East, the value after on the same line is the Heading value. On my APM I do get a value there from the on board compass. This changes as I rotate the APM board.
I need to check what the Arduino asks for, it sends some "rate" commands to the APM to get the data. I'll also need to see what data is coming from the APM. It may take a little while to set up a suitable test.

Mike.

[RCHH]

On my APM 2.5, I have disabled the onboard compass and have one up in the GPS dome.

No hurry on this Mike - take your time genius!

[MikeB]

I've just done a change to "Mavlink.cpp", which I've attached.

Mavlink.zip

(5.52 KiB) Downloaded 166 times

Instead of sending the actual value of cpu_load, this uses the the cpu_load field to send a count of the number of times the LAT/LONG values have been sent by the APM to the Arduino.
In my case, this stays at zero, but this may be because I don't have a GPS atttached to the APM.
If you could re-flash your Arduino using this source file, it will then tell me if the GPS data is getting to your Arduino.
If the cpu_load value stays at 0 for you, then it would seem the APM is not currently sending any GPS data.

Mike.

[LTMNO]

Unfortunately, I have had no success with my

Funduino Pro Mini 328/16



or

Arduino Nano 328/16


I connected the
APM -> Arduino
tx->rx
rx->tx
5v
Gnd

Arduino -> X8R
D5 -> SPort Signal
GND -> GND

[RCHH]

I've just done a change to "Mavlink.cpp", which I've attached.

Mavlink.zip

Instead of sending the actual value of cpu_load, this uses the the cpu_load field to send a count of the number of times the LAT/LONG values have been sent by the APM to the Arduino.
In my case, this stays at zero, but this may be because I don't have a GPS atttached to the APM.
If you could re-flash your Arduino using this source file, it will then tell me if the GPS data is getting to your Arduino.
If the cpu_load value stays at 0 for you, then it would seem the APM is not currently sending any GPS data.

Mike.

Done Mike. I am still seeing 0000 on CPU_LOAD, but it could be a cold start GPS. Will give it a while to 'warm' up.

In addition, I am seeing some random fleeting entries on ALT_BARO

Edit: Am now seeing 000A to 000D and FFF7 to FFF9 and FFFA to FFFB fluctuating on ALT_BARO

Edit 2: Mike, when I disconnect the GPS cable from the APM, the ALT_BARO debug codes drop to 0000. On reconnecting said cable, the values as above with FFF* instantly return. That snippet should help!

[kaos]

Mike:
I just digged out the box I put all my quad stuff.
The following are what I have, I don't have an APM board but I have a Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0 that can run Megapirate or multiwii.
pro mini 328p
Neo6M GPS
air and ground module for transmitting mavlink data to mission planner wirelessly.

of course, sky9x or ar9x Tx, DJT or DHT, don't have a XJT. Have a D4R-II as receiver.

If Megapirate or Multiwii can be used to test your work here, I will load up the hex for pro mini and megapirate final version 3.1.5 R2 (newer Megapirate moved to 32 bit processor) to help the testing.

[MikeB]

Unfortunately, I have had no success with my

Funduino Pro Mini 328/16

Arduino Nano 328/16

I connected the
Arduino -> X8R
D5 -> SPort Signal
GND -> GND

For SPort connection, did you connect D2 to ground? Otherwise it sends hub data.

The nano may have a problem as the serial output from the APM has to overcome the 1K resistor on the nano connecting to the on board FTDI chip. tomismrkolj1 has reported the same sort of problem with a nano.

Mike.

[MikeB]

kaos: If it sends Mavlink data, then it should work and worth testing if you have time.

Generally, I've taken the original code for the Arduino and used it assuming it was fully working. It may be that some things are not correct, and some things have changed on the APM. In particular, the Arduino sends a set of "Rate requests" to get the required data to be sent. From something I've read it seems this may now be an 'old' way of making this request, and that there is now a 'new' way to do this.
I'll try to capture the actual data coming from the APM and see if there is something that is now different from that which the Arduino is expecting.

Mike.