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
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
I've started implementing guided mode in my fork here:
https://github.com/stefantj/ardupilot/tree/stefantj-ardupilot
It seems to work well with the 'fly-to' feature, though I have not tested it very much.
Let me know how it works for you if you give it a try.
-Stefan
Do you mind if I merge your code into my fork and work on it?
Go for it, sorry for the slow reply.
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.
When you start, are you pointing the AT north?
It looks like your integral gain (YAW2SRV_I) is set to zero, so the PID loop won't fix a small error. Try increasing it (other people are using 0.01-0.1) and see if it fixes issue (1).
I've also run into 2) and 3), I think the last one is related to GPS latency. I am not sure if the location struct is predicting the position of the aircraft or simply returning the last known location.
-
81
-
82
-
83
-
84
-
85
of 113 Next