Invalid local position



  • Hi, I think I'm pretty close to getting my drone to fly with VIO using the Flight Deck, the only problem is that I am not getting valid local position data.

    nsh> ekf2 status
    INFO  [ekf2] local position: invalid
    INFO  [ekf2] global position: invalid
    INFO  [ekf2] time slip: 0 us
    ekf2: update: 9845 events, 56720us elapsed, 5.76us avg, min 1us max 62us 3.990us rms
    nsh> 
    

    The quickstart says to update the ECL but I'm unsure of how to go about doing that. I'm on the latest system image and I've updated the voxl suite to the latest version.
    Thank you for your help!


  • Dev Team

    Hi Dillon,

    What services are running? The required ones for flying with VIO are voxl-camera-server, voxl-imu-server, voxl-qvio-server, and voxl-vision-px4. Can you paste the output of voxl-inspect-services here?



  • Here are the services that are currently running:

    yocto:/$ voxl-inspect-services
     Service Name        |  Enabled  |   Running   |  CPU Usage
    --------------------------------------------------------------
     docker-autorun      | Disabled  | Not Running | Not Running
     docker-daemon       | Disabled  | Not Running | Not Running
     modallink-relink    | Disabled  | Not Running | Not Running
     voxl-camera-server  |  Enabled  | Not Running | Not Running
     voxl-cpu-monitor    |  Enabled  |   Running   |   0.0%
     voxl-dfs-server     |  Enabled  |   Running   |   1.7%
     voxl-imu-server     |  Enabled  |   Running   |   1.3%
     voxl-modem          | Disabled  | Not Running | Not Running
     voxl-qvio-server    |  Enabled  |   Running   |   0.0%
     voxl-streamer       | Disabled  | Not Running | Not Running
     voxl-tag-detector   |  Enabled  | Not Running | Not Running
     voxl-tflite-server  |  Enabled  |   Running   |   0.0%
     voxl-time-sync      | Disabled  | Not Running | Not Running
     voxl-vision-px4     |  Enabled  |   Running   |   1.8%
    

  • Dev Team

    There's the problem, voxl-camera-server is not running. Since it's enabled (and I'm assuming that you didn't stop it yourself) it probably aborted. This is usually due to a hardware issue with one of the camera cables. Can you now paste the output of journalctl -u voxl-camera-server to see what the logs for camera server say.



  • Okay, While I was waiting for your reply I went ahead and checked all of the cables and unplugged and re-plugged all of the cameras on the board and now I am getting this from the services:

     Service Name        |  Enabled  |   Running   |  CPU Usage
    --------------------------------------------------------------
     docker-autorun      | Disabled  | Not Running | Not Running
     docker-daemon       | Disabled  | Not Running | Not Running
     modallink-relink    | Disabled  | Not Running | Not Running
     voxl-camera-server  |  Enabled  |   Running   |   7.5%
     voxl-cpu-monitor    |  Enabled  |   Running   |   0.0%
     voxl-dfs-server     |  Enabled  |   Running   |  10.0%
     voxl-imu-server     |  Enabled  |   Running   |   1.9%
     voxl-modem          | Disabled  | Not Running | Not Running
     voxl-qvio-server    |  Enabled  |   Running   |   2.2%
     voxl-streamer       | Disabled  | Not Running | Not Running
     voxl-tag-detector   |  Enabled  |   Running   |   4.1%
     voxl-tflite-server  |  Enabled  |   Running   |   0.0%
     voxl-time-sync      | Disabled  | Not Running | Not Running
     voxl-vision-px4     |  Enabled  |   Running   |   2.0%
    

  • Dev Team

    Are you still not getting localization data?



  • Still getting invalid local position data



  • Heres the output from QGC:

    nsh> ekf2 status
    INFO  [ekf2] local position: invalid
    INFO  [ekf2] global position: invalid
    INFO  [ekf2] time slip: 0 us
    ekf2: update: 8677 events, 49546us elapsed, 5.71us avg, min 1us max 94us 4.090us rms
    nsh> listener vehicle_visual_odometry
    
    TOPIC: vehicle_visual_odometry
     vehicle_odometry_s
        timestamp: 431364179  (297.960915 seconds ago)
        timestamp_sample: 431346994  (17185 us before timestamp)
        x: -682.8690
        y: -951.3774
        z: -868.9987
        q: [0.9878, -0.0083, 0.0614, -0.1428]
        q_offset: [0.0000, 0.0000, 0.0000, 0.0000]
        pose_covariance: [nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan]
        vx: 0.0002
        vy: 0.0009
        vz: -0.0032
        rollspeed: 0.0095
        pitchspeed: 0.0000
        yawspeed: 0.0000
        velocity_covariance: [nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan, nan]
        local_frame: 1
        velocity_frame: 3
    nsh> 
    

  • Dev Team

    Do you see data from voxl-inspect-qvio



  • Yes, but it is very iffy, when I have it sitting on my desk and move it around all of the data changes like it should, but then when I move it to the floor or vice versa then it will start giving me the LOW_FEATURES error

     T_imu_wrt_vio (m)   |Roll Pitch Yaw (deg)| state| error_code
       -0.02   -0.01   -0.07|   0.2    0.4    0.2| OKAY | 
    

  • Dev Team

    Yeah it'll be unstable when its being moved around like that, it's meant to have the service start at the takeoff location and then track initial features on the floor/wall during takeoff. However, this does show that localization data is coming from the VIO service, so the problem is further down the line.

    The two things to look at now are the vvpx4 config file at cat /etc/modalai/voxl-vision-px4.conf and make sure that the QGC stuff is set up properly, and that en_vio and send_vio_to_qgc are both set to true.

    If all of that looks good, then you should run voxl-inspect-pose vvpx4_body_wrt_local to see if the voxl-vision-px4 service is getting the localization data peroperly.



  • I believe that I have the voxl-vision-px4 setup correctly for QGC, here is the conf file:

    yocto:/$ cat /etc/modalai/voxl-vision-px4.conf
    /**
     * VOXL Vision PX4 Configuration File
     *
     */
    {
    	"qgc_ip":	"192.168.8.20",
    	"en_localhost_mavlink_udp":	true,
    	"en_secondary_qgc":	false,
    	"secondary_qgc_ip":	"192.168.1.214",
    	"qgc_udp_port_number":	14550,
    	"localhost_udp_port_number":	14551,
    	"udp_mtu":	512,
    	"en_vio":	true,
    	"en_voa":	false,
    	"en_send_vio_to_qgc":	true,
    	"en_send_voa_to_qgc":	false,
    	"en_set_clock_from_gps":	true,
    	"en_force_onboard_mav1_mode":	true,
    	"en_reset_px4_on_error":	true,
    	"qvio_auto_reset_quality":	0.00050000002374872565,
    	"en_adsb":	false,
    	"adsb_uart_bus":	7,
    	"adsb_uart_baudrate":	57600,
    	"px4_uart_bus":	5,
    	"px4_uart_baudrate":	921600,
    	"offboard_mode":	"figure_eight",
    	"follow_tag_id":	0,
    	"en_tag_fixed_frame":	false,
    	"fixed_frame_filter_len":	5,
    	"en_transform_mavlink_pos_setpoints_from_fixed_frame":	false
    }
    

    And here is the output for voxl-inspect-pose vvpx4_body_wrt_local:

    timestamp(ms)|     Position (m)     | Roll Pitch Yaw (deg) |    Velocity (m/s)    | angular rate (deg/s) |
          153336 |   0.00  -0.01  -0.09 |   -0.6   11.0   -0.2 |  -0.00   0.00   0.00 |  -0.00  -0.03   0.01 
    

  • Dev Team

    Yeah that all looks fine, but there's no data in the local_position_ned or either of the odometry messages?



  • In QGC I only have the ODOMETRY data, but there is no local_position_ned tab if that is what you're referring to.


  • Dev Team

    And what happens if you try to put it in position mode?



  • It just tells me "REJECT POSITION CONTROL"


  • Dev Team

    I've asked some of our px4 experts what their thoughts are, can you share your px4 params file so we can see what's going on there since this seems to be a px4-side issue.



  • I couldn't figure out how to share the file through here, so I uploaded them to a drop box:
    https://www.dropbox.com/s/7kxknquutoav00i/PX4_Param_Voxl.params?dl=0


  • Dev Team

    We noticed that your EKF2 Aid mask is different from what we usually run, did you install the voxl px4 parameters file as here or did you create your own? Can you try to run with our default parameters file and see what happens?



  • I ran the parameters from the quickstart guide, I also ran the indoor_VIO helper and just changed the aid mask to fit was in the quickstart guide. I reverted it back to its original settings and the drone is still having the same problems.


Log in to reply