adb is not working after tflite deployment.
-
@tom Thank you for your reply, but that didn't work,
$ adb kill-server $ adb shell * daemon not running; starting now at tcp:5037 * daemon started successfully error: no devices/emulators foundWe tried with different computers, and still not working.
-
Hey @tom, I could really use your help with this. We're working on a project with tight deadlines, and I was wondering if you could assist us in fixing the issue. It would be awesome if you could provide virtual support. I really appreciate any help you can provide.
-
@bgaudel I would try to flash the latest SDK (0.9.5) by following the docs here: https://docs.modalai.com/sentinel-factory-reset/#flash-procedure
The VOXL2 SDK 0.9.5 can be downloaded from downloads.modalai.com
-
@tom adb and fastboot are not working in our drone, we need to get access to SW 1 as per this instruction, how can we access to that in our drone that has modem 5G on top of voxl 2, do we need to disassemble the entire board?
-
@bgaudel You should be able to remove the M0090 add-on board and gain access to the M0054's fastboot button.
If you don't want to disassemble your drone you can send it in for an RMA: https://www.modalai.com/pages/rma
-
@tom thanks for the reply and sorry for the confusion but I think we have an RB5 drone; we used sw3 on the 5G add-on and enabled the fast boot to install the system image with VOXL SDK 0.9.5 as per instructions in this link. We get the following warning
[INFO] {system::0xC2F5D7000} partition returned size {0xD3B5D7000}, expected {0xC2F5D7000}in the first process. I was wondering if it is safe to proceed with this instruction:Image Version: 1.4.1 [INFO] Found fastboot device [WARNING] This system image flash is intended only for the following platform: RB5 Flight (m0052) Make sure that the device that will be flashed is correct. Flashing a device with an incorrect system image will lead the device to be stuck in fastboot. Would you like to continue with the RB5 Flight (m0052) system image flash? 1) Yes 2) No #? 1 [INFO] {system::0xC2F5D7000} partition returned size {0xD3B5D7000}, expected {0xC2F5D7000} [WARNING] Partition layout was found to be incorrect, this requires flashing the full partition table. Flashing the partition table will also flash every partition causing all data on the device to be lost. When doing a full flash, make sure to backup any important files Would you like to continue with the full wipe/flash now? 1) Yes 2) No #?thank you
-
@bgaudel Yep, that shouldn't be an issue
-
@tom Thank you so much. After reflashing the drone and enabling the required services, we attempted to establish a connection with the QGC. However, we encountered an issue as the connection could not be established.
These are the activated services in our drone.
we used
voxl-configure-vision-px4to connect drone with QGC
How we can establish the connection between QGC and Drone?
-
@bgaudel Are you able to ping the drone from the ground station and vice-versa?
-
@tom Yes I am able to ping the drone from GS and vice versa shown in the image below.
This one is ping my PC from drone:
This is ping drone from my PC (my qgc):
mypc@mypc:~/mypc$ ping 172.16.0.143 PING 172.16.0.143 (172.16.0.143) 56(84) bytes of data. 64 bytes from 172.16.0.143: icmp_seq=1 ttl=64 time=27.0 ms 64 bytes from 172.16.0.143: icmp_seq=2 ttl=64 time=50.9 ms 64 bytes from 172.16.0.143: icmp_seq=3 ttl=64 time=71.3 ms 64 bytes from 172.16.0.143: icmp_seq=4 ttl=64 time=94.7 ms 64 bytes from 172.16.0.143: icmp_seq=5 ttl=64 time=118 ms ^C --- 172.16.0.143 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4005ms rtt min/avg/max/mdev = 27.039/72.410/118.097/31.966 ms -
@bgaudel Have you been able to connect to QGC on this PC in the past? I'm wondering if there is some firewall preventing the traffic
-
@tom Indeed, I have previously utilized the same computer without any issues, and the connection was established successfully. It is perplexing since I have not implemented any firewall restrictions on the PC. I am uncertain about the underlying cause of this connectivity problem.
-
@bgaudel Does QGC have auto-connect over UDP enabled?
-
@tom Yes, the QGC has auto-connect over UDP enabled.
we see the status of voxl-px4 as well,
rb5:~$ systemctl status voxl-px4 ● voxl-px4.service - px4 Loaded: loaded (/etc/systemd/system/voxl-px4.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2022-09-06 03:18:14 UTC; 11min ago Main PID: 2892 (voxl-px4) Tasks: 26 (limit: 4915) CGroup: /system.slice/voxl-px4.service ├─2892 /bin/bash /usr/bin/voxl-px4 -d └─2904 px4 -d -s /etc/modalai/voxl-px4.config Sep 06 03:26:44 m0052 bash[2892]: INFO [PreFlightCheck] Failed EKF sensor bias preflight check Sep 06 03:26:44 m0052 bash[2892]: ERROR [muorb] SLPI: MAG #0 failed: TIMEOUT! Sep 06 03:26:44 m0052 bash[2892]: INFO [PreFlightCheck] Failed EKF sensor bias preflight check Sep 06 03:26:44 m0052 bash[2892]: ERROR [muorb] SLPI: MAG #0 failed: TIMEOUT! Sep 06 03:26:44 m0052 bash[2892]: INFO [PreFlightCheck] Failed EKF sensor bias preflight check Sep 06 03:26:44 m0052 bash[2892]: INFO [PreFlightCheck] Failed EKF sensor bias preflight check Sep 06 03:26:44 m0052 bash[2892]: ERROR [muorb] SLPI: MAG #0 failed: TIMEOUT! Sep 06 03:26:44 m0052 bash[2892]: INFO [PreFlightCheck] Failed EKF sensor bias preflight check Sep 06 03:26:44 m0052 bash[2892]: ERROR [muorb] SLPI: MAG #0 failed: TIMEOUT! Sep 06 03:26:44 m0052 bash[2892]: ERROR [muorb] SLPI: MAG #0 failed: TIMEOUT!==================
the output of debugging the communication link as per https://docs.modalai.com/voxl-vision-px4-telemetry/rb5:/$ voxl-vision-px4 --debug_udp_recv Enabling UDP recv debugging loading our own config file ================================================================= Parameters as loaded from config file: config_file_version: 1 MAVLINK IO qgc_ip: NULL en_secondary_qgc: 0 secondary_qgc_ip: NULL qgc_udp_port_number: 14550 udp_mtu: 512 en_localhost_mavlink_udp 1 localhost_udp_port_number: 14551 VIO en_vio: 1 vio_pipe: qvio en_send_vio_to_qgc: 0 en_reset_vio_if_initialized_inverted: 1 vio_warmup_s: 3.000000 send_odom_while_failed: 0 MISC FEATURES horizon_cal_tolerance: 0.500000 OFFBOARD MODE offboard_mode: off follow_tag_id: 0 figure_eight_move_home: 1 robot_radius: 0.300000 collision_sampling_dt: 0.100000 max_lookahead_distance: 1.000000 FIXED FRAME RELOCALIZATION en_tag_fixed_frame: 0 fixed_frame_filter_len: 5 en_transform_mavlink_pos_setpoints_from_fixed_frame:0 COLLISION PREVENTION (VOA) en_voa: 1 en_send_voa_to_qgc: 0 voa_upper_bound_m: -0.150000 voa_lower_bound_m: 0.150000 voa_memory_s: 1.000000 voa_input #0 enabled: 1 type: point_cloud input_pipe: dfs_point_cloud frame: stereo_l voa_input #1 enabled: 1 type: point_cloud input_pipe: stereo_front_pc frame: stereo_front_l voa_input #2 enabled: 1 type: point_cloud input_pipe: stereo_rear_pc frame: stereo_rear_l voa_input #3 enabled: 1 type: tof input_pipe: tof frame: tof voa_input #4 enabled: 1 type: rangefinder input_pipe: rangefinders frame: body ================================================================= loading extrinsics config file loading horizon cal file existing instance of voxl-vision-px4 found, attempting to stop it starting geometry module starting px4 monitor starting px4 mavlink Waiting to connect to voxl-mavlink-server Connected to voxl-mavlink-server starting udp mavlink Adding manual QGC IP address to udp connection list: NULL WARNING: invalid qgc_ip, this is fine if you don't want to use it starting fixed pose input starting vio manager Connected to VIO pipe: qvio updating to use imu: imu_px4 done updating transforms to use imu: imu_px4 starting tag manager starting voa manager Connected to voxl-tag-detector Connected to pipe: stereo_front_pc Connected to pipe: stereo_rear_pc starting horizon cal module Init complete WARNING: connected to voxl-mavlink-server but no messages from PX4 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 Added new UDP connection to 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203 UDP recv msg ID: 0 sysid:255 from port: 14550 IP: 172.16.0.203Is there any specific configuration or installation that we need to do for px4 or QGC after installing the VOXL SDK image on a rb5 drone?
-
@bgaudel What does your voxl-vision-px4 config file look like?
cat /etc/modalai/voxl-vision-px4.conf?I'm seeing
qgc_ip: NULL, which may be the issue -
@tom we tried different settings. The following is the IP setup that we have on the LAN network using a router. "qgc_ip": "172.16.0.203", is my computer IP, and the drone IP is 172.16.0.75". Also, the ping test works back and forth.
rb5:/$ cat /etc/modalai/voxl-vision-px4.conf /** * VOXL Vision PX4 Configuration File * * version: don't touch this, used to keep track of changing config file formats * * ############################################################################## * ## Networking * ############################################################################## * * qgc_ip: * Manually inform voxl-vision-px4 of the IP address of your QGC Ground * Controller by providing the IP address of your ground station computer * in the “qgc_ip” field of the config file. This field is also configured * as one of the first questions in the configuration wizard. * If you wish to rely on QGC to initiate the connection to VOXL you can * leave this field as-is, blank, or “NULL”. Mavlink data is sent to this * IP on port 14550 by default, but this can be changed with the * qgc_udp_port_number config value. * * en_secondary_qgc: * Enable manually setting a second QGC ground station IP address. * * secondary_qgc_ip: * IP address for optional second QGC connection. Note that many more mavlink * connections can be made as long as they are initialized by the other device. * * qgc_udp_port_number: * Port to use for manual and automatic QGC connections, default 14550 * * udp_mtu: * Max size of UDP packet to send to QGC. Multiple mavlink messages will be * combined into one UDP packet to reduce network traffic. Set this to 0 to * send one UDP packet for every mavlink message. Default is 512 which * allows several mavlink messages per UDP packet. * * en_localhost_mavlink_udp: * If you are running MAVROS/MAVSDK onboard VOXL and wish to open access to * PX4 through a localhost UDP port simply ensure the follow feature is * enabled. This is set to true by default. This will allow one local process * to communicate with PX4 via port 14551 by default, NOT 14550 which is * reserved for connections outside the board. These separation prevents * conflicts between the two sockets. Both MAVROS and MAVSDK can be * configured to use this port. * * localhost_udp_port_number: * Port number for localhost UDP socket, default 14551 * * ############################################################################## * ## VIO * ############################################################################## * * en_vio: * Enable processing of VIO data from MPA to be sent to PX4 as mavlink * odometry messages. Enabled by default. * * vio_pipe: * Which pipe to subscribe to VIO data. Must be a standard libmodal-pipe * vio_data_t type. Default is qvio * * en_send_vio_to_qgc: * Enable sending of VIO odometry messages to QGC for debug. * Note PX4 also sends odometry messages to QGC, so look for * the messages in mavlink-inspector marked as from component 197 * * en_reset_vio_if_initialized_inverted: * For VIO algorithms like qVIO that can initialize in any orientation * and output their estimate of the gravity vector, we suggest leaving * this enabled to allow vvpx4 to automatically send the reset signal * back to the VIO pipe if VIO was initialized upside-down or sufficiently * off-level. Helpful if the user powers on a drone while carrying it to * the flight area and VIO starts too early. * * vio_warmup_s: * Wait this for this amount of time of having good VIO data before * actually starting to send to PX4. This helps stop EKF2 getting * confused if VIO flickers in and out while struggling to init. * Set to 0 to disable the feature. * * send_odom_while_failed: * Off by default. Reserved for the future when PX4 supports quality field * * ############################################################################## * ## APQ8096-only Features * ############################################################################## * * en_set_clock_from_gps: * Enable setting the VOXL system time to GPS time if no NTP server can be * reached via network to set the time. * * en_force_onboard_mav1_mode: * Force PX4 to use onboard mode for mavlink 1 channel which is the channel * apq8096 (VOXL1) uses to communicate UART Mavlink with PX4. Not applicable * to qrb5165-based platforms. Sets the MAV1_MODE PX4 param. * * en_reset_px4_on_error: * Trigger a reboot of PX4 one some of PX4's unrecoverable errors, * Not applicable to qrb5165 * Yaw estimate error & High Accelerometer Bias and both detected * * ############################################################################## * ## Misc Features * ############################################################################## * * horizon_cal_tolerance: * Allowable standard deviation in roll/pitch values to consider the drone * stable enough in flight to do a PX4 horizon calibration. Default is 0.45, * you can increase this slightly if flying in a small indoor area or with * a drone that does not hold still very well. * See https://docs.modalai.com/calibrate-px4-horizon/ * * ############################################################################## * ## offboard mode config * ############################################################################## * * offboard_mode: The following are valid strings * off: VVPX4 will not send any offboard commands to PX4 * figure_eight: Default value, VVPX4 commands PX4 to fly a figure 8 path * follow_tag: Drone will follow an apriltag around. Very dangerous, not * recommended for customer use, for ModalAI R&D only. * trajectory: VVPX4 receives polynomial trajectories by pipe and commands * PX4 to follow the trajectory path. Still in development. * * follow_tag_id: * Apriltag ID to follow in follow_tag mode * * figure_eight_move_home: * Enable by default, resets the center of the figure 8 path to wherever * the drone is when flipped into offboard mode. When disabled, the drone * will quickly fly back to the XYZ point 0,0,-1.5 in VIO frame before * starting the figure 8. Disabling this feature can be dangerous if VIO * has drifted significantly. * * robot_radius: * Robot radius to use when checking collisions within the trajectory monitor. * The trajectory monitor is only active when in trajectory mode * * collision_sampling_dt: * The time step to sample along the polynomials by when checking for collisions * in the collision monitor. * * max_lookahead_distance: * Maximum distance to look along the trajectory. Sensor data further out can be * unrealiable so keeping this value small reduces false positives * * ############################################################################## * ## Fixed Frame Tag Relocalization * ############################################################################## * * en_tag_fixed_frame: * Enable fixed frame relocalization via voa_inputs. * See: https://docs.modalai.com/voxl-vision-px4-apriltag-relocalization/ * * fixed_frame_filter_len: * Length of the moving average filter to use for smooth relocalization * when a tag is detected. Default is 5, a longer filter will result in * smoother behavior when a new tag comes into view. Set to 1 to do no * filtering at all and assume every tag detection is accurate. * * en_transform_mavlink_pos_setpoints_from_fixed_frame: * When enabled, mavlink position_target_local_ned_t commands received on * via UDP will be assumed to be in fixed frame and are then transformed * to local frame before being sent to PX4. This allows offboard mode * position commands from MAVROS/MAVSDK to be in fixed frame relative to * voa_inputs even though PX4/EKF2 operates in local frame relative to where * VIO initialized. * * ############################################################################## * ## Collision Prevention (VOA) * ## Settings for configuring data sent to PX4 for Collision Prevention * ############################################################################## * * en_voa: * Enable processing of DFS and TOF data to be sent to PX4 as mavlink * obstacle_distance messages for collision prevention in position mode. * * en_send_voa_to_qgc: * Enable sending of VOA obstacle_distance messages to QGC for debug. * * voa_lower_bound_m & voa_upper_bound_m: * VOA ignores obstacles above and below the upper and lower bounds. * Remember, Z points downwards in body and NED frames, so the lower bound * is a positive number, and the upper bound is a negative number. * Defaults are lower: 0.15 upper: -0.15 Units are in meters. * * voa_memory_s: * number of seconds to keep track of sensor readings for VOA * default: 1.0 * * voa_inputs: * Array of pipes to subscribe to for use with VOA, up to 10 supported * Each entry has 4 fields: * * enabled: true or false, it's safe to leave this enabled when the pipe is missing * type: can be point_cloud, tof, or rangefinder * input_pipe: pipe name, e.g. stereo_front_pc, rangefinders, tof, etc * frame: frame of reference, should be listed in /etc/modalai/extrinsics/conf * */ { "config_file_version": 1, "qgc_ip": "172.16.0.203", "en_secondary_qgc": false, "secondary_qgc_ip": "192.168.1.214", "qgc_udp_port_number": 14550, "udp_mtu": 512, "en_localhost_mavlink_udp": true, "localhost_udp_port_number": 14551, "vio_pipe": "qvio", "en_vio": true, "en_send_vio_to_qgc": false, "en_reset_vio_if_initialized_inverted": true, "vio_warmup_s": 3, "send_odom_while_failed": false, "horizon_cal_tolerance": 0.5, "offboard_mode": "off", "follow_tag_id": 0, "figure_eight_move_home": true, "robot_radius": 0.300000011920929, "collision_sampling_dt": 0.1, "max_lookahead_distance": 1, "en_tag_fixed_frame": false, "fixed_frame_filter_len": 5, "en_transform_mavlink_pos_setpoints_from_fixed_frame": false, "en_voa": true, "en_send_voa_to_qgc": false, "voa_upper_bound_m": -0.15000000596046448, "voa_lower_bound_m": 0.15000000596046448, "voa_memory_s": 1, "voa_inputs": [{ "enabled": true, "type": "point_cloud", "input_pipe": "dfs_point_cloud", "frame": "stereo_l" }, { "enabled": true, "type": "point_cloud", "input_pipe": "stereo_front_pc", "frame": "stereo_front_l" }, { "enabled": true, "type": "point_cloud", "input_pipe": "stereo_rear_pc", "frame": "stereo_rear_l" }, { "enabled": true, "type": "tof", "input_pipe": "tof", "frame": "tof" }, { "enabled": true, "type": "rangefinder", "input_pipe": "rangefinders", "frame": "body" }] } -
@bgaudel After modifying the conf file, are you restarting voxl-vision-px4 with
systemctl restart voxl-vision-px4? -
@tom yes we did
systemctl restart voxl-vision-px4after modifying the config file.The setting of our QGC is:
.Still not able to connect with QGC. We also tried the same thing on the two different PC. Are there any settings or configurations that we especially need to take care of?
-
@bgaudel It seems as though you have all the configs setup correctly, can you post the status of the following services:
systemctl status voxl-px4 systemctl status voxl-vision-px4 systemctl status voxl-mavlink-server -
