Warning #1: an issue has been found with Tower's Pause button which can cause the vehicle to fly to an old position if the vehicle has not sent a position update to Tower in some time.
Warning #2: Copter-3.3.2 fixes a bug found in Copter-3.3.1's desired climb rate initialisation which could lead to a sudden momentary drop when switching from Stabilize or Acro to AltHold, Loiter or PosHold.
Warning #3: Copter-3.3.2 fixes an issue found in Copter-3.3.1 which could lead to hard landings in RTL or AUTO if the WPNAV_SPEED_DN was set too high (i.e. >400 or 4m/s) and/or the WPNAV_ACCEL_Z was set too low (i.e. <100 or 1m/s/s).
Warning #4: a bug was found in Copter-3.3 which could cause a sudden crash if you abort a Take-off initiated from a ground station. Video description is here. The bug is fixed in Copter-3.3.1 so we recommend upgrading.
Note #1: AC3.3-rc8 corrected a long standing bug in the HDOP reporting. HDOP values will appear about 40% lower than previously but this does not actually mean the GPS position is better than before.
Note #2: if upgrading from AC3.2.1 the vehicle's accelerometer calibration needs to be done again.
Note #3: set SERIAL2_PROTOCOL to "3" and reboot the board to enable FrSky telemetry like in previous versions.
Note #4: the wiki will be updated over the next few weeks to explain how to use the new features
Copter-3.3.1 is available through the mission planner. The full list of changes vs AC3.2.1 can be see in the ReleaseNotes and below are the most recent changes since AC3.3.
Sadly this version (and all future versions) will not run on the APM2.x boards due to CPU speed, flash and RAM restrictions.
Changes from 3.3:
1) Bug fix to prevent potential crash if Follow-Me is used after an aborted takeoff
2) compiler upgraded to 4.9.3 (runs slightly faster than 4.7.2 which was used previously)
Changes from 3.3-rc11:
1) EKF recovers from pre-arm "Compass variance" failure if compasses are consistent
Changes from 3.3-rc10:
1) PreArm "Need 3D Fix" message replaced with detailed reason from EKF
Changes from 3.3-rc9
1) EKF improvements:
a) simpler optical flow takeoff check
2) Bug Fixes/Minor enhancements:
a) fix INS3_USE parameter eeprom location
b) fix SToRM32 serial protocol driver to work with recent versions
c) increase motor pwm->thrust conversion (aka MOT_THST_EXPO) to 0.65 (was 0.50)
d) Firmware version sent to GCS in AUTOPILOT_VERSION message
3) Safety:
a) pre-arm check of compass variance if arming in Loiter, PosHold, Guided
b) always check GPS before arming in Loiter (previously could be disabled if ARMING_CHECK=0)
c) sanity check locations received from GCS for follow-me, do-set-home, do-set-ROI
d) fix optical flow failsafe (was not always triggering LAND when optical flow failed)
e) failsafe RTL vs LAND decision based on hardcoded 5m from home check (previously used WPNAV_RADIUS parameter)
Thanks for your testing!
Replies
Hi Pomaroli,
I have not been happy with the aggressiveness of Yaw after Autotune. I have worked out why and the next release will result in much sharper Yaw response after Autotune.
The problem was I was not using the full throttle range for the yaw test and backing off the acceleration as well. The new Autotune will still back the acceleration for roll and pitch off to 90% and Yaw to 75%. So you can increase both of these a little before getting to the limit. I chose these numbers to give sharp performance without any overshoot. For fpv racing you may want to increase these until you see a little bounceback after big inputs.
For racing though I tend to find that lower rates and accelerations help with smooth flying provided it doesn't get too slow. The lower accelerations only tend to be a problem if you want to do those really fast flips and rolls. Then you need to push the acceleration to the absolute limit.
hi Pomaroli,
I set it in the parameter tree. It doesn't reset there. But it seems you tried to do that. Maybe you need to look at it there too.
Hi Pomaroli,
Save the parameter file and see what it says there.
Hi Peter,
That is a hard question to answer. I has some advantages in the basic ACRO performance and probably some disadvantages.
Some of our advantages is our throttle linearisation is much better than TPA. We have a variable Yaw mix that lets you tune the point at which your copter spins out rather than roll roll or pitch (very extreme flight here). Depending on the controller and pid choice you have the pixhawk will provide significantly better stability at maximum and minimum throttle. The other big difference between Arducopter and some of the other autopilots in ACRO is we use a stabilized acro controller. That means that when you are going through extreme maneuvers (fpv racing), the copter may cavitate and drop a prop but it will bounce back to your last position.
All this is heavily dependent on how well you set up the controller and this setup wouldn't be practical if Autotune didn't do most of the work for you. We are also working hard to ensure we can squeeze every last bit of performance out of a given frame.
The other point I want to highlight: There is great work being done in all of these autopilots and they are achieving fantastic performance, the points I made above may not apply to all other autopilots. Arducopter is a little behind in some small areas and way ahead in others. Because we aspire to be the best across the board it is hard to push the development of ACRO as fast as I would like to.
What I can confidently say is that the pilot will be the biggest limiting factor given a well setup and manufactured copter.
I would say the biggest disadvantage arducopter has in this space is the size of the controller. I am hoping we can get a next generation micro pixhawk in the formfactor of the naze32 / multi wii boards.
Still to be implemented is full quertonion stabilization (currently use euler angles). We want to do an update of the code to run the rate loops with the gyro read and bypass the io chip. This will ensure we have the absolute minimum latency and jitter. To improve acro further we will need new ideas.
Other than the wires they are fully compatible. They are "full" pixhawks as far as the firmware/GCS is concerned.
2 issues I have with them are [and now there is a V2 that fixes one of them] all the leads are wired backward, so the PM has to be re-wired and it has no speaker or battery.
But it's 1/2 the size and weight and now you can even get them in a case :)
There are quite a few "mini" out already. They are called Pixhawk Lite. And they work really well.
Have you tried to change it via the full parameters list? It should let you set any value i think and keep it.
I read a post by Randy saying the PPM Channel Mapping issue would be resolved before 3.3 went final. Does anyone know if that is done?
It's done. I am flying with it - it works well.
Hi Andy,
I am still having issues with RCMAP in rc5 with my Pixhawk, using cppm via a Frsky DR 4 II and a JR PCM 9x with Frsky tx module.
In the full parameter tree (Mission Planner) I change the channel assignments to match the JR (TAER from AETR).
Perform a Radio calibration which all works fine then go flying. Trouble is the craft always rolls to the left.
This has been the case for me since I switched to 3.3, worked great in 3.2.
If I use a FrSky 8 channel RX via the PPM converter, plugging the channels in appropriately, and not using RCMAP all is OK.
Is there something I am missing?
-
342
-
343
-
344
-
345
-
346
of 449 Next