Topics created by alfa budiman

Hi,

This is all down to the VIO algorithm. You'd be able to make major tweaks if you're postprocessing the data after, like detecting a reset and continuing from the last valid position (we do this in vvpx4), but changing the px4 params or other fusion techniques that only use the same sensors as the initial vio algorithm will likely not yield any improvements.

As for improving the vio algorithm itself, the QVIO's mvVISLAM package is proprietary code(even to us, we don't have the source) that we usually quote at 2% error over distance, which seems to match the test you've run here (you've flown a bit under 10 meters and it looks like you've drifted ~0.15-0.2 meters. We've been working on and experimenting with other algorithms internally, but don't have a hard date on when these will be fully tested/published. It's worth mentioning that most of our experimentation with these is to attempt to open-source our solution and add support for other features (like multiple cameras) but that generally the 2% error is considered very good especially in real-world environments.

The 2 main things you can do out of the box to ensure that your VIO is working as best it can are ensuring that it has accurate camera and imu calibrations, and that your extrinsics file is accurate.

Thanks, that's exactly what I'm looking for

I setup wifi connectivity on the RB5 drone by executing

voxl-wifi station ssid password

It automatically connects to any network with that matching ssid and password, whether it is a hotspot setup by my cellphone or setup by my personal laptop, regardless of their IP address. This is the functionality that I want. If the IP address of the drone changes because it is connected on a different network, that is fine. The issue is the drone IP address changing even though it is re-connecting on the same network after being turned off and turned back on.

@tom said in Drone IP Address keeps changing:

@alfa-budiman The ROUTE_IP and LOCAL_IP depend on the format of the IP addresses on the WiFi network you are attempting to connect to.

I would connect to your WiFi network and check the IP address given to your drone by the network.

If it gives you an IP address in the format 192.168.X.Y you'll want to set the ROUTER_IP to 192.168.X.1

then set LOCAL_IP to whatever IP you want to request from the router, it will need to be in the format 192.168.X.Z where Z is the number you want to request.

My concern with entering these IP addresses is that it would then cause the cause drone to search for a specific IP address or else it will not connect.

I documented the steps I took to setup my drone here:
https://github.com/albud187/uav_nav_ops/blob/manual/RB5_Drone_Setup.docx

it's not possible for a flight controller to have PID parameters for an unknown drone. Every drone has different tuning parameters. We sell the VOXL m500, pre-tuned and flight tested, just for this purpose.

@Chad-Sweet
What is the "basic drone bring up process"?

I can fly it in manual mode, it's not easy to fly, but I felt like its more due to my skill level as its behavior from virtual joystick was somewhat similar to when I tried virtual joystick with your RB5 drone.

It does drift noticeably. I think this drift is excessive but again, I'm not sure if it's an issue with the drone or my skill level using virtual joystick.

It didn't seem to respond to virtual joystick inputs in position mode but I didn't extensively enough test that mode. I'll test that mode again and see what happens.

Thanks. I got it working and it appears to be calibrated. It also appears to be responding as intended with MAVROS when I publish to /mavros/setpoint_velocity/cmd_vel_unstamped

I tested with props off and powered via battery. I published 0,0,1,0 corresponding with vertical speed of 1 m/s up and the motors sped up. I then published 0,0,-1,0 and the motors slowed down as expected.

Thanks.

CTV, CTU and CTT*:
detected by usb, connects to wifi / Q Ground control and can be armed / throttled. For some reason these just worked after I pushed the button and powered them on, didn't have to go through the full-flash process.
*For CTT it was a Q Ground Control related issue. I saved the parameter file from CTV and loaded it onto CTT.

CU7:
non-responsive to flash-full process:

[INFO] version: 0.0 [INFO] adb installed [INFO] fastboot installed [INFO] qti-ubuntu-robotics-image-qrb5165-rb5-boot.img present [INFO] abl.elf present [INFO] qti-ubuntu-robotics-image-qrb5165-rb5-sysfs.ext4 present [ERROR] Device in fastboot mode. Unable to backup camera files. [INFO] Please bring device out of fastboot mode by first running: fastboot reboot

I then enter fastboot reboot and try sudo ./flash-full.sh again. It gets stuck at

[INFO] version: 0.0 [INFO] adb installed [INFO] fastboot installed [INFO] qti-ubuntu-robotics-image-qrb5165-rb5-boot.img present [INFO] abl.elf present [INFO] qti-ubuntu-robotics-image-qrb5165-rb5-sysfs.ext4 present [INFO] Saving camera calibration files

and is no longer detected by usb. However, when I push the button again, it does appear on lsub and fastboot devices.

c9ce2d0d fastboot

I haven't tried it but I was just able to publish to /mavros/setpoint_velocity/cmd_vel_unstamped and the motor speed appeared to respond as expected when testing without propellers. This only works if the drone is set to offboard mode.

@Chad-Sweet
Alright, if MAVROS hasn't been tested on the RB5 drone then what is the currently established method of programmatically flying it?

I encountered this problem a while ago and its just a matter of a usb device on your virtual machine

7e018bc6-8636-428f-b624-327316eb00a7-image.png

You can also download adb for windows to verify that the drone is detected by the computer. If it's not detected by your computer at all (on host OS), then it won't be detected by your VM.