Not 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.
Replies
Steven,
Definitely DroidPlanner doesn't deal with multiple vehicles properly. I've raised an issue here a couple of weeks ago about this.
Ed -- It's a pretty major kludge what I did, and also I don't have the time to learn GIT in order to upload stuff. Basically, there's a "location_valid" flag that gets set to false if GPS information IS NOT received within a timeout period. I just kept the flag as true, and point the tracker to the last updated known position of the vehicle. I'm happy to send the file if you can compile it. It wasn't too bad by following the instructions at http://dev.ardupilot.com/wiki/building-the-code/building-px4-for-li...
As for pointing the AT to a specific location, it's something I desire too and looking through the code it's obvious how to implement it: I need to add a "guided" mode to the AT that takes a lat, long and alt as inputs and points the antenna there. All the code is in place, but figuring the interfaces out will take some doing. Moreover, the feature would need to be carried over to something like MAVPROXY so it can be exposed to the user. I looked through that code as well, and it's all doable with enough time ;)
For now, I just had to get the scanning to stop so my yagis don't get driven into the ground in case of comm loss.
-Ted
Do you mind if I merge your code into my fork and work on it?
Although a total kludge, I was able to recompile the AT firmware to keep the antenna pointed to the last known coordinate before loss of comm rather than going into Scan mode. It's more likely I will recover comm by trying to have my vehicle "rally" to the last known location rather than looking for the needle in a haystack by scanning.
1) The pitch always seemed to work well but the yaw was often 20 degrees to the left of the actual MRC location. I took Mission Planner snapshots of both my AT and MRC connections and the compass looked identical. Is there a procedure to eliminate the offset? Should I angle the AT hawk on its mount?
2) Sometimes the tracker would stop tracking and not recover until a power cycle.
3) The tracker would sometimes lag the MRC location and then catch up. Is this a PID setting? I haven't played with PIDs other than to use a suggestion from this thread. I had posted an image of my PIDs earlier.
4) With the buzzer plugged in on the hawk, I would occasionally get a short then long beep sequence. Any idea what this means?
your issue 4), your lost telemetry singal shortly you get short tone, then re-connect you get long tone. check your 3dr telemetry
Dick,
Thanks for the information. I disconnected the MRC telemetry and got the short tone on the AT. I then re-powered the MRC and got the long tone. I decided to disconnect my second telemetry link to the GCS for now and see if perhaps it was interfering with the AT to MRC link. I also discovered that my MRC power level was only 17 instead of 20 so I changed it.
Perhaps some of my other settings are not optimal so I posted an image below. I typically disable ECC because of the bandwidth usage and use a 33msec max window size. I wonder if using ECC and the "Standard Mavlink" max window of 133msec would provide improvements.
One other change I did was to activate the "Auto Declination" feature in both my AT and MRC. This change seems to have improved my compass settings so they match my hand compass on my desk. In a non-moving experiment, the AT seems to point directly to the MRC.In the images below, my AT was in my office and the MRC was on my porch. They seemed to be positioned perfectly.
We'll see what happens on the next field test.
Hi Stefan,
Thanks for the suggestion. I will try it on my next test. My AT was pointed West toward the MRC and the MRC flew North (to the right) and South (to the left) in the video.
My yaw I is 0.0 which came from my starting setup. It seemed to work ok in my backyard when walking the MRC around slowly but flying around is a different dynamic. The pitch still changes slowly when flying but the yaw can pass by the AT faster than walking. These are my PIDs used in the video.
-
77
-
78
-
79
-
80
-
81
of 104 Next