Developer

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 servocity.com.
  • 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 –

Replies

      • So what is considered a safe distance then?

        • Developer

          a 5cm separation perhaps?  I didn't measure it but somewhere under that distance the servos would start twitching, move the radio away and it stopped.

    • It was relatively warm outside today for the last day of January in upstate NY so I took my AT and copter out to the backyard. Another weather oddity for this winter is that my backyard was snow free! :)

      Anyway, I made another set of logs (20.bin) for Randy with good GPS locks. The yaw was perfect and the pitch non-functional using the v0.7.5 firmware.

      On the HUD, is there a way to clear the purple path once things settle down and aren't moving around?

      3702615330?profile=original3702615370?profile=original

      20.BIN

      • Developer

        Re the purple line, I haven't played with it much but maybe try reducing the "Track Length" on the MP's Config/Tuning, Planner screen?

      • Developer

        Greg,

        Sorry for taking so long to review your logs.  It looks like the pitch servo output is maxing out at 2100.  I guess you've tried reversing the pitch servo?  So try setting RC2_REV to +1 (it's -1 at the moment).

        By the way, reviewing this log uncovered an issue with the logging of the desired attitudes.  I'll push out Tracker-0.7.6 with a fix for that shortly.

      • I have been working on a copy of the AVR version of this project and I have replicated this same inconsistent pitch problem. In an effort to add something to solve this pitch problem I will share what I have found. I discovered that the following functions are called at different points 

        void Tracker::arm_servos()

        {    

            channel_yaw.enable_out();

            channel_pitch.enable_out();

        }

        void Tracker::disarm_servos()

        {

            channel_yaw.disable_out();

            channel_pitch.disable_out();

        }

        What I have discovered is that once the pitch servo is disabled the call to arm the servo sometimes does not happen. I don't know why it was only pitch that was affected. To work around this I added a

        channel_pitch.enable_out(); 

        to the servo.cpp update pitch servo function before the 

        channel_pitch.calc_pwm();

        channel_pitch.output();

        Once I did this the pitch has not failed to update. The reasons why the call to arm the pitch is unreliable I still don't know. Hope this helps in some way. 

        • I will look into that once I diff my (working) version with 0.7.5

  • Randy,

    Yes, I'll extract it tonight and post.
    • Randy,

      Here is the .BIN file from my testing. I also downloaded it via Mission Planner and ZIPed the various files together. I am not sure what the difference is so it is probably the same information in different formats.

      This was my AT HUD.

      3702614485?profile=originaland this was my copter HUD.

      3702614248?profile=originalSatellite count and HDOP was good on both units. The placement of the AT and copter show various positions in my house. It is cold outside this time of year in NY. :)

      v075Log3.zip

      3.BIN

      https://storage.ning.com/topology/rest/1.0/file/get/3702614347?profile=original
      • As a side note, I realize that testing indoors is not recommended but I could rotate the AT left or right and see the yaw correct but the pitch always remained down even when I tipped the AT forward or backward. If I reversed the pitch checkbox in the Extended Tuning screen, the AT always pointed straight up using the v0.7.5 firmware.

This reply was deleted.

Activity

Jose Araujo liked Jose Araujo's profile
Aug 29
spencer harvey liked spencer harvey's profile
Jul 9
More…