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
Randy,
Nice catch on the firmware in the hexacopter. It was frozen for an AMA demo last August and I never updated it. It was my Tarot 650 Sport quadcopter that I was using to test the AT last summer so I fired that up and it had v3.2 copter code in it. Here are some fresh logs with the quadcopter and AT. It still exibits the same pitch issue where it continues to point down. I even armed the quadcopter to see if it made a difference. The HUD images show an almost exact position for the AT and copter in my house. Both were near windows.
I attached the log files from the AT (36.BIN) and the quad which seems to have the correct date using v.3.2 firmware. When the weather breaks, I will try to test it outside with the quadcopter up in the air. Perhaps there is a baro issue on my Pixhawk in the AT since that is the only thing changed from last summer. I may try Jakob's firmware again since I have forgotten if it worked on this current AT setup. At the very least, it may provide a tie-breaker in determining a software/hardware issue.
36.BIN
2016-02-13 16-12-41.bin
I uploaded Jahob's v0.7.2 firmware for Pixhawk and both yaw and pitch worked fine. This is good evidence to focus on an issue with the AT v0.7.5 and v0.7.6 releases.
I attached the AT and quadcopter logs from the Jakub firmware test. They may not have any useful data as this release was from before the AT logs worked.
One thing to note is that the telemetry communications between the GCS and AT were not as good using Jakub's firmware as when using the v0.7.6 release so this does appear to be an improvement in the v0.7.6 release.
38.BIN
2016-02-14 10-05-20 46.bin
Greg,
I never tampered with telemetry options and there must have been some improvements since my last version. I will soon merge my changes with current version to enable logs and improve telemetry. It is good to hear that my version works fine, it proves that your hardware setup is fine.
Tracker with OSD
we were having an issue with tracker, while using OSD, the Mavlink data from the tracker is getting into the OSD, and the OSD is not filtering the data correctly, and so is showing tracker altitude rather than the planes altitude.
the solution is to fix the OSD code to filter GCS data out.... but in the meantime, Randy suggested turning the SR(port to plane) values to 0 in mission planner extended params (for tracker). This should stop the tracker sending on its data to the plane.
No problem with your response delay as it is winter here in NY. If the tracker thinks it's pointed down at 72deg then this is accurate for the actual position I saw. I will try reversing the Pitch control again. Perhaps I didn't reboot afterward so I will try that too. When your new version is available, I'll test it again and post a log so you can verify the fixes. Thanks for the update!
Randy,
I tested the AT with v0.7.5 firmware again with the pitch set to normal and then back to reverse. In either setting, the pitch would simply go to the extreme down or up position of my min and max settings. I saved the .bin files and attached them here along with some graphs similar to your initial one above. At the end of the graphs, the yaw changes are me moving the AT to see if I can get the pitch back in range. It always stayed full up or full down. My setup only allows for the AT to point down about 30 degrees from forward.
22.BIN
27.BIN
Greg,
Txs for the logs.
So the logs show the ATT.Pitch is mostly about 25 degrees which matches the angle you're seeing it point at meaning it's unlikely to be an estimation issue, and more likely to be a control issue.
Could you try setting RC2_TRIM to 1500? It's a bit of a guess...
If it was a compass issue, I do not think it would maintain a constant offset as the AT rotates. Most of us are using the Pixhawk internal compass as it is most convenient. The Pixhawk internal compass has proven to work very well in copter applications. Compass direction can also be verified in the MP HUD so you can see that your setup is proper with a manual rotation of the AT.
A previous theory was that the issue may be due to AT setup changes that cannot yet be properly compensated for by the firmware. For example, my setup limits the Pitch to 90 degrees and the Yaw to 180 degrees. This is an AMA requirement when flying at an official field. The suspicion was that perhaps the calculations required 180 or 360 degrees as others have their AT set up for.
We consider the AT firmware still "green" at this point and hope that it will become more robust in 2016. A more robust AT firmware should help eliminate setup issues or define better limits for user setup and operation. Today, we are having fun experimenting to make a better AT. :)
Totally agree with you. Just thinking and trying to help.
I also hope this AT solution gets matured as soon as possible. It's really the best out there. Features like auto tuning and better integration in mission planner for example.
But I'm already happy the way it works with Jakb's firmware.
For me, now, it tracks spot on...
The video I posted was from my AT setup last summer. I haven't actually used my latest setup in the field which has a different Pixhawk installed. My initial test of it last week in the backyard seemed to have the yaw pointing properly so it will be interesting to see the performance this spring.
-
32
-
33
-
34
-
35
-
36
of 113 Next