# Invalid local position Source: https://forum.modalai.com/topic/371/invalid-local-position Category: General Questions (https://forum.modalai.com/category/2/general-questions) Posted: 2021-08-02 15:02:42 UTC by DillonAllen Replies: 29 · Views: 10230 ## DillonAllen · 2021-08-02 15:02:42 UTC 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! ## Reply by Guest · 2021-08-02 15:27:16 UTC 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? ## Reply by DillonAllen · 2021-08-02 15:36:41 UTC 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% ``` ## Reply by Guest · 2021-08-02 15:42:29 UTC 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. ## Reply by DillonAllen · 2021-08-02 15:46:46 UTC 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% ``` ## Reply by Guest · 2021-08-02 15:54:49 UTC Are you still not getting localization data? ## Reply by DillonAllen · 2021-08-02 15:58:04 UTC Still getting invalid local position data ## Reply by DillonAllen · 2021-08-02 16:10:06 UTC 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> ``` ## Reply by Guest · 2021-08-02 16:16:45 UTC Do you see data from ```voxl-inspect-qvio``` ## Reply by DillonAllen · 2021-08-02 16:33:30 UTC 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 | ``` ## Reply by Guest · 2021-08-02 16:43:29 UTC 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. ## Reply by DillonAllen · 2021-08-02 16:47:44 UTC 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 ``` ## Reply by Guest · 2021-08-02 17:19:37 UTC Yeah that all looks fine, but there's no data in the local_position_ned or either of the odometry messages? ## Reply by DillonAllen · 2021-08-02 17:23:01 UTC In QGC I only have the ODOMETRY data, but there is no local_position_ned tab if that is what you're referring to. ## Reply by Guest · 2021-08-02 17:24:36 UTC And what happens if you try to put it in position mode? ## Reply by DillonAllen · 2021-08-02 17:30:13 UTC It just tells me "REJECT POSITION CONTROL" ## Reply by Guest · 2021-08-02 17:59:41 UTC 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. ## Reply by DillonAllen · 2021-08-02 18:08:52 UTC 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 ## Reply by Guest · 2021-08-02 18:39:04 UTC We noticed that your EKF2 Aid mask is different from what we usually run, did you install the voxl px4 parameters file as [here](https://docs.modalai.com/upload-px4-parameters/) or did you create your own? Can you try to run with our default parameters file and see what happens? ## Reply by DillonAllen · 2021-08-02 18:47:25 UTC 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. ## Reply by DillonAllen · 2021-08-03 18:25:05 UTC So I've tried completely resetting the parameters on the drone back to factory and reloading all of the parameters again, but I am still getting invalid local position data. Also as a small side note, should the tracking camera be inverted? (for example, I move an object from the top of the tracking camera and it shows up from the bottom on the feed) ## Reply by Chad Sweet (ModalAI staff) · 2021-08-03 20:14:46 UTC Do you have a magnetometer connected? We have seen this issue when the px4 ekf doesn't initialize due to missing sensor ## Reply by Cliff Wong (ModalAI staff) · 2021-08-03 20:27:47 UTC Hi Dillion--the *reject control* on mode switching is from having GPS activated (sounds like you don't have a 3D fix) considering your aid mask is *329*. For vio-only flight, the parameters should be this:![start-vio.png](https://forum.modalai.com/assets/uploads/files/1628022019688-start-vio.png) If that does not solve it, you'll need to confirm in QGC's nuttx shell that vio message data is getting to PX4: * In QGC, goto the [mavlink console] under [analysis tools], press [enter] to get a nuttx prompt * type "*uorb top vehicle_visual_odometry*" [enter] * confirm you're getting similar rates like this (key is the rate column) ``` TOPIC NAME INST #SUB RATE #Q SIZE vehicle_visual_odometry 0 1 30 1 256 vehicle_visual_odometry_aligned 0 0 15 1 256 ``` That will confirm vio data is being processed directly in PX4's EKF module. If not, we'll need to have you setup the video overlay to verify vio data itself (aka verify a mavlink issue). ## Reply by DillonAllen · 2021-08-03 22:33:59 UTC Since we are attempting to preforming indoor flight using VIO I had disabled the SYS_HAS_MAG and the GPS_1 config like it says in the quickstart guide, so for this reason I didn't have the GPS and magnetometer plugged in. Once I plugged in the GPS and magnetometer the drone had valid position data and we were able to actually fly the drone. The problem now is that when we flew it (which was outside in the sun which might have caused problems) the drone would take off in position mode very nice for about 5 seconds then it would start to freak out and flying more sporadically which is when we would land the drone. Is this due to the drone being flown outside is the sun or is this some type of calibration issue? ## Reply by Chad Sweet (ModalAI staff) · 2021-08-04 02:51:36 UTC Hi Dillon, You can initialize properly without mag, but you'll need a ModalAI firmware image on the Flight Core. You can see the v1.10 and 1.11 images [here](https://docs.modalai.com/flight-core-firmware/) I found the SYS_HAS_MAG reference in the [calibrate cameras](https://docs.modalai.com/px4-calibrate-sensors/) page where it also references needing the firmware. I could not find it in a quickstart though. If you have a pointer to that page we would like to make sure it correctly calls out the custom firmware as well as it could be an oversight on our end. The firmware we shipped the unit with would support this, so maybe you upgraded through QGC or something. ## Reply by Chad Sweet (ModalAI staff) · 2021-08-04 02:55:45 UTC To debug VIO, there are a number of different tools: 1. Monitor in QGC as shown [here](https://docs.modalai.com/flying-with-vio/) 2. Use [voxl-inspect-qvio](https://docs.modalai.com/voxl-inspect-qvio/) 3. Monitor on qvio overlay (still to be documented [here](https://docs.modalai.com/voxl-qvio-server/)) ## Reply by Chad Sweet (ModalAI staff) · 2021-08-04 03:13:23 UTC This is all assuming you have not modified the location of your tracking camera relative to the IMU. Are you using the Flight Deck mechanical configuration exactly, or has it been modified? ## Reply by DillonAllen · 2021-08-04 15:12:41 UTC The only thing that we have really modified is the forward distance from the center of gravity which should only be a slight difference. I remember seeing something about changing that in the T_stereo_wrt_body in the voxl-vision-px4 for the collision detection to match the distance from the center of gravity, but that setting does not show up when I look at the voxl-vision-px4, is that what I would need to change to help stabilize my flights? ## Reply by DillonAllen · 2021-08-05 15:07:23 UTC Am I going to have to add those IMU settings to the voxl-vision-px4.conf like "R_imu_to_body" and "T_imu_wrt_body"? I believe that I'm using the IMU1 but I'm also no sure how to check and see which one is in use currently. ## Reply by alarm_hq · 2021-12-09 19:42:51 UTC (in reply to Cliff Wong) I found the QGC EKF2_AID_MASK parameter settings above (configuring to 280: Vision position fusion, vision yaw fusion, vision velocity fusion) to allow the seeker to enter position and off-board modes. Prior to configuring, QGC was receiving VIO but was still unable to enter position mode as referenced [here](https://docs.modalai.com/flying-with-vio/#confirm-px4-is-getting-vio-data) To make the forum search engine happy: seeker position mode rejected