While I wait for a decision on my SRG which was submitted September 20th, I am left to do as much testing as possible without having any parts.
Preparing XBee resources
The XBee radios have many mature libraries, and plenty of examples and guides available for Arduinos, which I will be using to control the trio of radios in the relay system.
The main library is located here: https://github.com/andrewrapp/xbee-arduino/tree/master. It includes in its wiki a great getting started Developers Guide. The guide points out that the XBees can operate in two modes, AT or API. In AT mode, the radios operate basically as two ends of a hose. Bits go in one side, bits come out the other. There is little else to it. AT mode allows for fast transmission and the ability to implement a custom protocol. in API mode, the radios use packets to format data and address it to specific radios. This allows for better insight into RSSI as well as checking for errors, etc.
Packet mode makes sense for my implementation as I am sending discrete chunks of data from one side to the other. Some of this data may need to be sent more frequently than others, for example prioritize control data over telemetry data, and packets would make it simple to prioritize which data gets sent.
Quadcopter weight carrying test
I still have a good amount of time before aerial tests will be conducted, but the carrying capacity of my quadcopter is still an unknown. Theoretical calculations from ecalc.ch give 1.7kg, or about 3.7lbs, of payload capacity. Those numbers are what the quad can carry at the very maximum, meaning the max it can hold and still manage to get off the ground. The payload for a workable flight time must be as small as possible.
A payload of 2lbs brings the theoretical flight time down to 10 minutes, which is serviceable. The payload should be kept below this number as a general rule. I will refine the number further once testing is done.
Antenna tracking options
Hardware:
Antenna tracking will become a large factor if and when the range extender capability is introduced. It would also make ground station setup easier as antennas wouldn’t have to be manually aimed. As I have access to a laser cutter and 3D printer through the Makerweb, I will design and build the tracker myself.
There are plenty of DIY tutorials online:
- http://ardupilot.org/copter/docs/common-mission-planner-gps-based-antenna-tracking.html
- http://ardupilot.org/antennatracker/index.html#home
- https://github.com/andreiva/simple-rssi-antenna-tracker
I am most interested in a by-default RSSI tracker and the possibility of adding GPS to its tracking capabilities. In both the “off-the-shelf” and XBee configuration, accessing the GPS location of the relay should be fairly straightforward. The code for an RSSI tracker could be modified to use GPS to establish an initial fix on the relay, then maintain a strong signal with RSSI. An algorithm to decide which method of tracking to use will be an interesting bit of research. This guy seems to have done something very similar to what I am looking for.
Software:
Unlike the software running the relays, the antenna tracker has the benefit of being ground based and larger sources of computational power. The tracker will have two data inputs: GPS location of relay (and it’s own fixed position) and one to two sources of RSSI. It’s output will be the bearing and angle of the antennas.
A simple tracker uses RSSI or GPS only. The this guy link from above has a very nicely organized GitHub repo. I initially thought that his project included combined GPS/RSSI tracking, but it appears that it does not. Combining the two data sources has the potential to make a very fast and reliable tracker. A basic operation pseudo code is shown below:
RSSI_GPS_Track:
if RSSI is below signal threshold:
point antenna towards GPS
else if RSSI above signal threshold:
continue to track with RSSI
This would allow for very quick setup times as the tracker would not need to be manually aimed or scan back and forth until it picks up enough RSSI signal. It would also make the tracker resilient to a fast moving relay (not that that should happen) or to an obstruction obscuring the relay from the tracker. The tracker would not halt when signal is lost, but instead keep pointing at the general GPS position of the relay until signal is picked up again. This is already much more added functionality when compared to individual data sources, but there should also be more functionality with a better algorithm.
Other situations where this might come in handy:
- Rejecting other signals that create “false” RSSI readings
- Signal path reflections?
- Very weak RSSI
- More?
An algorithm that can use both sources, assign them a “reliability” index of sorts, and then decide which source to trust more would accomplish the goals of the simple tracker while also adding the above functionality (hopefully).
I have the option of writing my own algorithm, but I’m sure there are algorithms out there that do this, its just a matter of figuring out the right search terms. Here are some that I have found:
- Automatic Weight Learning for Multiple Data Sources
when Learning from Demonstration - (emailed Matt for help with search terms)