Flying Antenna Tracker (Relay Copter)

I decided to make a relay copter which would allow to fly planes/copters BLOS (in adjacent valleys, or flying out from a deep valley over a plateau). What I thought would be an easy project turned out to be a headache with many dead ends.

So the basic idea is to develop a copter and control software which would allow retransmission of both analog 5.8 Ghz video signal, telemetry, and RC control signal through a copter between GS and a plane/copter. The relay copter must fly in almost autonomous mode, so that one would control only the plane, and communicate with the relay copter through a few, simple commands.

The plane must have good video link and RC control range of 50 km.

The key idea is that the copter would act like a tracker, both on ground and in the air.

So these are a few of the issues which need to be considered:

  • Video Link, from plane though copter to GS
  • RC from GS through copter to plane
  • RC from GS to copter
  • Telemetry from plane to copter (for tracking)
  • Telemetry from copter to GS, both of plane and copter
  • Software for copter control

One of the key ideas is that the copter would track the plane using yaw control of the copter for azimut, and have a servo to incline the main antenna (which points to the plane) in elevation. The antenna from copter to GS would also be directional, also with the inclination controlled by servo.
There is no need for azimut tracking towards GS, because the copter tracking software will always try to put the copter between the plane and the GS, i.e. plane, copter, and GS would always be aligned on one line.

The hardware part was relatively easy to design and fabricate: The key piece is the main antenna, 21 dbi patch antenna of about 28 x 28 cm. and with a weight of 480 grams “as is”.

The antenna can be moved from about -15 degrees to down to 45 degrees using standard servo (there is a small mistake in the lever connecting point, I had to extend it in the final version). The weight of the whole assembly is 190 grams.:

When pointing at 45 degrees, the antenna barely clears ground, so for take offs and landings that is its home position:

On the other end, there is the smaller antenna mechanismo for pointing in elevation, which weighs 40 grams, without the antenna:

So the total weight of the video retransmission is
Main antenna: 480
Mount and servo: 180
RC305 and cable: 60
Secondary anntena: 40
Mount and servo: 40
VTX: 20
TOTAL 820 grams

This configuration allows the following:
Main antenna - plane: with a 2 W transmitter with standard dipole, vertical polarization:, on the plane

  • acceptable reception to 70 km., provided the pointing is good.
  • good reception to 50 km.
  • crystal clear video to 30 km.

What I do not know how the retransmitter VTX would affect this, I ran short tests which seem to indicate that the interference is not that bad, but a real world test is really necessary.

Now, on the copter to GS side, I will have a supposedly 17 dbi patch antenna (which is closer to 12..14 dbi), 7 x 14 cm. I have run this antenna for standard copter flights, with 2 W on copter and distances to 10 km. providing flawless video (i.e. dipole to patch).

My main objective is to reduce the power of the VTX to eliminate/reduce potential interference to the main antenna. A directional antenna is very good at it, that is one of the reasons to use it for this connection leg.

I pretend to allow the copter to fly to no more than 8 km, i.e. that is the maximum distance for video link. Since I will have a 12 dbi antenna instead of the dipole, I can reduce the transmission power to about 1/10 of the VTX with dipole antenna, i.e. just 200 mW.

The exact optimum power setting would have to be determined experimentally, but a 200 mW power would guarantee almost perfect video to 8 km.

The separation between the main antenna and secondary antenna is close to 45 cm.

The Radio Control Link.

This was the first big headache I had. The initial idea is to have one Radio on GS controlling both the copter and plane. The GS to copter link is ELRS 2.4 Ghz for the time being. With 1 W Transmitter I had pretty good signal to 16 km, so that it is more than enough to have rock solid control for a copter at 8 km.

ELRS sucks for the transmission of data, especially transparent modem link. I probably will dump it in favour of mLRS 2.4 Ghz system later on, and for the time being I will not be able to get telemetry from the plane to GS.

The copter to plane link would be through mLRS 900 Mhz, configured for minimal bandwidth and with an expected stable range of 60 to 80 km., although this was not tested out (it is for the first time I am using mLRS, always used Dragon Link 433 Mhz for long range).

Now, I immediately ran into an issue which is not completely solved yet.

First problem was that I was not able to feed SBUS signal to mLRS transmitter, it stubborny does not want to accept SBUS. It works fine with CRSF, but I can not easily obtain CRSF signal on the copter, i.e. the ELRS receiver is configured as SBUS, but SBUS fed to mLRS did not work, although the FC accepts it flawlessly.

So, I decided to read all RC channels in lua script, reconfigure a MAVLINK2 packet with RC OVERRIDE COMMAND, and send it to the plane FC. This so far has not worked out, I spent like 10 hours debugging and trying out, the FC of the plane refuses to accept it.

So the next idea was to generate a SBUS signal on the plane side using a pi pico, feed it with a data stream from mLRS receiver which would contain the RC channels, That worked very well, and in less than 1 hour I had it up and running, no CRC, no Mavlink headers, IDs, I really think that MAVLINK sucks a lot.

The only issue now is that the stream is generated by lua script on the copter side, and there is always a risk of lua script crash. So I decided to put a pi pico on the copter side as well.

So the way it would work: ELRS transmits to copter ELRS receiver which outputs SBUS. This SBUS is connected to both copter FC for control of the copter and to pi pico on the copter side, which reads and decodes SBUS packets, and then resends then through mLRS serial link to the plane.

On the plane side, the packets are received by the pi pico, decoded, and reformatted to SBUS sentence and sent to plane FC.

I can also easily implement a diversity switch on the plane side pi pico, i.e. to have a physical ELRS receiver on the plane for close range LOS control. The failsafes must be carefully programmed so as not have a disaster (no failsafe, when one occurs)

Finally discovered the issue with ELRS Rx - mLRS Tx connection. The only way to make it work without extra hardware and programming is to set ELRS RX output to inverted CRSF and at 400000 baud, then the mLRS Transmitter started working.

However, that same change broke the ELRS - ardupilot FC connection. One can invert the RX pin of the RC IN Uart, but it seems that ardupilot does not recognize 400000 baud crsf format.

So I will have another ELRS receiver on the same ELRS transmitter for the copter control

Hi @Michail_Belov,

Txs for the post! This is worthy of a blog post I think because I’m certain others also want to do this kind of thing. I could simply convert this discussion into a blog post but we’d want to move an image to the very top to make it appear on ardupilot.org properly. No pressure though, if you’re more looking for feedback then a discussion is also good, txs!

Have been working on the script. Initially, it was very hard because there is no good documentation about exact bindings available (what is on ardupilot.org seems to be outdated, there are piece meal examples in the github, and the AI is extremely good at inventing functions and calls which do not exist).

It could be a very good deal for the Ardupilot developpers to concentrate on rewriting good manuals rather than trying to introduce new features.

One of the issues I faced was that I needed a stable GPS Guide mode with yaw control, which seems not to exist. The way I solved it was by injecting rudder input with guided mode set to GPS target. It works fine, but it is really hacking the system. There are options to set yaw, but it involves also the direct control of the pitch and roll, which is too complicated (aka more risky).

The copter flight is divided into several stages which can be called up by a simple dial switch.

FIRST COMMAND: TAKE OFF and INITIAL CLIMB
The idea is that the copter first takes off and climbs to a certain safe hard-preset altitude (something like 20 to 100 meters).

From there, it will do initial climb and reposition at 45° degrees up to a certain Altitude, which is the INITIAL_HOVER_ALT. The pilot during setup stage can set that altitude to anything from 200 to 2000 meter (using a toggle switch and a pot). The copter will climb in the direction to which it was set on the ground. During the climb, it will be yawing (=tracking) the plane. Once it reaches the preset altitude and corresponding GPS position, it will hang there, simply tracking the plane by yaw.

SECOND COMMAND: FULL TRACKING
The pilot, during the setup stage can set two variables, MAX_HOVER_ALT and MAX_HOVER_DISTANCE, in the range 200..2500 and 200..8000 meters. The copter now will position itself on the line which goes from GS to plane and then fly out. If it is off by more than 9 degrees (i.e. GS-plane line and GS-copter line), priority is given to rejoin the line (basically, it will navigate to the left/right from its GS-copter line. If it is less than 3 the copter flies directly towards the plane. If the difference is intermediate, it will try to rejoin the line at a shallow angle. In all that it will also climb to the MAX_HOVER_ALT. When copter reaches the MAX_HOVER_DISTANCE, it will stay there. If the plane, for example, flies to the left, the copter will start moving to the left as well, always trying to keep itself on the line between GS and plane and not going beyond the MAX_HOVER_DISTANCE. The yaw always controls the pointing to the plane.

THIRD COMMAND: STOP
Issuing this command will stop the copter (i.e. it will stay where it is), but it will continue to track in yaw the plane. One can go back to SECOND COMMAND or to FOURTH COMMAND from there

FOURTH COMMAND: Return to GS. The copter will fly back and descend to the safe initial altitude (20..100 meters).

FIFTH COMMAND: LAND
This would involve putting the main antenna in the take off position (down 45 degrees) and stop tracking in yaw the plane and slowly land.

SIXTH COMMAND: RTL (unconditional) if everything looks bad… Also, there will be a direct switch which bypasses the LUA script for calling this mode

Some considerations: The navigation speeds will be set pretty low, probably maximum speed of around 8 m/s, climb up at least 6 m/s, climb down: here I will have to test it out, ideally I want to set a high speed as well, but worried about downwash. I am thinking of setting the descent speed in Lua based on pitch/roll. If there is a pitch/roll which suggests an air speed of at least 5 m/s, I think that I could set the descent speed to something like 6 m/s or slightly higher as well. otherwise a safer descent speed of 3..4 m/s would be set. Also for the return flight a potentially higer navigation speed would be set, maybe 12 m/s.

I can not use high speeds because the antenna is very nice airbrake which could push the power consumption up considerably even at moderate speeds

By the way, why there are two legs, INITIAL HOVER and MAX HOVER? When you start the mission, your priority is to clear first the ridges so as to have good LOS to plane and not to crash into mountain side. So the first leg is designed to have a climb slope of 45 degrees, which from my experience would clear almost any mountain slope. After the initial climb, the next climb can be much shallower. To assure a reasonable angle, the speeds, vertical and horizontal must be set accordingly. More than 45 degrees could produce problems with antenna pointing (between GS and Copter), so this is the practical maximum limit.

So far I have written and preliminary air tested the first two commands. Here is the lua script if someone wants to take a look (not finished, not verified, at your own risk, but I hope the ideas are good):
RETRANSLATOR_08.lua (33.4 KB)

Discovered issue with altitude control. Not sure what is happenning, but after issuing vehicle:set_target_location(Copter_target) command, the copter correctly flew to the GPS position, including altitude. After that it stayed there for about one minute, but began slowly descending. Is it normal behaviour for Guided mode, after the vehicle reached the destination? During this time, there were yaw commands issued for yaw control tracking, but the target was not updated, i.e, no vehicle:set target commands were issued. There was no LAT LNG drift at all

Looking deeper into it, during the second section of flight, the target altitude was constantly updated, at a rate of 10 HZ:
Copter_target:alt(MAX_HOVER_ALT * 100)
vehicle:set_target_location(Copter_target)

MAX_HOVER_ALT was fixed the whole time at 50 m, and home was set Field Elevation Set: 141m, so it should be 191 m absolute GPS. But the graph below shows considerable variation of altitude, and the descent and bobbing up and down were noticeable from the ground (it was not a GPS drift). For this flight, I did not have Baro logging enabled, but I believe the baro altitude was also changing in a different flight, although I am not 100 % sure.

The graph below is from yet another flight, but it shows the correlation between GPS and BARO, which seem to indicate that both work correctly.

Any ideas as to why?

first, nice project. Nice to hear that you considered mLRS, and sad to hear that using sbus with mLRS gave you issues. mLRS works in fact fine with sbus. It needs to be configured however properly, the key is “Tx Ch Source” = “in” (see mLRS-docu/docs/BASIC_SETUP.md at main · olliw42/mLRS-docu · GitHub). That part should be easy enough. What might be less easy and indeed can be a source of confusion is on which pin on the tx module the sbus input is to be applied. This depends on the specific tx module you are using.
cheers

Thanks, olliw42! Yes I will try and retest SBUS. Most probably I missed the correct setup because I was trying things in the “dark”, and the correct configuration slipped by.

After fighting for two days with unexplained altitude changes which I initially attributed to my programming, it turned out that the barometer is failing, the ahrs:position is not very good at catching this, and I had to revert to gps:location as the main source for altitude.

It worked finally very well.

The test speeds were very low, 1..4 m/s to be able to follow it.

I was able to fly a complete mission just by switching one rotary switch with 6 positions:

I enabled a fake plane which was going round the base, and the copter followed it exactly as expected, tracking it by going where the copter is supposed to be (on the line betwen GS and Plane), yawing towards the Plane, and also following the inclination of the plane.

And it landed within 1 meter from where it took off.

Next thing would be to determine maximum descent speeds, because when I was flying the copter manually, vertical descents from about 3.5 meters started to produce very strong oscillations. The problem is that the copter is supposed to fly high, and you can get high very quickly (even at a rate of 12 m/s). But going down is another story.

However, when you fly horizontally, the speed can be increased by maybe 70 to 120 %. My idea is first to set up final flying weight, retune the copter for that weight, then determine safe vertical descent speed, and then determine safe descent speed versus horizontal air speed. I do not prentend to use air speed directly, but rather determine which inclination corresponds to what air speed (aprox.). So if I have 8 degrees of pitch, I would know that I am flying at 30 km/h. And on the basis of these 30 km/h I would set the maximum descent speed.

Another thing for going down quickly is to use a minimum horizontal speed. So initially, the copter flies back to the home base at a good speed (20..40 km/h) which allows for efficent descent. Once it reaches the Home and if the altitude is still too high, than it will do a falling leaf maneuver. It will fly out from where it came to a certain limited distance (a couple hundred meters). Than it will stop and go back to Home. If it still to high, it will repeat, If the altitude is less than 100 meters, it will start landing directly.

By the way, there is a script somewhere which makes a quick descent in acro mode withg circling around the target. It has one big issue, it requires yaw input, and generally this is a very destabilizing factor, i.e. I prefer not to use yaw too much in critical and marginal situations.

Thus far the copter frame weighs 1800 grams with everything, motors, props, electronics, excluding batteries and excluding retransmission equipment. During the tests, it was flying at about 3860 grams and with 6S 8000 mah nominal Lipo which gives around 18 minutes of flight time. Also, it was too light, to tune it well. It has hovering throttle at around 0.09, this also gives some vertical positioning issues. After increasing weight I think I will improve its performance considerably.

Final version weights:
Airframe all inclusive: 1800
Retransmission: 800
Two liion batteries 24 cells each: 2500 (24 ah nominal)

Total: 5100 grams
From my experience, going beyond 50 % of weight for batteries has diminishing returns, so even if one could add another battery (the copter should have maximum TOW of 10 kg, short hover and 8 kg. permanent hover), that would add just minutes to the total flight time.

For the final setup with these Xrotor motors (3115- 1050) I doubt that I can fly much longer than 30..35 minutes, so for the time being it will be just a test bed. I need about 70..90 minutes of flight time to be useful (which can be achieved by using high efficiency motors and huge props).

There are final two ideas I have:

  1. One is that one can tether this copter, and I think it could go to maybe 200 meters tethered. But for mountains this does not solve anything. It has the capacity to carry 200 meters of double 20 awg cable and high voltage converter for that.

  2. The other idea is to make a turntable on to which the copter will be placed. So when you start the mission, you first let your normal copter/plane fly off and you start tracking it by using the retranmission copter which is on this turntable and which follows the target plane/copter by using a servo in the turntable, inclination of the antenna by the copter itself (with a limited up angle of about 15 degrees as designed now). When the plane begins to come close to the point where it could go beyond the LOS, the retransmission copter would be given the command to fly off. This would reduce the air time considerably, especially if the ridge is far off and plane needs time to get there. The climb of the retranmission copter can be very fast actually, it can reach 1000 meters in about 1.5 minutes.

The lua script in the copter would control the servo (continuous rotation). The copter could be connected to it through a simple connector which would disconnect on take off, and on basis of the compass it would determine when to cut the servo rotation.

There is copter fast descent script in examples IIRC (if not look into applets). It descends on helical path.

I saw it, but it has one big problem: it is helical. When you try to go down as fast as possible, you should not use yaw, as it is a destabilizing factor when close to limits. I prefer to do back and forth movements (in fact, when flying manually in acro mode, that is my prefered method as well - drop at 15 m/s, if you still do not make it, stop, turn around and fly out).

Ran some endurance tests, got a very nice surprise. I simulated full weight copter with 48 cell liion (5.1 kg) and with a Lipo discharge 6S 6400 mah it gave me a hover time of 12:45 minutes.

If I used the 48 cell liion pack, and adjusting for losses due to voltage sag, that same set up would give a hover time between 43 and 49 minutes (depending on the cell and discharge limit, I go for no load 3.0 V resting voltage), which is incredible for 18 buck motors (Hobbywing Xrotor 3115 - 1050) and 8 buck props (APC 15 x 4)!

There is another trick to extend hover time, and this is to fly slowly, especially with big props you can expect a drop by about 10 % in energy if you fly slowly, around 25 to 30 km/h. Since the copter would be hanging most of the time in the same spot, one idea is to see if there is a pitch angle (due to wind). If there is no wind, then I may introduce a slow back and forth flying pattern, i,.e. the copter would go a couple of hundred meters forward and then return.

With such algorythm another 4 minutes could be added to the total flight time (becoming 47 to 53 minutes).

Also, a dirt cheap way of adding another 1.5 minutes is to swap props for 16 x 4 APC (unfortunately, APC does not have bigger ones with low pitch and pushers). So we may get close to 50 minutes of theoretical flight time.

Another 1.5 minutes could be gained by using 900 kV motors instead of 1050 kVfrom the same brand.

Could not resist building the rotating turntable… it was a very easy project, took me less than a couple of hours designing and an overnight printing, but it is almost done…

Turntable uses a ball bearing which is pressed into the base, and the rotating part is pressed on to the axis (it is 52 o.d. 25 i.d.). A continuous rotation 50 gram servo rotates the whole thing easily. The legs of the copter would be placed in these shallow leg restrainers so that the copter would not fall off. The servo cable would go through the axis (axis is a hollow 25 mm. pipe) and would connect to the copter through simple pins. Since the antenna has a relatively limited upward movement (15 degrees), the uneven leg supports would provide an extra 7 degrees of inclination. I believe that should not affect arming of the copter.