1. Mavproxy and Position_Forward do not launch.
This issue is more often than not encountered when you have multiple QGroundControl applications running on different machines under the same network. Ensure that you do not have multiple QGroundControl running at the same time and restart the drone again.
2. Streaming enabled on RCBenchmark Tracking Lab but, the LCD screen indicates Tracking Offline.
Check that the port number is correctly entered. For reference, the port number should be 5401. Also check if the IP address has been correctly entered.
Incase the problem still persists, please close and relaunch RCbenchmark Tracking Lab to start a new session.
3. The drone suddenly loses tracking.
Tracking can be interrupted between the Otus and the ground computer, between the RCbenchmark tracking lab and the Raspberry Pi, or between the Raspberry Pi and the PX4. The troubleshooting steps below will help identify the issue.
Before attempting those troubleshooting steps, check the following elements:
- The base stations are within view of each other (green LED) and at less than 5 m of each other. This is so the base stations are synced. The base stations should also be mounted firmly.
- The USB dongle is connected to a USB extension and is as close as possible to the Otus tracker (at the edge of the tracked area, or on the floor or the ceiling in the tracked area).
- The hexagonal vibration damper is installed. Also, no wires or battery touches the Otus tracker during flight as they can transmit vibrations.
- Large mirrors in the room are covered.
- You are not in an environment with a very high number of Wifi networks such as a trade show.
- You are using a dedicated router in the same room as the quadcopter and the ground station.
- After each drone power-up, reset the local axis in RCbenchmark tracking lab. Make sure you are using the right controller ID to reset the local axis, especially if you have multiple controllers. Check that the vision yaw, pitch and roll is close (0.1< rad) to the LOCAL_POSITION_NED yaw, pitch and roll. Look for differences of 1.5 or 3.1 rad (Pi or Pi/2 rad) which would indicate a bad local frame of reference of the tracking system.
Likely cause for in-flight loss of tracking:
- RF interference
- Between the Otus tracker to the USB dongle. Solution: reduce the distance between the USB dongle and the Otus tracker. If you are in an environment with a very high number of wifi devices (i.e. tradeshow), move the tracking system to another location.
- Between the ground computer and the Raspberry Pi. Solution: Use a dedicated router. Use a wired connection between the ground computer and the router. Move the router closer to the UAV.
- Vibrations: Caused by the high frequency from the motors and propellers spinning. Solution: use the hexagonal vibration damper. Check that no wire or element is touching the Otus tracker (other than the USB power input). Balance your propellers. The magnitude of vibration of the Otus tracker should be one order of magnitude lower than the vibration of the frame. You can check this by touching the frame of the quadcopter and the Otus tracker when the propellers are spinning and the quadcopter is secured to the ground. The vibration on the Otus tracker will be much lower.
- Base stations too far. The maximum recommended distance between the base station is 5 m. The minimal distance between the base stations and the tracker is 75 cm. You may get a sync error message in SteamVR if the base stations are too far apart.
- Strong direct sunlight.
- Large mirrors or reflective surfaces in the room. Large windows could also act as mirrors.
Loose connection. Vibration in flight could cause a connector to become loose. Tightly secure your connections
- Defective Otus tracker
- Each Otus tracker is calibrated in the factory. Stong impacts may disconnect a sensor or change the geometry of the tracker, which reduces tracking reliability.
- Defective base station: Unlikely. A defective base station will not show as solid green in StreamVR.
For the following tests, record the position of the Otus tracker in RCbenchmark Tracking Lab. Also, record the PX4 log file. You should have RCbenchmark tracking lab and QGC opened on the desktop computer. In QGC, open the analyze window and look for the vision and pose messages. Chose one axis for your tests such as the X or Y position axis. You are looking for irregularity in the tracking that looks like a polynomial or exponential change in the estimated pose when the quadcopter does not move.
3.1 Manual tracking test
Remove the propeller of the UAV and power it. Once tracking started, reset the local axis and inspect the graph in QGC as explained above. Check vision and estimated position and orientation match in QGC. Manually move the drone around the room to cause tracking to break. Try fast and slow movements. Also try to occlude the view between one base station and the Otus tracker: the tracking should hold and not jump. Look for loss of tracking in RCbenchmark Tracking Lab and in QGC.
If you are losing tracking at any point during the flight in RCbenchmark tracking lab, you probably have an issue with poor signal reception or a visual issue mentioned above. You also know that there is an issue between the Otus tracker and the ground computer. If tracking is always good in RCbenchmark tracking lab but breaks in QGC, it means that you have an issue with the Wifi or with the Raspberry Pi itself.
If the tracking does not break, you have a good RF environment with the motors off. You can also discard visual problems issues.
3.2 Manual flight tracking test
Repeat the steps above in flight. You will need two people: one to fly the drone and one to watch the graph.
If you lose tracking an any point during flight, it is likely that the issue is caused by vibration. See the likely causes and solution above. Alternatively, the issue could be caused by strong RF interference from the motors. The Otus Quadcopter kit was check for this potential problem, but a custom quadcopter could be using larger motors. You will need to increase the distance between the Otus quadcopter and the motor. You can also change the ESC switching frequency.
If you are confident that the tracking is solid during manual flight, you can move on to an autonomous flight.
4. The screen not display anything at all. (Raspbian does not boot)
If your Raspberry Pi does not boot, try to connect the HDMI port to a screen and reboot. If no image is displayed an you have checked all the electrical connections, the files on your SD card are probably corrupted. In this case, you will unfortunately have to reinstall the SD card image. Follow the instructions here.
5. My Otus is not being tracked by the RCTracking Lab.
This case usually arises when the base station loses tracking of the Otus. Do the following to eliminate the issue.
- Ensure that the base station is on and that there is nothing in between the Otus and the base station.
- Ensure that the controller firmware is up-to-date on Stream VR.
- Click Steam VR > Devices > Update Firmware > Select the controller.
- If the problem still persists, please exit and re-launch the RCBenchmark Tracking Lab.
- Connect the Otus tracker dongle into a different USB port on the main computer.
6. The screen displays EKF yaw error.
This error arises when the position co-ordinates from the Otus Tracker are not reset to local axis. This causes the position mismatch with the position co-ordinates from the pixhawk which leads to wrong vision position estimate calculation leading to a EKF Yaw error.
To fix this issue, Please perform the following steps in the described order:
- Reset local axis on the RCbenchmark Tracking Lab.
- On QGroundControl, navigate to parameters then click on Tools on the top right corner and select reboot. Once Pixhawk has been rebooted, the correct co-ordinates are plugged into the vision position estimate fixing the issue.