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
I mean with "baro=0" the altitude in the HUD shows 0. You mean the press_abs should show 1013 Hpa?
Yes my press_aps show actual 1012! :-)
I´ll try now your version with GPS alt.
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
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
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?
-
73
-
74
-
75
-
76
-
77
of 113 Next