Skip to content
Lab 9: Believer GCS and Parameters
This week in lab, the GCS for the Believer was manipulated in order to gain information about the flight. This was accomplished by connecting a GPS and airspeed unit to the flight controller. Once these items are connected successfully, the crew on the ground will able to understand the airspeed and positioning of the aircraft. Some difficulties were encoutnered during this operation, and they are highlighted toward the end of this page. This lab is essentially an extension of the communications and avionics lab and uses much of the same software (Ardupilot).
GCS
At the start of the lab, while using an AIDA3 PC, the Cubepilot was connected to the GCS via USB. Shortly thereafter, the connection was verified to be live by monitoring movement in the HUD. Moevements of the Cubepilot flight controller were shown on the aircraft’s orientation and instrument readouts. After this was assured, some parameters and settigns were managed. some such settings are the GUID, connectivity indication, and flight modes. An image of the HUD can be seen below.
HUD imaging
The GUID_THISMAV (Globally unique ID to this MAV(Aircraft) parameter controls how the system differentiates one vehicle from another across networks or DroneCan buses. Connectivity is confirmed with the green Beating Heart icon toward the top of the screen. Another point of note is that there are manual flight and stabilized flight modes. For manual flight, the pilot directly manipulates all actuators. For stabilized flight modes, the pilot indirectly manipulates all actuators except for ailerons, elevators, rudders, and ground steering. Some of the primary items included in this activity can be seen in pieces below.
Lab materials
Parameters
After connectivity was assured, some of the parameters of the GCS were changed. At the beginning of the task, the parameters were first downloaded and saved. This is important when starting up the program, especially if things will be changed shortly thereafter. They do not update unless action is taken. Also, one point to note is that the telemetry module is how we communicate wirelessly with the flight controller, and it would soon be installed. It is also important to understand that MavLink is a messaging protocol used for communicating between drones and drone components.
To get into the weeds a little further, some more specific parameters were examined. For instance, TELEM 1 must have a BAUD rate of 115200 in order to communicate with the GCS. In addition, The JST- GH Telemetry connector cable links the RFD900 with the Cubepilot (specifically the Telem1 and Telem2 port on the Cubepilot). If these connectors and data speeds are out of alignment with one another, they will not communicate with each other. It is important to confirm connectivity with their associated parameters before flight.
Setup of telemetry was fairly simple, and required a few steps. First, the crew connected the air side RFD900 to the Cubepilot TELEM 1 port using the supplied cable. They were sure that the connector orientation was correct on the RDF900 end. Second, with the Cubepilot still connected by USB and in the GCS parameters tab, the crew confirmed the parameters matched SERIALX Parameters. Then the crew connected the ground side RFD900 to the PC and changed the serial connection from USB to the RFD900. The device manager was needed to open to identify the new COM port, and the crew kept the USB cable connected for power. It was then confirmed that data was then being transmitted wirelessly. The BAUD rate was kept at 115200, and the serial protocol was kept at “MAVLINK.”
Airspeed
Airspeed sensors are optional but highly recommended. If an airspeed sensor is not used an open-loop throttle mapping could be used instead, but additional margin should be incorporated into TECS settings when flying in open loop throttle. Open-loop throttle mapping sends preset throttle commands without sensor feedback, unlike closed-loop mapping, which adjusts throttle based on real-time sensor data to maintain desired performance. Airspeed sensors rely on pressure readings from a pitot tube, and that is what was installed later. An image of the pitot tube and line can be seen below.
Pitot tube
The pitot tube is long so it can collect information from undisturbed free-stream airflow, where the air pressure reflects the aircraft’s true dynamic pressure. The communication protocol used by the airspeed sensor is I2C Address: 0x28H. As a point of reference, a Hexadecimal number is a number expressed in the base 16 numeral system. Hexadecimal number's digits have 16 symbols: 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F. Each digit of a hexadecimal number counts a power of 16. Therefore, 0x28 hexadecimal = 40 decimal.
In order to setup the airspeed sensor, a few key steps were taken.To start, the crew attached the provided silicone tubing to one end of the pitot tube and to the correct port on the airspeed sensor. While using the provided cable, they then connected the airspeed sensor to the Cubepilot in the appropriate port.
3. In the GCS parameters tab, the crew later modified the parameters to match ARSPDX Parameters. Before doing this, they were sure to complete the original column to save a record of original settings. Some parameters are only visible upon reboot. From the Engineering tab, the crew performed an Autopilot Reboot of the board, remembering to download the parameters again. Finally, they verified that the airpseed sensor worked by monitoring changes on the ASI (and blwoing on the tube).
Some parameters which changed are detailed here. Airspeed type was changed from none to I2CMS4525D0, while the airspeed address was changed from 40 to 0x28H. Airspeed bus was changed from Bus 1 (external) to Bus 0 (internal). Lastly, airspeed tube order was changed from either port to port 1, and airspeed use was kept in the use position. Some of the parameters previously mentioned can be seen below.
Airspeed parameters
GPS
GPS is a very important tool to use for UAS operations especially like here where the goal is to eventually fly the aircraft above 400 feet AGL. For thsi operation, the crew used the Here3+ GPS. The communication protocol the Here3+ GPS uses is DroneCan 8Mbit/s. Also, the additional sensors the GPS unit includes are a magnetometer (compass), gyroscope, and accelerometer. This was a difficult module to setup because of the software hardships encountered, and the setup is still in progress days after the original installation attempt. An image of the GPS assembly can be seen below.
GPS module installation
The crew began this process by plugging the GPS unit into the appropriate ports on the Cubepilot board. They then flashed the FCU with Arduplane following the Ardupilot instructions. Using MissionPlanner, they connected to the board and verified parameters matched CAN Parameters. In a different menu on the line named “com.cubepilot.here3+,” parameters was selected. The crew downloaded the original parameters and attached them here: . They then selected “load from file” and uploaded this parameter file: WR_here3plus.param. “Write Params” was then chosen, and they closed the mission planner software and rebooted the FCU. They then reloaded the Windracers firmware using the thumb drive. In the GCS parameters tab, the crew modify the parameters to match ARSPDX Parameters described below. They were sure to complete the original column to save a record of original settings, and then they verified that the GPS acquired satellites. An image taken around the time of this process can be seen below.
Software work occurring
Parameters Check
Since the crew has modified the parameters, it’s helpful to compare the parameters with a known good parameter set. Do accomplish this, the Diffchecker software was used. First, the crew opened Diffchecker. Here one can easily compare differences between two files. In Diffchecker, crewmembers added the file they downloaded above in Parameters to the left side. They then added the file attached here to the right side: Parameters.json. It was then necessary to download the parameters again and attach here, but it was evident at this point that it would not work. The crew then found it important to change the embedded link to their own output using the share button.
More specifically, at the end of the parameters check, it became evident that the GPS was not working properly. The GNSS was not online at the end of the check, and this was confirmed with Professor N. Rose. After trying to download the parameters again, it became evident that the problem could not easily be fixed. After about an hour of trial and error with the professor, the crew was unable to determine the solution to the GPS problem. This is an important item for flight, and the search is ongoing for a permanent solution. An image of this trouble shooting can be seen below.
Active trouble shooting
Want to print your doc?
This is not the way.
This is not the way.
Try clicking the ··· in the right corner or using a keyboard shortcut (
CtrlP
) instead.