Updated for ACM 2.5.3 and APM 2.3.0 - Unified Ardustation 2 With Parameter Editing, Antenna Tracking and Auto Detection of Arducopter or ArduPlane

This is an update from the original blog post in October 2011:

I've updated the Ardustation 2  source code to allow compilation with Arduino 1.0 Relax and the latest libraries for ACM 2.5.3 and APM 2.3.0. This update also includes a modification of parameter names for PID editing that match ACM and APM. The updated version is 2.0.12.

The download zip file also includes the libraries used to verify compilation of the software. The software has been lightly tested with ACM and 2.5.3 and has not been tested with APM 2.3.0.  If you find any issues feel free to comment here or post an issue at the Ardustation 2 Google 

The software is available here:

http://code.google.com/p/ardustation-ii/downloads/list

Download 2.0.12 for ACM 2.5.3 or APM 2.3.0 - compile with Arduino 1.0 Relax

Download 2.0.11 for ACM 2.0.48 or APM 2.24 - compile with Arduino 0022 Relax

Heino R. Pull

The original 10/2011 info follows:

With the help of Jeff E and Hai Tran, I've updated the Ardustation 2 Antenna tracker code to support the detection of the UAV platform from the Mavlink heartbeat. Parameter download and editing is automatically configured for ArduPilot 2.24 or ArduCopter 2.0.48 when Mavlink connects. The key parameters available for editing is modifiable in the source code with the  PID gains set as the default for both platforms. A number of bug fixes have been made to previous versions of Ardustation 2 including a more standard Mavlink interface for the latest libraries distributed with APM 2.24 and ACM 2.0.48. 

 

This version has been ground tested with APM 2.24 and ACM 2.0.48 with parameter editing, but testing is still needed to verify that the appropriate parameters are changed correctly. Please be cautious if you try this software out and verify the parameter changes with the Mission Planner.  I don't have a fixed wing setup to test APM in the air, but I plan to test ACM 2.0.48 while tuning my loiter values on my quad this week. I've included the libraries used to compile the code in the zip file.

A video describing the original antenna tracking functionality is available here: Original Ardustation 2 Antenna Tracker Post and Video

The updated code is available here: Ardustation 2 ACM/APM Version 2.0.11

 

This software is based on Phillip Anthony Smith's Mavlink Ardustation. Thanks also to Jeff E and Hai Tran for their code additions and suggestions.

Views: 9018


3D Robotics
Comment by Chris Anderson on October 15, 2011 at 10:15pm

SO impressive. Love this!

Comment by Ian Beaney on October 16, 2011 at 3:44am
Excellent work
Comment by Kirill on October 16, 2011 at 7:21am

Looks very good! Well done!

Comment by Colin on October 16, 2011 at 10:11am

Nice work. I just had a play with this and it’s looking good. It’s a shame I spent the last couple of weeks doing very similar work.

I have been updating my version of Michael Smith’s Ardustation code (which used BinComm). It’s working fairly well now, with flight data and parameter editing (no antenna tracking). I’ll be ready to share it in a few days time- maybe we can “compare notes” so to speak.

Comment by Heino R. Pull on October 16, 2011 at 11:18am

Hi Colin - it sure is hard to know what others are working on the site  but I'm definitely interested in what you're doing. We should definitely compare notes and I'll check out your code also.

Comment by Andy Demartini on October 16, 2011 at 1:26pm

Heino,  Thanks for doing this!  Can you please explain how Ardustation would be set up if I am already using APM Planner with a 900 mhz XBee running at 57600 baud?  Does A/S just monitor the data stream?  Could it be placed inline with Mission Planner where it communicates with the airplane while listening to the downlink for the appropriate Mavlink packets?

Thanks,

Andy

 

Comment by mauricobain on October 16, 2011 at 3:24pm

Hi Heino,

Excellent work. You can use the ardustation and the Mission Planner with PC at the same time? Also, there are a thing that I don't understand, and is why you need to use the Xbee and the Patch antenna? The patch antenna is for FPV?

Thanks,

Mauricio

Comment by Heino R. Pull on October 16, 2011 at 5:09pm

Andy and Mauricio: The easiest way to run a computer with Mission Planner and an Ardustation is to use a total of 3 Xbees. One in the aircraft and then one for the PC and one for the Ardustation.  If all Xbees are on the same channel, they will "or" the data to the software in the aircraft automatically. Unfotunately, when working with parameters both the Mission Planner and the Ardustation will make requests on the transmit serial line for the aircraft to download the parameter values. Two xbees on the ground handle it pretty well.  It would be possible to use one Xbee on the ground but since the AS and MP need to independently send the command to download parameters, you would need to wire together the transmit lines from the computer and the Ardustation. This requires some kind of "or"ing of the signals such as an open collector arrangement with a pullup or a logic gate. Using an extra Xbee makes it all very simple at the expense of an extra Xbee. 

The Ardustation software only looks for parameter packets if it has been requested by hitting the menu selection so that is what adds the complication.

 

The patch antenna is indeed for FPV and I originally only used the antenna tracker function and ignored the parameter edit ability in my use.  However there were enough requests from users who wanted to also edit parameters - so the parameter edit function was updated to both APM and ACM parameter types. If the Ardustation is sitting on a moving antenna, it is awkward to try to use the buttons and display so that is why it is nice to be able to use the Ardustation for antenna tracking only and to simultaneously use a computer with Mission Planner for parameter editing.

Comment by Andy Demartini on October 16, 2011 at 5:42pm

Heino,

In my XBee setup, the two radios use each other's hardware address as a way to establish a "pair".  They connect with each other on power-up and implement an ARQ protocol to pass data.  I haven't seen a two-to-one XBee setup yet and am scratching my head as to how the X-CTU setup would be done.  Is this more of a broadcast mode, like the difference between TCP and UDP?  Enquiring minds would like to know ;-)

 

Comment by Heino R. Pull on October 16, 2011 at 9:17pm

Andy - That is a great question. I was very expedient 4 or 5 months ago when I wondered how I could get antenna tracking working while the Mission Planner was up on an Xbee and I searched and searched Google for what happens when more than 2 were up and running. I found a post - that I can't find right now that made it clear that in general it would be possible to have 3 and that they would mirror each other. I tried it and it seemed to work pretty well with default settings in XCTU with the same PAN ID for each module.  I also looked at the serial messages with my logic analyzer and the messages were intact with no interference that I could see. Since the parameter request mechanism only happens rarely, it semed that collisions would be a minor problem and when it seemed to work I stopped investigating.  

 

Now that you asked I'm very curious myself and did some hunting tonight in the docs. It is definitely broadcast mode and the key (I think) is that when an Xbee sees received RF data, it holds back the transmit buffer until the received packet is finished. The transmit buffers are sent after 3 character times of no serial data. So it seems in general a burst of serial data representing a Mavlink packet is held together (since they're pretty small for the ones I'm sending - Mavlink on, Mavlink off, write parameter, and get list of parameters). Therefore, if two Xbees transmit a request for parameters near to each other, unless they exactly transmittling the full packet at the same time, one wins and blocks the other while the a/c Xbee receives the command.  Yesterday when I was testing I did a scenario like that and watched the Mavlink request parameter list packet in the data stream within a few seconds of each other and saw a complete packet request from both ground Xbees. I'm sure there will be cases when two xbees will transmit RF exactly on top of each other and then I don't know and iin general I wouldn't want to create some kind of "network" in this mode, but for the case of two ground stations, it seems it will work pretty well.  

I'm frustrated though that there doesn't seem to be much info on the RF protocol for the proprietary XBEE 900 Pro long range protocol. 

You're definitely a much more advance Xbee user than I am, but I definitely needed to understand a little more about what's making them tick.  I'm still searching for more detail but they are really cool devices.  

 

The other thing I realize now is that trying to wire two ground Xbee serial transmit lines together would be really problematic since there would be no mechanism to hold a Mavlink packet together and it would be likely to clobber bytes to the a/c when two request parameter packets would be close to each other. The Xbees make this "or"ing more feasible.

Comment

You need to be a member of DIY Drones to add comments!

Join DIY Drones

© 2017   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service