Aero FC GPS connector - baud rate and connecting 3rd party NMEA enabled GPS

trgiman commented 6 years ago

Hi. I did manage to identify TX and RX pin of GPS connector on RTF Kit. We are using sensors, that are sending NMEA message and I need to connect these into the GPS connector. We did verify that our sensors are sending NMEA message ( we can set various baud rates for our sensors). But after connecting to RTF Kit GPS connector, QGround Controll reports no GPS signal. What is the baud rate of RTF GPS connector, how to change the baud rate or how to debug the issue most effectively?

Our sensors serve as "indoor GPS" And we want to achieve same setup as described at https://www.marvelmind.com/downloads/marvelmind_pixhawk_v2016_10_11x.pdf

zehortigoza commented 6 years ago

PX4 tries all protocols that it supports in several baudrates, you will need to debug what is exactly the issue with your solution a start point would be:

VineeshKK commented 6 years ago

@trgiman: If you want to scan only for ashtech protocol, you can use the following commands in nsh. nsh> gps stop nsh> gps start -p ash

anitha-suresh-zz commented 6 years ago

@trgiman Please reopen the issue in case you need more clarification. Closing the issue for now, as there are no more questions from last few weeks.

alexis-gruet-deel commented 5 years ago

Hello, I'm re-opening this issue as I have some issues to get marvelmind working on intel-aero-rtf. I confirm that I receiving ASHTEC NMEA Message on PX4 1.8.2 when using posix_sitl_default build from my ubuntu (Marvelmind connected to USB-to-UART)

So everything is working on this side, on the RTF it's a different story ;

I've connected the RX (pin3) and GND (pin6) from GPS J3 RTF connector to TX and GND on marvelmind hedgehog board. But PX4 does not report any GPS from QGC nor Mavlink shell

My Question : How to debug incoming messages on /dev/ttyS5 ? and ensure data are well-received ?

@trgiman : I followed some of Your threads on this repo and px4 ; Do You have some clues ? can You pls confirm my setup is correct regarding the wires ? eventually some tweaks on marvel sw dashboard ? I would be grateful to have an answer.
Tks and rgds

trgiman commented 5 years ago

@Hi MI-LA01. I did manage to deliver GPS to RTF. At least selected parts of NMEA messages which include location etc.

You have to modify Ashtech driver protocol in PX4 firmware. Not dramatically, but by default it is expecting different number of items compared to what MM is sending. This is due to the fact of flexibility of NMAE standard.
Mm is sending several types of NMEA gps messages( check in the dashboard setting). You will need to pick up the right one. Just pay attention to the fact that down the road px4 will need xyz coordinates and velocity info to make the drone fly.
You can also switch to ArduPilot, in AP driver is communicating correctly.

I am sorry but RTF is no longer focus of the project. Unfortunatelly I do no longer have modified versions n of PX4 driver. Hope it helps a bit

alexis-gruet-deel commented 5 years ago

Hi @trgiman, Thanks for Your time and quick answer. I finally got to know how to connect MM on the RTF. I followed Your suggestions and tweaked the ashtech.cpp file. I receive now from MM on PX4 this message (12hz on MM)

nsh> gps status
INFO  [gps] Main GPS
INFO  [gps] protocol: ASHTECH
INFO  [gps] port: /dev/ttyS5, baudrate: 115200, status: OK
INFO  [gps] sat info: disabled
 vehicle_gps_position_s
    timestamp: 769329171 (0.045909 seconds ago)
    time_utc_usec: 0
    lat: 386799865
    lon: -93399870
    alt: -1460
    alt_ellipsoid: 0
    s_variance_m_s: 0.000
    c_variance_rad: 0.100
    eph: 0.000
    epv: 0.000
    hdop: 1.200
    vdop: 0.000
    noise_per_ms: 0
    jamming_indicator: 0
    vel_m_s: 0.051
    vel_n_m_s: -0.042
    vel_e_m_s: 0.029
    vel_d_m_s: 0.000
    cog_rad: 2.539
    timestamp_time_relative: -769329171
    fix_type: 3
    vel_ned_valid: 1
    satellites_used: 8
INFO  [gps] rate position:        7.23 Hz
INFO  [gps] rate velocity:        7.23 Hz
INFO  [gps] rate publication:         7.23 Hz
INFO  [gps] rate RTCM injection:      0.00 Hz

The RTF accept the flight mode position ; However, the drone is not stable when hovering, forcing me to land after 2 secs flying.

My last questions (I promess) ;

Did You ever achieved good results w/ MM on RTF using the flight mode position ?
Based on the output above, do You think the message received by ashtech.cpp is well formed ? (# GPGTV is enabled on MM in addition to the "fuse IMU for speed in NMEA enabled" ; giving a "track true" and ground_speed in knots)

On PX4, config, nothing crazy : EKF2_AID_MASK is set to GPS only

Thanks again and wish You all the best. rgds a

Marvelmind output;

trgiman commented 5 years ago

Hi @MI-LA01,

没问题我很高心帮你！ :-)

I had the same issue. North and East values velocity values are provided within message,but Down to Earth message is not provided.I believe EKF alg in PX4 needs it.

    vel_m_s: 0.051
vel_n_m_s: -0.042
vel_e_m_s: 0.029
**vel_d_m_s: 0.000**

Therefore I was trying to send 2 messages from MM

1th that included values above and
2nd second that gave me also vel_d_m_s value, which you have currently 0.
Also check if knots are converted to m/s in Ashtech drive code

But due to some formatting issue? in PX4 ashtech drive serial port read I had problems to read both messages. I would be very curious if you will solve this issue.

Well and at that stage I decided to take other approach with PX4Flow and Lidar (as I was not in need of exact coordinates) - that approach was a success but again no exact coordinates.

alexis-gruet-deel commented 5 years ago

Thks again for Your fast answer!

"in PX4 ashtech drive serial port read I had problems to read both messages. I would be very curious if you will solve this issue."

Yes I've fixed it however, not proud of myself. In GpsDriverAshtech::receive()

/*
 *  Added found sentences (At least 2 $GPGGA + $GPVTG) 
 * 
 *  This will force the bytes to be read till the end 
 *     - MM GPGGA sentence return ~75 bytes
 *     - MM GPVTG sentence return  ~35 bytes
 *     - parseChar will return the first message (75 bytes read ; later in the process this will be ignore by the return after handleMessage()) ; 
 * 
 *  The trick consist to force all bytes to be read before returning 1
 *
 */
int found = 0;

ssize_t bytes_count = 0;

while (true) {

        /* pass received bytes to the packet decoder */
        while (j < bytes_count) {
                int l = 0;

                if ((l = parseChar(buf[j])) > 0) {
                        /* return to configure during configuration or to the gps driver during normal work
                         * if a packet has arrived */
                        if (handleMessage(l) > 0) {
                                found++;                
                                /* Found two messages ($GPGGA + $GPVTG) - we can now return. */
                                if(found == 2) {
                                    return 1;
                                }
                        }
                }

                j++;
        }

found == 2 means ; 2 sentences where read, next iteration can then occur.

The Good : We catch all data from GPGGA and GPVTG once.
The Bad : Don't know what's going on if MM don't send those data or crap sentences.

I observed the same thing for vel_d_m_s however, I'm not sure where to find this parameter from MM sentences.. any clues ?

anyway, will review all $GP sentences from MM to find it. I keep You post :)

alexis-gruet-deel commented 5 years ago

Well, I've inspected all sentences including : ZDA, GGA, VTG, RMC but can't find any occurrences of Vertical velocity aka vel_d_m_s in PX4.

@trgiman : Do You remember the sentences holding this value in MM ? rgds a

trgiman commented 5 years ago

Hi @MI-LA01 ,

Unfortunately if I remember correctly, MM is not sending vertical velocity via GPS messages. But if we would know the angle of drone pitch. It could be calculated by trigonometry formula? Considering facts:

velocity = acceleration x time
acceleration down towards earth is 9.8 m/s^2
CB = 9.8 m/s^2 x sin(theta)

theta is in degrees. Assume that drone is in point C. When hovering in C vertical velocity is 0. I believe that vel_ms: 0.051 is representing BA vector. C //| // |
// | B A

Not sure if I have correct understanding of the situation. Also I noted, that you have to flip the orientation in MM Dashboard since current altitude is negative alt: -1460. There is an setting in the Menu of the dashboard.

Good luck.

malfonsoNeoris commented 5 years ago

Hi there... any advance on connecting the marvelmind to aero? i am starting with this.. and cannot connect. i have compiled px4 v1.82 and ardupilot 3.67 but cant communicante in any any advice? thanks?

alexis-gruet-deel commented 5 years ago

On Ardupilot don't know, On PX4 i was able to get NMEA messages from a custom driver that I wrote for this (px4/gpsdriver) however ekf estimator need vertical velocity and marvelmind NMEA don't send this information. I tend to think that a custom driver implementing the native Marvelmind protocol as described in their doc should do the trick as all data could be exposed, then something tricky connect it to the ekf estimator.

intel-aero / meta-intel-aero

Aero FC GPS connector - baud rate and connecting 3rd party NMEA enabled GPS #303