Automatic Antenna Tracker

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

OverTheTop

Well-Known Member
TRF Supporter
Joined
Jul 9, 2007
Messages
9,521
Reaction score
8,797
Location
Melbourne Australia
An Automatic Antenna Tracker

I am building an Automatic Antenna Tracker (AAT) so my telemetry antennas will follow the rocket during flight. I figured this project is sufficiently epic and different that I should do a build thread for it. I have been sprinkling a bit of what I have been doing in the "What have you been doing rocketwise today?" thread as I have been going along. So here I am starting this journey of hardware to paper (ok, screens anyway).

Why an AAT?

I had thought antenna trackers were a good idea for quite a while but there was no compelling requirement to have one. I am building a Vertical Trajectory System currently and this uses the F765-WING Flight Computer by Matek and has some nice features:
http://www.mateksys.com/?portfolio=f765-wing
F765-WING_3.jpg

Here is a link to a somewhat documented VTS if you are interested:
https://forum.ausrocketry.com/viewtopic.php?f=56&t=6632

It is this VTS project that eventually spawned the AAT. This FC has many great features in excess of what is needed for trajectory control. It is crafted especially for the FPV (first person view) crowd that fly RC aircraft with a camera onboard. There is a chip on the FC that can take the High-Definition video feed from a camera and overlay it with data to further assist the pilot with situational awareness while flying. Having this feature there gave me impetus to add a HD camera to the VTS and then start using the OSD (on screen display) features:
CameraOverlay.jpg
This instantly gives me a really good snapshot of how the rocket is performing as it leaps off the pad and into the sky.

This is all well and good, but I need to be able to receive the transmitted video. We can all remember the days before digital TV where if the signal got weak the picture went snowy or went away. If my signal level drops that will also happen on this system, so I need to keep sufficient signal to noise ratio during flight. That is a measure of how much the signal is above the surrounding noise and a good indication of how good the picture will be received.

For a good introduction to antenna use and selection have a look at this link:
https://ardupilot.org/copter/docs/common-antenna-design.html

In a nutshell it means if you want the antenna to provide a better signal to the receiver it needs to be somewhat directional. If you get out of that beam then the signal falls off quickly. The AAT will keep a higher gain antenna pointed at the source of the transmission, giving the best S/N ratio and a better HD picture 😊.

Telemetry System

Now, I have never been known to go to excess with rocketry ( 🙄 ) but now you know, if you didn't already, where I got my forum name from. Things were getting out-of-hand with complexity, so I ended up drawing the relevant system diagram for my entire system:

TelemetryBlockDiagram.png
As you can see there is quite a bit going on and some built-in redundancy in the links!
  • Featherweight GPS Tracker. Basic stand-alone connection between the rocket and an iPhone on the ground. The transmitter is located in the avionics bay midway along the airframe. Standard stick antennas are used on this system at both ends.
  • TeleMega. This is my main rocket telemetry system and is in the nosecone of the vehicle. Additional deployment channels are used for live monitoring of voltages in my VTS. Receivers (TeleBT and TeleDongle) provide redundancy.
  • RDF900+ modem/transmitter. Located in the VTS module which sits just below the nosecone and above the parachutes. This is a well-specified transmitter, capable of up to 1W transmit power. A GNSS receiver provides location information which is then sent to this modem for transmission. The transmit antenna will be a dipole on the side of the rocket on the VTS module.
    The receive part of this is interesting as the RFD900+ is a diversity receiver. You can have two antennas and it will select the source with the best signal for decoding. In my case I have an omnidirectional whip and a yagi. If the signal falls outside the yagi beam width the receiver will be looking on the whip and pick up the signal there if it can. Receive location is available on the attendant PC and is also sent to the AAT to provide pointing information.
  • Video transmitter. This takes the HD video information provided by the camera and the OSD and transmits it. The transmit antenna will be a dipole on the side of the rocket on the VTS module. Receive antenna is a patch antenna.
Also note the four Bluetooth links to the relevant display devices. It is relatively easy to set up BT links using commercially available HC-06 modules that are essentially BT serial connections. I have done this for the AAT and the RFD900+ receiver links.

Next Up
So much for the introduction. Next up will be a discussion on the processor system that will track the flight.
 
The RFD900 is a diversity transciever. Not just a reciever.
Love the pair of RFD900 diversity transcievers. Best money I ever spent on radio gear. Rock solid performance. Tested on FPV to 74 km horizontally I believe..... Not by me.... No idea what it would get vertically.
 
So this is different but similar. I built this to help me find my rocket in the sky. I was tired of young kids (mostly college students) pointing to the sky and saying "Your rocket is right there !" and all I would see was, well, nothing LOL. It gets the GPS and altitude info from the rocket over LoRa, and uses it's own internal GPS to point to the rocket. I've thought about beefing it up so I could mount a small video camera on the pointer, but I never got around to it. I suppose you could mount a directional antennae like a yagi on it to get tracking of your video signal. It's not perfect but it works pretty good. I'd guess pointing accuracy is about a degree. The farther away the rocket is, the better it works.

The main rotation is handled by a brushed DC gearmotor with encoder, and the up-down pointer is on a hobby servo. It's got a simple boresight to look through.

1662121174680.jpeg

1662121193281.jpeg

1662121214390.jpeg
 
Last edited:
So this is different but similar. I built this to help me find my rocket in the sky. I was tired of young kids (mostly college students) pointing to the sky and saying "Your rocket is right there !" and all I would see was, well, nothing LOL. It gets the GPS and altitude info from the rocket over LoRa, and uses it's own internal GPS to point to the rocket. I've thought about beefing it up so I could mount a small video camera on the pointer, but I never got around to it. I suppose you could mount a directional antennae like a yagi on it to get tracking of your video signal. It's not perfect but it works pretty good. I'd guess pointing accuracy is about a degree. The farther away the rocket is, the better it works.

The main rotation is handled by a brushed DC gearmotor with encoder, and the up-down pointer is on a hobby servo. It's got a simple boresight to look through.

View attachment 535514

View attachment 535515

View attachment 535516
can you share the code for this.?
 
This with a tracking video camera mounted would be a very, very marketable item in this hobby. I would buy one in a second.
It wouldn't be steady enough for that. The kinetheodolites that you see getting shots of SpaceX and others' rockets from 80km or more downrange are very specialised pieces of equipment that also use visual information to help keep the camera on the bird.
 
The more directional the antenna, the closer you need to point the antenna.
I would consider a dipole setup; that gives a 180 degree field to work with. Not as much gain, but if you have a good transmitter it should be fine. a folded dipole like a FM radio antenna can be made easily for your frequency band.
 
Antenna Tracking Processor

The heart of the AAT will be a small processor module which has a small drone flight computer similar to what was used in the VTS. The F765-WSE by Matek is one that I had kicking around and luckily it is supported by my chosen firmware platform. It has an enormous number of features in a very small package.

https://www.mateksys.com/?portfolio=f765-wse

F765-WSE_5.jpg

Firmware


The firmware I will be running for this is Ardupilot. Ardupilot is an open-source vehicle control project currently in worldwide use. Many different types of vehicles (planes, quadcopters, helicopter, rovers, submersibles) are available to be controlled, and there is conveniently also an Antenna Tracker version.

https://ardupilot.org/

https://ardupilot.org/antennatracker/index.html

The system consists of:
  • Flight Computer
  • GNSS Receiver
  • OLED Display
  • HC-06 Bluetooth Communications Module
Connection to the unit is by a single DB25 connector on the end. Nice and simple.

Note that the unit must be attached to the moving boom of the antenna tracker and point in the direction the antennas are pointing. The processor uses the magnetometer, accelerometers and gyroscopes to determine where it is pointing in space.

The GNSS receiver (configured to receive GPS, Galileo, and GLONASS constellations) allows the unit to determine its location in order to calculate the relative position and direction of the flight.



Schematic Diagram


ProcessorSchematic.png
This helps me keep things straight in my mind as to what is happening in the module. Note that all block diagrams, schematics and interwiring diagrams in this thread are drawn on Altium Designer.

Hardware Connections

24V power is provided into this unit and it is regulated down by a switched battery eliminator circuit (SBEC) to other voltages. The generated 9V, 5V and 3.3V outputs are provided at the interface if needed.

Control of the two servos (pitch and yaw) for the altazimuth mount are determined by the processor and fed out the interface as PWM signals, like RC servos would expect. These are a pulse stream with pulse lengths of between 1ms and 2ms representing either end of the required positions of the axis. 1.5ms would be the midpoint. Other electronics turn these pulse widths to actual positions, just as a RC servo would. More on that in a future installment.

There is a Safety Switch which is used to arm the system. This is to make sure there are no unanticipated movements which injure anyone nearby when it gets enabled. This will also prevent damage to the mechanism.

Finally, there is a telemetry input (UART-based serial stream) which will have the location of the rocket during flight from the receiver/modem.

Debug Interface

The Bluetooth communications module is used for connection to a PC which is used for firmware updating, control parameter changes and debugging the system. This link should be needed only infrequently after system commissioning.

The 0.96” OLED display is also useful for diagnostics to some extent.
Display.jpg

Construction

The Processor is built into a small plastic enclosure. A small plastic sled was 3D printed and holds the display, GNSS receiver, USB and Bluetooth interfaces. It screws to bosses in the case.
sled.png
Holes were milled in the case for access to the display, USB port and interface connector.
InsideCase.jpg

A window was cut out of 0.5mm polycarbonate to suit, and glued in place to the ABS case with CA glue (Loctite 401).
Window.jpg

The flight computer was attached to the case with an industrial double-sided tape. Simple and effective.

A small filter was made to keep any extraneous interference from getting in on the safety switch wiring. This just goes inline with the wires and is covered by heatshrink.
Filter.jpg

A clamp was designed that would allow the Processor to be clamped to the rotating boom of the AAT. The clamp was 3D printed and metal threads were inserted where necessary to strengthen the threads.
FlatBaseClamp.png


I am currently printing these in PLA but once the concept is proven I will switch printers and get the parts in ABS.

These thread coils used are a little different to the traditional hot-insert parts seen in 3D prints. A helical metal spring is threaded into the plastic to become the reinforced thread.
xhelicoil-installation-process.jpg.pagespeed.ic.Q1sl9nWS8b.jpg
They are not inexpensive, at about $0.50 each, but they work well.

Holes were drilled and countersunk in the case for attaching the clamp.
ProcessorRear.jpg
Wiring internally was accomplished with nice flexible silicone-insulated hookup wire. Connections to the DB25 connector were properly crimped for reliability.

Wires were soldered directly to the PCAs in most cases, to save space. A small application of hot-melt glue providing strain relief where needed.

Next Up

Interwiring Diagram.
 
Last edited:
Interwiring Diagram

Interwiring.png
This is how it should all hang together :)

Next Up

The next installment will discuss the turret assembly, incorporating the altitude (aka tilt or pitch) axis. Note that there is extensive use of 3D printing for this project. That will continue 😊. 3D printing enables flexibility of design for parts that is unachievable through subtractive processes.
 
Last edited:
It just kills me seeing all this talent and intelligence, Makes me realize how primitive I am. Keep the pictures coming.
 
(I've only read post #1 and very fast skimmed beyond that. I' be back.)

Have you thought about making the data link bi-directional, uploading commands as well as downloading telemetry? I've been trying to think of a reason to do that. That is, what commands would one want to transmit? But surely we can think of something, just as an excuse, because making it bi-directional would be cool. A self-destruct command is probably a bad idea. Maybe a command to shut down the VTS if it misbehaves and set the canards to neutral? Ground command as a third redundant deployment mechanism? Add a second camera and use ground commands to switch views? Permit/prohibit a staging or airstart event?

Yes, I know, none of those are necessary things. It just seems like a shame to have a tracking antenna and not use it in both directions.
 
Ummmm. Cool topic but in reality I didn't have a problem pointing a hand held Yagi antenna at a flying rocket with a 70cm/400Mhz Ham band tracker in it. I ported the output to a map and knew where to point my Yagi until touchdown. Still to setup and have the antenna be pointed automatically would allow one to stare at the computer screen full time to track and not have to worry about antenna pointing.
900Mhz stuff is a different ballgame.
I've read were a 900Mhz multi-element Yagi antenna would be a bear to aim at a rocket that is out of sight. But I've also read where folks have done it successfully without a problem. They get the rocket back using a 900Mhz Yagi.
I tried a 900Mhz Yagi with my Eggtimer trackers though they just quite went out of sight for a very short period of time. Had no problem with tracking and getting the rockets recovered. The Yagi did increase the ground footprint of the tracker for terminal recovery. Proved it by switching out the 900Mhz Yagi to the standard vertical dipole and the signal disappeared as I approached the downed rocket. Put the Yagi back in and got a final position fix to get the rocket.
If one is doing out of sight stuff routinely, GPS telemetry/tracking is the way to go for the last 20 years or so. Can recover quickly and go fly your next rocket without dinking on the recovery. Find the rocket and can go back and fly more that have been pre-prepped!!!
Kurt
 
Ummmm. Cool topic but in reality I didn't have a problem pointing a hand held Yagi antenna at a flying rocket with a 70cm/400Mhz Ham band tracker in it.
I have used patch antennas and yagis as well for tracking, no problems with handheld. This is more to keep the HD video feed on-beam and an interesting project.
 
Very cool project. I'm subscribed.

We do this manually with our flight computer tracking app. Our iPad app gives us a direction arrow and an azimuth to aim the attached yagi. It uses the iPads built-in GPS and compass and calculates against the incoming long/lat/alt of the rocket. A drone flight computer is a great cheaper alternative, as it will have a reliable compass (the hardest part).

I've always wanted to build something similar for camera tracking, but GPS wouldn't cut it. To do the poor man's version of the NASA Kineto tracking mount I considered an android device with three cameras (focal lengths) running TensorFlow at 240 fps to determine where in the frame the rocket was and then adjust the servos to recenter the rocket. Ultimately, that mount could hold a camera, an antenna, or anything else, but it would be optimized for the up part of the flight not down. Maybe someday...

A few years ago, we switched our radios over from point-to-point FSK to a LoRa mesh network. We still use a Yagi on the handheld tracker, but we put another radio into mesh mode (as a repeater) and attached it to a 50' high antenna out at FAR, so now we get lossless packets even when the rocket is buried in the dirt five miles away. The LoRa mesh radios have been amazing and simple to use, but they won't work for your COTS camera, so an ATT is still in order. On board video transmission is next level!
 
This with a tracking video camera mounted would be a very, very marketable item in this hobby.
But would it? Even without the video (because of the steadiness issue) I bet it would cost an arm, a leg, and half of the other leg.

The more directional the antenna, the closer you need to point the antenna.
I would consider a dipole setup; that gives a 180 degree field to work with. Not as much gain, but if you have a good transmitter it should be fine. a folded dipole like a FM radio antenna can be made easily for your frequency band.
But he's got a whip going into that RFD900.
  • The whip gives more field of view than a folded dipole, although that's probably not really necessary.
  • A folded dipole gives a bit of gain on axis, but that appears also not to be necessary; the whip gives enough of a link to get the Yagi pointed on target (according to post #1).
  • The Yagi then gives a much better S:N than either a whip or a dipole, which is necessary for good video (again, according to post #1).
  • The whip is smaller and simpler to build than a dipole.
Given the high gain Yagi is needed, one might as well make the low gain antenna as small and simple as can be adequate.
1662570186906.png
-----------------------------
Well, that brings me up through post #12, and lunch time is over.
 
Since when has anyone paid attention to what these things cost? 🙄
Well shoot. The OP emailed me and said it was to keep a camera aligned on a flying rocket automatically. Yeah, motor jitter would have to be dealt with but perhaps hardware is available that is economical to do that. If not, the OP would probably abandon the project. A well set tripod for a small camera would likely get a stable platform as long as the pointing electronics don't vibrate too much. The biggest problem is a close-in shot of a rocket on the pad. The pointing "motors" and image monitoring would have to respond intantaneously for the shot off the pad.
That's a though nut to crack. Zoomed out shots would probably be less hard to frame. Kurt
 
Well shoot. The OP emailed me and said it was to keep a camera aligned on a flying rocket automatically.
Are you sure there's not some misunderstanding there? What he's said in this thread is indeed that it's about a camera and alignment and stuff, but the camera is on board the rocket and the pointing is to maintain the data link.
 
Turret Assembly/Tilt Axis

Construction for this axis starts out on a 6mm aluminium plate. Holes were drilled and counter-bored to accept screws to hold the two bearing supports. Seven more holes were drilled and tapped to provide a mounting location for the hub which goes underneath and is driven by the large stepper motor (19mm diameter keyed shaft) in the pan drive system. There was also a hole added for the wires to go from this axis down to a cable chain and the base mount.
MillPlate.jpg

Two bearing support brackets were 3D printed. Holes were cleaned out with drills and then thread inserts were added for strength when tightening up the screws. Helicoil inserts were chosen as I have successfully used these in the past. Bearings were held in place with three screws on each side. The stepper motor was screwed to one of the supports using capscrews, and the pulley added to the stepper shaft.
BearingSupports.jpg

Note that the stepper motion control system was mounted to a 3D printed support that screwed directly onto the back of the stepper motor. This is a TIC36v4 motion controller from Pololu and is a very capable position/rate controller. It has many features which will be described in more detail in a future post.
https://www.pololu.com/product/3141

TIC1.jpg

A small bracket was printed to hold the opto sensor for the homing of this axis. When a pin (attached to a shaft collet) goes through the gap it breaks a beam of light which signals to the motion controller the home location of the shaft has been reached. It does this automatically when the unit is turned on.
Opto.jpg

The axle shaft for this axis is a 19mm carbon-fiber tube. This was chosen as it is very low mass and I am trying to keep the inertia of the moving system to a reasonable amount. That will translate to faster operation. It was inserted through the bearings approximately into the correct position.

An aluminium coupler was turned, machined and then slit, to allow the drive pulley to clamp the shaft properly.

The drive pulley and a belt set (same as used on 3D printers) was purchased and bored out to suit the shaft, then screwed to the aluminium coupler. The standard grub-screw attachement for the pulley is not suitable for use on a CF axle.

Collet2.jpg

An assortment of clamps was sketched in CAD and printed out to fix various items onto the shaft:
  • Collets to fix the position of the shaft
  • Flat mounting plates for the Processor, telemetry receivers x 2.
  • Mount for 900MHz whip antenna
  • Mount for 900MHz Yagi antenna
  • Mount for 1.3GHz patch antenna
Attachments.jpg

Where necessary, holes were drilled and M4 threaded inserts were added to allow the clamps to be fixed to the shaft.

Mounting plates were added to the Processor, video receiver and downlink receivers.
VRxPlate.jpg

A small plate was designed and printed to hold a 4mm carbon-fiber rod that will help with cable managements on the shaft. This was fixed to the back of the Processor using VHB tape.
CableMount.jpg

A second limit switch, for the other extreme of travel, was added to avoid the motor drive damaging any of the antennas or drive system. A simple snap-action switch was used this time, rather than an opto. A screw head on one of the collets activates the switch if the motion exceeds the expected range.
LimitSwitch.jpg

Wiring to the Processor plug was done, using very flexible silicone-insulated wires. These were dressed and run to assorted locations where needed.
ProcessorWiring.jpg

The TIC36v4 controller was connected to a PC, via USB, and configured for the system. In this case I am using the “RC” interface in which pulse width sent to the controller (from the Processor) determines the position of the shaft. Step counts and end locations were determined empirically and entered where needed in the configuration.

I do have some truss structures designed and printed to give the bearing supports more lateral support and will add these later after debugging the mechanism. They will limit access to the stepper area somewhat.

That completes the description of the tilt axis mechanism of the system. Now I will spend a little more time on the cable-chain arrangement between the rotating turret and fixed base in a future post as I am still designing that part of the system.
 
Last edited:
Back
Top