Warning #1: Compass calibration and reducing interference is far more important than with 2.9.1b
Warning #2: GPS glitches can cause sudden and aggressive position changes while in loiter mode. You may wish to reduce the Loiter PID P to 0.5 (from 1.0) to reduce aggressiveness (see image below of where this gain can be found in mission planner).
Warning #3: optical flow is not supported but will be back in the next release (AC-3.0.2 or AC-3.1.0).
Warning #4: loiter turns does not maintain altitude. This bug will be fixed in AC-3.0.2.
Warning #5: This release has only been lightly tested on Traditional Helicopters.
Improvements over 2.9.1b include:
WPNAV_SPEED, WPNAV_SPEED_UP, WPNAV_SPEED_DN, WPNAV_ACCEL allows configuring speeds and acceleration during missions
How to upgrade:
1. Make sure you are using Mission Planner 1.2.59 or newer (get it here)
2. Click on the MissionPlanner's Hardware, Install Firmware screen. The version numbers should appear as "ArduCopter-3.0.1", then click the appropriate frame icon and it should upgrade as per usual.
3. Reduce the Loiter and Alt Hold PIDs if you have modified them from the defaults. The modified PID values for the 3DR frame can be seen in the image below.
Note: Nav parameters have been combined with Loiter so do not be concerned if you can't find them.
5. Try out the new version in stabilize mode first, then alt-hold, then loiter and finally RTL and Auto.
Numerous How-To videos are available:
Special Thanks to Marco, DaveC and the large number of testers on the pre-release thread who put their copters at risk during the extended testing period. Some of their videos can be found here, here, here, here, here and here. Thanks also to MichaelO for the MP changes required for this release.
All feedback welcome. Please put your questions, comments (good and bad!) below.
Super Happy! No more manual tuning, I hated that, and was never satisfied cause I sucked at it and I don't particularly like hanging onto it when its running. The tuning part is probably what has driven people away from APM. Now if I change my setup, extra battery or heavier camera I can simply autotune and save those PIDS for a particular setup.
No longer a RED LED.
Using vs 3.0.1 with a APM 2.5.
Something happened and I've no Red Led. I was only connecting to fly. The GPS Blue does its thing correctly but, I've no Red. I can Arm the copter and fly it. I can Disarm, connect to MP, collect logs, change, write and refresh parameters. HUD updates normally.
I've reflashed Firmware - I've erased EEPROM and then reconfigured. I've dismantled the copter and even with only connecting the GPS and APM to the USB still no RED. Do they burn out? I've not tried to connect external LEDs yet.
Another unrelated oddity.
I did notice in my search an odd situation. If you connect to the MP via USB then open a terminal window you get the datastream from the vehicle. I could not close the app and had to kill it. I restarted then connected to the vehicle through the Terminal APM connect. The APM seemed to be stuck in some loop because when I went into the Terminal and connected to download logs a stream of odd characters again streamed in the window and I could not shut down MP again without killing it. After another cycle of killing and starting the MP I did get back into the logs to download them. Yes, I know you are not supposed to connect via USB and terminal. Could you put the USB connect and disconnect button back onto the terminal screen? Often you are connected and go into terminal and with no indication or ability to disconnect you have to go to another screen to do so.
You're just running out of flash space on the AVR. If you try to compile with Arduino (which uses a slightly older version of the compiler) it won't fit anymore. You'll need to turn off some features before doing the make. Check the APM_Config.h. You'll see a bunch of #defines in there to easily turn off OPTFLOW or MOUNT or some other features that you might not need.
I've never heard of one of those LEDs burning out but I suppose it's possible.
Re the terminal window...the weird stream of characters are mavlink messages. Not readable by humans but mission planner can decode it into all the altitude, position data etc that you can normally see through the flight data screen. Normally when you enter the terminal window the first thing mission planner will do is force the apm to reset (i.e. reboot). Maybe that reset is not getting through sometimes. By the way, if you're not using the USB cable (i.e. you're using telemetry), the APM will refuse to reboot if it's been powered up for more than 30 seconds or if the motors are armed.
So no idea what happened to my RED? How do I start a cycle of the LEDs? Was that the old AutoTune with the left stick down and right for ~20 seconds?
Yeh, that shouldn't be a problem at all. However, generally speaking you should be able to tune the copter in your lightest setup and that should be fine for any of the heavier setups. Just don't do it the other way round!
If it's an APM2 then the red light should always be either flashing or solid (depending upon whether it's armed or not). If it's always dark then it doesn't sound good. Yes, you could test the cycling of the leds by doing autotrim but it's not really testing anything different that what you're testing by simply powering the board.
WPNAV_SPEED_DN will be used for the portion of the landing that is above 10m. Below 10m it should use the LAND_SPEED parameter. Best to provide a dataflash log.
You can check the maximum speed of your copter by flying it at top speed while maintaining altitude in stabilize mode and then looking at the dataflash message's GPS lines. Try graphing the ground speed. Most copters are between 13m/s and 18m/s maximum.
Looks like the twitches are coming from the radio input. If you're using a high speed futaba and the APM is running an outdated ppm encoder you should upgrade it using these instructions. If it's an official 3dr board purchased before Mar 2011 you could have this problem.
The logs look like the yaw is being controlled reasonably well. Maybe your compass orientation is incorrect. Did it work fine on AC3.0.1 but suddenly it's drifting in AC3.1?
Modifying that parameter should take-effect immediately and yes, you can set it to any value you like. I can't comment on it not sticking. That sounds like a mission planner issue...if it's reproduceable you can stick an issue in the mission planner's issue list. Make sure to include detailed directions on how to reproduce the issue.
I am able to compile the code with Arduino.
tell me what to do.