figuring out the Antenna Tracker

3691139590?profile=originalNot many people know but we have an piece of open source software for controlling an Antenna Tracker.  It's been built by Tridge (Arduplane lead developer) for use in the outback challenge.

Sadly we have no documentation and, as far as I know, nobody except Tridge has used it.  Still given Tridge's track record on building great software I suspect it works well and if it doesn't, I'm sure we can fix it.  So to not let this piece of code go to waste, I'd like some help from people who are interested to give it a try and help me figure out how it works.

Here's the little that I know:

  • It runs on any of our supported board (APM1, APM2, PX4, Pixhawk, Flymaple and perhaps VRBrain)
  • For APM1/APM2 users building the code is as easy as opening our hacked ArduinoIDE and selecting File > SketchBook > Tools > AntennaTracker and then building in the normal way.  For PX4/Pixhawk, our autobuilder doesn't automatically build a binary but I can provide one if people are interested.
  • It can control a Pan and Tilt gimbal like this or this found on
  • It may or may not require a GPS
  • It must somehow receive vehicle position updates from the ground station which has the telemetry radio that is connected to the vehicle. Maybe through a USB cable.  Tridge probably uses the python ground station, MAVProxy, to passthrough the vehicle position data to the AT but perhaps we can get MichaelO to build out a similar feature in Mission Planner.
  • I imagine this antenna tracker could also be used to keep a camera focused on the vehicle which might be good for easing the burden on creating videos of our vehicles.

So if you want to give it a try please do and stick any findings, questions or issues below. Alternatively Issues can go into the issues list.

I'll start sticking things into the wiki as they become clear.

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


            • Randy,

              Nice catch on the firmware in the hexacopter. It was frozen for an AMA demo last August and I never updated it. It was my Tarot 650 Sport quadcopter that I was using to test the AT last summer so I fired that up and it had v3.2 copter code in it. Here are some fresh logs with the quadcopter and AT. It still exibits the same pitch issue where it continues to point down. I even armed the quadcopter to see if it made a difference. The HUD images show an almost exact position for the AT and copter in my house. Both were near windows.

              I attached the log files from the AT (36.BIN) and the quad which seems to have the correct date using v.3.2 firmware. When the weather breaks, I will try to test it outside with the quadcopter up in the air. Perhaps there is a baro issue on my Pixhawk in the AT since that is the only thing changed from last summer. I may try Jakob's firmware again since I have forgotten if it worked on this current AT setup. At the very least, it may provide a tie-breaker in determining a software/hardware issue.



              2016-02-13 16-12-41.bin

              • I uploaded Jahob's v0.7.2 firmware for Pixhawk and both yaw and pitch worked fine. This is good evidence to focus on an issue with the AT v0.7.5 and v0.7.6 releases.

                I attached the AT and quadcopter logs from the Jakub firmware test. They may not have any useful data as this release was from before the AT logs worked.

                One thing to note is that the telemetry communications between the GCS and AT were not as good using Jakub's firmware as when using the v0.7.6 release so this does appear to be an improvement in the v0.7.6 release.


                2016-02-14 10-05-20 46.bin

                • Greg,

                  I never tampered with telemetry options and there must have been some improvements since my last version. I will soon merge my changes with current version to enable logs and improve telemetry. It is good to hear that my version works fine, it proves that your hardware setup is fine.

  • Developer

    Tracker with OSD

    we were having an issue with tracker, while using OSD, the Mavlink data from the tracker is getting into the OSD, and the OSD is not filtering the data correctly, and so is showing tracker altitude rather than the planes altitude.

    the solution is to fix the OSD code to filter GCS data out.... but in the meantime, Randy suggested turning the SR(port to plane) values to 0 in mission planner extended params (for tracker). This should stop the tracker sending on its data to the plane.

  • Hi Randy,
    No problem with your response delay as it is winter here in NY. If the tracker thinks it's pointed down at 72deg then this is accurate for the actual position I saw. I will try reversing the Pitch control again. Perhaps I didn't reboot afterward so I will try that too. When your new version is available, I'll test it again and post a log so you can verify the fixes. Thanks for the update!
    • Randy,

      I tested the AT with v0.7.5 firmware again with the pitch set to normal and then back to reverse. In either setting, the pitch would simply go to the extreme down or up position of my min and max settings. I saved the .bin files and attached them here along with some graphs similar to your initial one above. At the end of the graphs, the yaw changes are me moving the AT to see if I can get the pitch back in range. It always stayed full up or full down. My setup only allows for the AT to point down about 30 degrees from forward.



      • Developer


        Txs for the logs.

        So the logs show the ATT.Pitch is mostly about 25 degrees which matches the angle you're seeing it point at meaning it's unlikely to be an estimation issue, and more likely to be a control issue.

        Could you try setting RC2_TRIM to 1500?  It's a bit of a guess...

  • Anthony,
    If it was a compass issue, I do not think it would maintain a constant offset as the AT rotates. Most of us are using the Pixhawk internal compass as it is most convenient. The Pixhawk internal compass has proven to work very well in copter applications. Compass direction can also be verified in the MP HUD so you can see that your setup is proper with a manual rotation of the AT.
    A previous theory was that the issue may be due to AT setup changes that cannot yet be properly compensated for by the firmware. For example, my setup limits the Pitch to 90 degrees and the Yaw to 180 degrees. This is an AMA requirement when flying at an official field. The suspicion was that perhaps the calculations required 180 or 360 degrees as others have their AT set up for.
    We consider the AT firmware still "green" at this point and hope that it will become more robust in 2016. A more robust AT firmware should help eliminate setup issues or define better limits for user setup and operation. Today, we are having fun experimenting to make a better AT. :)
    • Hi Greg,

      Totally agree with you. Just thinking and trying to help.

      I also hope this AT solution gets matured as soon as possible. It's really the best out there. Features like auto tuning and better integration in mission planner for example.

      But I'm already happy the way it works with Jakb's firmware.

      For me, now, it tracks spot on...
      • The video I posted was from my AT setup last summer. I haven't actually used my latest setup in the field which has a different Pixhawk installed. My initial test of it last week in the backyard seemed to have the yaw pointing properly so it will be interesting to see the performance this spring.

This reply was deleted.


DIY Robocars via Twitter
RT @DanielChiaJH: Great racing against @a1k0n today at @diyrobocars! Pretty cool to both break sun-9s at the track today I think I got very…
18 hours ago
DIY Robocars via Twitter
Broadcasting the @circuitlaunch race live now at Races begin around 2:00pm PT
23 hours ago
DIY Robocars via Twitter
RT @a1k0n: ran a huge number of hyperparameter tuning experiments yesterday; now I can train a new policy, far with better quality, in 15 m…
23 hours ago
DIY Robocars via Twitter
RT @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
Sep 26
DIY Robocars via Twitter
Sep 24
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
Sep 23
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: Practiced at @RAMS_RC_Club today with my new @ARRMARC car
Aug 28