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
Great analysis work, thank you.
I'm a little slow to follow. Could you explain why the 3DR module experienced 2x the data rate?
It is a guess but technically each device is sending a MAVLink stream to all devices it can access. In simple scenario (Pixhawk + Mission Planner) we get only one MAVLink stream from Pixhawk to MP (MP doesn't send nearly as much data back to Pixhawk as the other way around). With 2 Pixhawks and MP every one of them sends their own MAVLink plus it relays the other one's MAVLink which leads to massive data traffic but again, it's just a guess
Since you were using USB for half the chain, shouldn't you have plenty bandwidth? Unless the Tracker is actually sending its own useless MAVLINK info to the aircraft,rather than just relaying the GCS data.
My knowledge here is obviously limited, so forgive any ignorant assumptions I may be making.
Maybe Randy can shine some light on how the Tracker affects MAVLink traffic.
Unfortunately tracker is sending its own data to the plane..
Jakub,
Thanks for the AT testing and detailed explanations. I believe that APM:Copter v3.2.0 and v3.2.1 should work fine as I am using it on several APM 2.6 MRCs.
Although I am using a Pixhawk on my AT, the communication issues still exist when connecting the GCS to the AT so I have disconnected that 3DR radio link for now until the basic AT setup is working better. My next goal is to eliminate the AT to MRC telemetry link losses of which Dick Ou gave me some direction to try.
I look forward to your results testing on problem #2 as I have seen this issue in my setup. Until now, I thought it may be telemetry link errors but I never saw them on my ground tests. When loitering, the pitch could be wrong in one spot and then correct itself when the MRC was moved to another loiter spot. I guess that this is the same principle of varying air pressure pockets that the Neutral Density filter fixes on my GoPro camera.
I have been spending a good amount of time with MAVPROXY, and while it's very powerful, as mentioned previously you can end up with a loop if you're not careful (my setup has 4 instances of MAVPROXY running).
With respect to the barometer altitude, I kludged in using the GPS altitude to point the tracker. The reason being is that I also kludged in the ability to point the tracker to an arbitrary position by disabling the "scan when signal is lost" function (which is what might be happening to some of the folks who are seeing weird behavior of the tracker). By doing so, I can send IGPS Mavlink messages to the tracker from my ground station, and have the tracker point to the arbitrary location specified by the GPS message. Since my version of tracker exclusively uses IGPS to point, I don't need to send barometer messages to get the pitch pointed.
For my application, absolute accuracy is not such a big deal since I have a pretty wide beamwidth, so the GPS pointing should work just fine.
I'm not much of a coder, nor do I know how to drive GIT, but I'm attaching my code changes to tracking.pde if anyone wants to include it in their fork. My changes are documented in the code with the word "kludge". It might resolve some of the issues I'm reading about in this thread.
tracking.pde
On my second test of the APM: Antenna Tracker, several of my issues seemed resolved and my main issue is now the occasional loss of the telemetry link. Although I was still using the v0.5 firmware, I had enabled Auto Declination and unplugged the 2nd telemetry unit that links to the GCS. I also increased my power settings from 17 to 20 on the telemetry link from the AT to the MRC. The Antenna Tracker never seemed to stop like in my first testing and the yaw control seemed better with an occasional lag in catching up. I did not change any PID settings from the previous test.
My Antenna Tracker points a 5.8GHz helical antenna to the video downlink on the MRC. The APM telemetry units use onmi-directional antennas and should normally have no problem with a short distance link as seen in the video. I posted an image of my telemetry settings. Perhaps someone has a suggestion for improving the robustness. I was also thinking of trying the RFD900 Radio Modem so telemetry is no longer my weak link.
APM: Antenna Tracker Test 2 from Gregory Covey on Vimeo.
I had same problem as you before, I use 3dr for pc to AT and xBee for AT to MRC, first you can try to uncheck Op resend, if problem still there, try to upgrade your 3dr firmware to Sil 2.x, you can download firmware at http://www.rfdesign.com.au/firmware/ and its configuration tool at http://www.rfdesign.com.au/downloads/
Dick,
Thanks for the suggestions. I will try them both and see if the telemetry disruptions go away.
It also looks like Jakub and Randy are on the trail of the GCS link issues.
I made the Op Resend change to my AT and MRC so I'll test that next before upgrading the SiK firmware. We finally got a good rain day here so I am happy my grass is growing but unhappy that I cannot test my AT until next weekend.
-
79
-
80
-
81
-
82
-
83
of 113 Next