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

            • I cloud not get this version, with GPS-alt, to work.

              The pitch is still at the same 45° position. and the Yaw is turnig left right all the Time. Back to previous version Yaw works, pitch still 45°.

              What If seen is that the bank angle very often is 10° or 15° left or sometimes to the right.

              nevertheless I´ll continuing tomorow.

          • Andre,

            If you want you can try my experimental firmware (I haven't tested it yet). I attached it to this post. It uses GPS altitude, not baro altitude. It is very much untested - what I mean, is that I didn't have time to upload it and try it in my tracker (it is raining outside). I once had a very similar firmware and it worked perfectly until I accidentally deleted it... Now I recreated it from memory with some improvements.

            If you decide to try it make a backup of your current parameters before you upgrade. If it doesn't work - don't worry, downgrade to what you have now and I will work on current version :)

            Just a heads-up: It may point with negative offset (instead of going up it may go down) because I am unsure if I got all the additions and substractions correctly.

            AntennaTracker-v2.px4

            https://storage.ning.com/topology/rest/1.0/file/get/3702846360?profile=original
            • Developer

              Jacob,

              Feel free to submit PRs as well back to master.  The tracker needs love.

  • A demo of the tracker I've been working on for a long range line-of-sight link.

    https://youtu.be/RWhsQ6oWfQo

    • Ted, nice video demonstration. Is this a university project or bid proposal?

    • Very nice demonstration, good work. Can you elaborate on MAVProxy configuration? I had problems with similar setup, since Plane firmware and MAVProxy seems to relay MAVLink packets back and forth. 

      • Hi Jakub,

        It took a while to get a better grip on MavProxy, but the key is to differentiate between what is defined as a link and what is defined as an output. They are denoted by the direction of the arrows on my block diagram. The arrow points FROM a MavProxy OUTPUT to a MavProxy Link (aka --master from the command line). Messages that come FROM and output are forwarded only to the first ACTIVE MASTER link. Messages that are received on a link are forwarded to ALL outputs.

        You can definitely get into loop situations if you're not careful. I think that MavProxy is overkill for this application as each instance is a full on ground station that has more smarts than is warranted (i.e. they each send heartbeats and set stream parameters unless actively disabled). Right now it works for me, but it seems that the same functionality could be implemented with the unix socat (http://linux.die.net/man/1/socat) command.

        If you need specific guidance on what I did with MavProxy, let me know and I'll do my best to try and explain.

        Regards

        -Ted

    • Developer

      very nice!  good smooth movements on the tracker.

      • Hi Randy, I am wondering what the AT performance differences would be between a relatively closer MRC and a plane that is farther away using the same AT. When using manual mode with slower changes my AT seems to perform well. However, when tracking an MRC that is 30 meters to 150 meters away the AT sometimes has issues. I guess the point I am trying to make is that following a simulated vehicle is one thing and following real MRCs and Arduplanes is another. Has there been any thought to changing how the AT works for tracking an MRC versus a plane?

        • Developer

          MRC = multi-rotor craft?

          The way it works is it maintains an estimate of where the vehicle is using it's location, heading and groundspeed (reported by the vehicle on the telemetry link).  Those updates probably arrive at 1hz ~ 5hz so between those updates it just projects forward where it thinks the vehicle is based on the last update.

          I suspect there's a sudden jump in the vehicle's estimated position when an actual update arrives.  When the vehicle is far out, that jump doesn't affect the tracker's desired pitch and yaw angles much but when the vehicle is close the angular change could be very large.

          Another likely problem is the lat, lon positions are reported as 4bytes floats instead of 4byte integers which reduces their accuracy to about 1m. If we used integers it would be 1cm (normally you'd think floats are more accurate but not in this case).  This could also lead to very rough estimates of the vehicle's position and thus target angles.

          The controllers in the tracker are pretty simple and could certainly be improved in many ways including fixing the issues above and adding extra filters to keep it all smooth.

This reply was deleted.

Activity

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