Posts made by alfa budiman

I've been working with the RB5 drone for autonomous flight and computer vision applications. I recently did a basic test to quantify the accuracy of VIO. In this test, I had the drone fly to positions (0,0,0), (1,1,1), (1,-1,1), (-1,-1,1), (-1,1,1) and back to (0,0,0), from its starting location. These are in global coordinates established by a motion capture system.

When powered up, I obtained the homogenous transformation from initial motion capture estimate. This homogenous transformation was then applied to the drone's VIO pose estimate. The drone compared this VIO pose estimate with my desired set point position inputs for flight. Motion capture was used to estimate ground truth position. I plotted the trajectories below. In each plot, black is VIO pose estimate, red is motion capture pose estimate and blue is the difference between them.

Overall, I can see that the VIO is working and it won't be perfect but I'd like explore ways to improve its accuracy. I am also certain this is not a PID control error either, as we can see the estimated (VIO) pose converging onto the set point inputs I provide; the drone clearly thinks it is in the right position, when it is not, as given from the motion capture pose estimate.

Some options I'm considering:

• changing PX4 parameters associated with VIO
• building a ROS node(s) to improve the pose estimate. I am only using the ROS topic /mavros/local_position/pose. Maybe I can use more information such as from /mavros/local_position/velocity_body and fuse them together for example.

@Alejandro-M
I documented the steps I took to get my RB5 drone from out of the box to flying programmatically with MAVROS. It includes intermediate steps such as wifi and QGround control setup.

https://github.com/albud187/uav_nav_ops/blob/manual/RB5_Drone_Setup.docx

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

I just tried executing the voxl-static-ip command and it returns saying "unkown host". I believe I'm already loading rb5 with voxl-sdk as I am able to programmatically fly it using MAVROS and work with its camera imagery through voxl_mpa_to_ros_node.

My intuition tells me that the current script on my RB5 drone isn't setup properly and that I should just take the bash file from source (https://gitlab.com/voxl-public/voxl-sdk/utilities/qrb5165-system-tweaks/-/blob/master/scripts/voxl-static-ip), fill in the LOCAL_IP and ROUTER_IP, push that file onto my drone and execute it.

I'm not too familiar with that, what should I put for "LOCAL_IP" and "ROUTER_IP" ?

I think (but am not too sure) that LOCAL_IP is what the drone's IP will be (permanently). As for router IP, I'm not sure what that would be. If it is the IP address of the computer I am ssh-ing from then that is an issue as I would like to be able to ssh into the drone from any computer or any router as long as they are on the same network.

Before I do something that could cause connectivity issues would it be possible to run the bash script without ROUTER_IP? Something like this:

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

I need to know the camera's position and orientation relative to the drone's body frame. This is so I can calculate its homogenous transformation relative to the drone, and then combine that camera imagery to localize detected objects in 3D space.

I need to know the values of dx, dz and theta from this image:

I'm assuming that the camera is centered laterally, so dy=0 (please correct me if this is incorrect), and that there is no roll or yaw with regards to its orientation. Hence the theta is the pitch or how much the camera is rotated along the y axis. Positive direction of y axis in image is out of the page.

I'd like to share my experience installing these packages on the RB5 drone. It was not pleasant but it got done.

I tried several variations of pip install opencv-python, with different versions of opencv and pip / pip2 / pip3, none of those worked. I tried sudo apt install and that didn't work. Similar issues popped up trying CV Bridge.

Ultimately, I ended up having to build these packages from source (I think that's the right term). I followed the steps here: https://pyimagesearch.com/2015/06/22/install-opencv-3-0-and-python-2-7-on-ubuntu/
to install opencv. I ignored steps 8 and 9.

To install CV Bridge, first I installed opencv as per the linked instructions. Then, I repeated the linked instructions step 10 but with the github repo for CV Bridge (https://github.com/ros-perception/vision_opencv). After this, you must edit the ~/.bashrc on the drone and enter the following:

export LD_LIBRARY_PATH=/usr/local/lib

These packages can then be used for computer vision work with camera imagery from voxl_mpa_to_ros_node. If anyone was able to install these packages using just pip install, I'd like to know how, as I believe this issue, of having to install from source may pop up in other packages I try to install on the drone.

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

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.

I'm not sure if you still have this problem, but if you know ROS, you can stream the cameras on your computer by configuring the drone to have the ROS master on your computer. First follow the steps at this link to setup ROS on RB5. https://docs.modalai.com/setup-ros-on-voxl-2/

Then you can set the ROS master to be on your computer by opening ~/.bashrc on the RB5 drone, and entering these lines in the file:

export ROS_MASTER_URI=http://{PC_IP_ADDRESS}:11311/
export ROS_HOSTNAME={RB5_DRONE_IP}

PC_IP_ADDRESS can be obtained from ipconfig on your computer. RB5_DRONE_IP is the one you use to ssh into it.
Then on the drone:

source ~/.bashrc

On your computer execute:

roscore
Rviz

On the drone execute:

roslaunch voxl_mpa_to_ros voxl_mpa_to_ros.launch

You will then be able to view the camera display topics from voxl_mpa_to_ros on your computer. You can stream them on Rviz, and you can create ROS nodes to subscribe to these topics for whatever computer vision application you develop. Hope this helps.

Whenever I turn off the drone and turn it back on, its IP address when connecting to my wifi network always changes. How do I make the RB5 Drone's IP address stay constant after turning it off and back on?

This IP address change is very annoying for the 2 following reasons:

1 - I am working with multiple robots communicating with each other over wifi via socket programming scripts. I have to declare each robots' IP address on my scripts. The IP address of my other robots, as well as my computer don't change.

2 - Sometimes I want the ROS master of the RB5 Drone on my computer. This is essential for me to view from voxl_mpa_to_ros on Rviz, as well as test computer vision scripts.
To get the ROS master on my comptuer, I ssh into the drone and edit the ~/.bashrc file, adding the following lines

export ROS_MASTER_URI=http://{PC_IP_ADDRESS}:11311/
export ROS_HOSTNAME={RB5_DRONE_IP}

I'd have to change the IP address on the ~/.bashrc every time the drone is turned off and back on later.

I've been having extensive issues regarding flight for a custom hexacopter built using the VOXL Flight Deck.

First, I should mention that the problem is unlikely the motors, ESCs or estimator. I had the drone clamped onto a heavy table and powered it up with props on. I executed

motor_test test -m n -p N

I had all 6 motors spinning at the same time with PWM ranging from 5%, 20%, 40%, 60%, 80% and 100%. As the PWM % increased, the RPM increased. In each PWM, all 6 motors were spinning at the same PWM.

Next, while the drone was still clamped I armed it and set the throttle to the max using virtual joystick. The expected behaved behavior would be all motors spin up to max PWM, and stay at that RPM until the throttle is changed. However, sometimes all motors spin up but (1 or 2) slow down or stop. Sometimes not all motors spin up.

I repeated this test with offboard mode, sending a velocity command (0,0,0.5,0) - corresponding to moving up at 0.5 m/s and observed the same result of inconsistent motor behaviour.

Overall, I can conclude that the motors and ESCs are not the problem.

Another test I ran involved the estimator. I had the drone powered up without probs. I had a small piece of tape on the motor shaft to provide visual aid. I increased throttle on stabilized mode. I tilted the drone and can see / hear the motors adjusting and attempting to level the drone. When I lower the left side of the drone, the motors on the left spin faster until I level the drone. This tells me the estimator is not the issue. This also tells me the controller is working as intended (but it doesn't tell me that the controller is tuned good enough or not).

So at this point I know the estimator, motors and ESCs are good to go.

The drone cannot take off, it usually tips over or becomes unstable. I've tried various values of gains for the rate controller and none of them have worked. The officially documented method for PX4 tuning requires that the drone can take off and hover well enough in the first place which my drone cannot.

So to recap, I have two issues:
1 - motors are behaving extremely inconsistently when attempting to fly (but behave fully as intended using the motor_test command)

2 - when the motors do spin up "enough" it still can't take off as it flips or becomes extremely unstable. The drone overall cannot safely take off and in its current state I can't even start apply the tuning procedure.

At this point I really don't know what the problem is. It could be the PID gains on the rate controller, but I don't think the motor performance is consistent with some of the settings I've tried for the gains.

While clamped, I've tried maxing out all the gains and maxing out the throttle - some motors are still very inconsistent; some motors are much slower than others for example or straight up stop.

Each test was conducted with full batteries.

Honestly, I have zero experience building and tuning a custom drone. This custom drone was handed to me by my research group and it's my job to get it to fly programmatically with MAVROS.

I was under the impression that the VOXL Flight Deck would already have its PID controllers tuned as I didn't see a section on PID tuning on the documentation for the Flight core.

Regarding that tuning procedure, it requires the drone take off and hover. My drone can't take off, it starts tilting to one side and I have to immediately lower the throttle else it will tip over. Not sure how to address this, do I just trial and error different controller values until it is "stable enough" ?

Or will disabling MC_AIRMODE automatically make it able to take off?

My understanding is if its disabled then there is no roll/pitch/yaw so the drone should be only be able to move up or down, but I have never touched that setting.

I'm having issues with the performance of my drone's motors during flight testing. I confirm that the ESCs have been calibrated properly as per https://docs.modalai.com/flight-core-pwm-esc-calibration/

For testing, I use Q Ground Control and have tried manual mode and stabilized mode.

I arm the drone (with propellers on) and gradually increase the throttle, but not enough to make the drone actually get off the ground, and I keep the throttle there. One of the motors eventually stops spinning or starts slowing down. As for which motor, it's not always the same and can vary, so I don't think the ESC / motor is the problem.

If I throttle it and do try to make it lift off, it starts tilting to one side so I immediately decrease the throttle to level it and keep it on ground.

I have also tested using motor test sliders on vehicle setup and also run into very inconsistent motor performance. When I throttle all the motors at the same time, sometimes one of the motors doesn't spin. Again, I can confirm that I can spin each motor individually. Also, when I arm the drone without propellers, all the motors spin, I put a piece of tape on the motor shaft and I can visibly see there's almost always a motor that isn't spinning properly or it slows down when it shouldn't. It's not always the same motor.

I have done this test using both hexacopter and quadcopter configurations. With the hexacopter configuration, there were 2 motors that didn't perform as expected.

What should I do to address this issue?

I don't think the motors / ESCs are the issue. I don't think it's a battery issue either.

I did another test using the motor_test function on mavlink shell on the drone with quadrotor configuration.
I execute

motor_test test -m n -p N

where n is the motor number (from 0 to 3) and N is the % of PWM output.

The motors spin up and maintain that constant rate until given another PWM output value. They respond exactly as expected without any issues. I've even tested with propellers on but only up to N = 10 any higher is probably unsafe and may risk the drone lifting off.

I should note that the motors can be quite sluggish to spool up when propellers are on, compared to spinning up immediately during testing without propellers.

@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.

I got my drone setup with MAVROS and Q Ground Control and it appears to be responding when I publish to /mavros/setpoint_velocity/cmd_vel_unstamped

However, there's some issues with the drone's response. I've only tested it moving purely vertically up and it is unstable / doesn't respond right away.

For publishing to the topic I made my own ros node (velocity_publisher.py) that lets me input the desired velocity in the form (vx,vy,vz,wz). This input corresponds to the movement in m/s (or rad/s) in the drone's forwards (vx), left (vy), and up (vz) directions, with wz corresponding to rotation along the z (up) axis. I confirmed that I am publishing correctly when using rostopic echo. I confirm that these directions are correct; I have moved the VOXL FLight deck itself powered up but un-attached to the drone while observing rostopic echo /mavros/local_position/velocity_body.

For testing, my steps were as follows:
1 - Open QGround Control and 3 terminals. On each of the terminals I ssh to the drone.
2 - On terminal 1 I run MAVROS as per your instructions here: https://docs.modalai.com/mavros/
3 - On terminal 2, I run velocity_publisher.py
4 - On terminal 3, I arm the drone using rosservice call /mavros/cmd/arming True
5 - On terminal 2 I input my desired command velocity.

Here are my issues:
1 - I publish (0,0,vz,0). The drone doesn't move until (approx) vz>0.5. This is an issue if I want the drone to move at a speed less than 0.5 m/s.

2 - When the drone is moving it is unstable and drifts undesirably. While I input (0,0,vz,0), I only want it to move straight up. However, it clearly has very noticeable lateral motion.

3 - Some motors are sluggish to start when arming.

Some theories as to the cause of the issue:
1 - Improperly calibrated ESCs. They were calibrated as per the steps here: https://docs.modalai.com/flight-core-pwm-esc-calibration/
Though, I did change the PWM_MAIN_MIN / PWM_MAIN_MAX parameters on QGRoundControl. I'll reset them to factory defaults and re-calibrate everything.

2 - Improperly calibrated sensors, especially gyroscope. I don't think this is an issue I calibrated on Q Ground control using a wired connection. But same as # 1, I can reset the parameters on Q Ground Control and re-calibrate everything,

3 - Misaligned propellers. I can re-assemble the mounts for the motors to ensure each of them are properly aligned.

I will be resetting the parameters and recalibrating everything on the VOXL Flight deck as well as re-assembling the propeller mounts. What else should I look at?

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.

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.

@Adrian-Hidalgo

@modaltb
I'm not positive that the ESC needs 4000. I just put that setting on QGC to test what would happen. I'll have to check the ESC documentation to verify its PWM range.

Additional testing with pwm info:

It does appear to be attempting to adjust PWM signal as I throttle the drone on virtual joystick:

One possible theory - the ESC / motors need more PWM then what can be provided by QGC / VOXL Flight Deck. The max PWM it can provide is around 2100, even if the I set PWM_MAIN_MAX to 4000, it doesn't provide more than approx 2100. I'm certain that PWM_MAX_MAIN is the correct setting, as when I set this to 1600, and check pwm info, the PWM at max throttle is around 1600.