Bench-top tests

Test the autonomy pipeline with software-in-the-loop simulations and SDR.

For evaluating the payload, testing phase coherence, gain stability, and general debugging of the autonomy code, one needs to compile the entire flight stack, introduce a flight path, and simulate drone flight in synchronization with the transmitting and receiving SDR. Below are instructions on how to do so.

On the base station:

The base station will host a locally compiled ArduCopter flight stack that will stream MAVLink data to the payload and internally route the same data to a ground control software (GCS) like QGroundControl. This will allow you to begin and stop the mission as you would on the field using the GCS and show you drone systematics in real-time. It will also allow the payload to receive drone position and orientation and know when to begin and stop calibration.

1. Build ArduCopter (initial installation instructions can be found here):

cd ~/ardupilot
sim_vehicle.py -L MiltonAirfield -v ArduCopter --console –map

1. In another terminal run mavlink-routerd to route MAVLink packets to the Pi and to another internal port for QGroundControl:

mavlink-routerd -e 127.0.0.1:12550 -e <pi internal addr>:16550 127.0.0.1:14550

1. In a third terminal start the GNU Radio front-end:

roscd beam_mapping/Base\ Station/
python tcp_toggle.py

1. Finally, in a fourth terminal do this:

roscd beam_mapping/Base\ Station/
python base-station-receiver.py

1. Run QGroundControl:

~/Downloads/QGroundControl.AppImage

On the Raspberry Pi

1. First, you need to instruct the Pi to look for a MAVROS connection via a local network connection, and not the default serial connection when mounted on the drone. To do this, first disable all running ROS nodes: sudo pkill -9 rosmaster. Then modify one of the boot-up shell scripts:

roscd beam_mapping/Payload\ Computer/
nano connect_to_fc.sh

Uncomment the second roslaunch command and comment out the first one. Be sure to change the UDP address to whatever the internal IP address of the Pi is.

If acquiring data from one SDR to another, ensure that the total input power into the RX SDR does not exceed -15 dBm. This can cause damage to the RF front-end. A safe working setting is 40 dB gain on the TX SDR and 0 dB on the RX SDR.

1. Now you have to run all the boot-up shell scripts in order or reboot the Pi. Here is how to manually start the autonomy pipeline from the terminal. First run some ROS nodes to connect the Pi to the compiled flight stack running on the base station:

roscd beam_mapping/Payload\ Computer/
./connect_to_fc.sh

1. Run the ROS nodes that will handle all WPs:

roscd beam_mapping/Payload\ Computer/
./mission.sh

1. Run the GNU Radio and SDR codes:

roscd beam_mapping/Payload\ Computer/
./start_cal_v2.sh

Once all these codes have started up, there should be communication between the payload and the base station and you should be able to synchronize saving calibration data. You can test this by typing custom commands into the raw_input() prompt in the terminal running base-station-receiver.py (step 5 of base station setup).

To get a list of available commands, type helphelp.

Simulating a flight path

At this point, the payload computer should have pushed the first WP found in ./mission/mission.waypoints to the flight stack over the UDP connection established via the roslaunch command (step 1 of Pi setup). Now, to begin the entire mission open up QGroundControl, select Takeoff and wait for the drone to hover at a safe altitude. Then switch Flight Mode to Auto. Watch as the drone moves from one WP to another, pauses, transmits a series of burst signals, and then moves on until the mission is complete.

Video demo of running the bench-top tests.