I've release a new version with an additional 5 parameters for Arducopter:
Added missing Arducopter parameters stab_d, stab_d_s, acro_p, axis_p, axis_enable for a total of 47 parameters. Compatibility with ACM 2.5.3 and APM 2.3.0
The new release is available here:
For the git setup I used Tridge's guide http://code.google.com/p/ardupilot-mega/wiki/GitGuide for TortoiseGit and setup the remote updates using step 5 - so that git sync->Fetch/Rebase works from the master and git sync->Push works for my clone.I'm still in the crash course for git, but I normally don't want to automatically get updates from the master until I'm ready for them, or I would create a branch. I git->sync when I'm ready for new changes.
As far as changing the flow rates for parameter reads - it hasn't been needed as long as the Mavlink parser is happy. Pulling all the parameters was working ok - even with the issue I started seeing with individual parameter updates. It was when the Mavlink message length requested from the "start feed" was getting larger than the Xbee's transmit buffer that I started having issues. By eliminating one of the sets of feeds, everything now seems to be rock solid without disabling all of the Mavlink flow. Of course if the Mission Planner is also running, there could be more traffic set up and I need to beef up the parsing of the existing Mavlink messages. Mavlink returns a parse status and I need to see how that can help resetting processing if the Xbee truncates a message. Mavlink 1.0 is also on the horizon and I need to check that functionality also.
As far as the changes - are you using the ATMEGA 328 (Ardustation) or a larger processor? The current code is very short on ram and it is a battle to add new stuff without taking existing stuff away. You may want to branch if you're using the 328 since new main menu items have blown the heap when I first started from the original Ardustation code. There is a free memory check at the end of the main PDE that you can use to see where you're at as you're modifying.
Thanks for the comments. I'm using a plain vanilla Arduino Mega (rev3 I think) so in my case there should be plenty of SRAM I guess although I haven't really checked. I did notice the method you mention though and I guess I should check eventually.
I guess some people may start turning their "old" APM1280 into GCS's or antenna trackers (I actually still intend to fly with mine) so there may be potential in the future. Do you think 8KB may also not be "enough" for a while? Guess I should really check how much I use now.
In case you are interested: uploaded my changes to
In order to use the other LCD I had to pull out the lcd.print calls. Despite this I think it should be all still "backward compatible" to the original hardware. Also I added the MAVLINK10 new way of sending GPS packets. Well, in case you consider it useful have a look.
Thanks Andre, I'll pull it down and try running on the hardware. I'm working this week on the MAVLINK10 transition of the code anyway and it will be great to see what you've done.
I don't think you'll have any memory issues on the ATMEGA - its the 328 that is so tight.
I pulled your clone down and was able to compile in backward compatibility mode for the 1280, but not for the 328. The errors were coming from the use of the extra serial ports not on the 328. I am interested in the changes for Mavlink 1.0 and the GPS processing and I'm having a look at how you set that up. Thanks!
I've just finished a bug fix for a nasty Mavlink parameter update issue and added all D parameters. This will be released tomorrow as Ardustation 2 version 2.0.14. The source code is available now in my Ardustation II git clone.
where can I find the version?
I was involved with a developer meeting yesterday and didn't get a chance to upload, but I'll do it later today. I'll post here for sure when I have a chance to do it.
If you can use git - the info to pull it down is here:
I just added a new forum post announcing the release of 2.0.14.