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
Does APM Leak?
Without fail if I leave my bird attached to a power supply for a couple of hours when I try to connect to MP via USB it wont connect. I wondered if there was a memory leak.
Reset the PH and it's all good.
Not the end of the world ( I wish we were getting several hours of flight time :) ) but it might be in the future.
Have a habit of leaving hawks plugged in USB and going to sleep than to work and coming back the next evening to a fully working hawk. I suggest you carefully examine your board for cold solder joints and sometimes no-solder joints :) start with the USB plug as it's rather easy do damage one.
Ditto with me. Generally the airframe stays on all the time. I have a paper clip nearby to do a reset occasionally when I am playing adding hardware or tinkering with setups.
Wouldn't surprise me if it's a Windoze problem. I've had it completely forget config for the 3DR data link, usb drivers the lot.
This is all on a desktop, My business 8 core 32gig ram PC running Win 7.
what you are describing is not uncommon for a windows vm inside osx - you have a lot of driver virtualization going on and it is typically not the best approach for dealing with hardware level device drivers. The best approach for dual-use of the macbook pro is to use bootcamp and boot natively into windows. then your device drivers become more direct between hardware and OS.
if you do not want the inconvenience of dual booting then another option is to pick up a cheap windows 8 tablet or laptop and use it solely for "utility", e.g. mission planner, 3dr radios, arduino devices, updating device firmwares etc.
Also I would not chance trying to update firmware on a usb > ftdi / rs232 / ttl device using a virtualized machine-
hrmm.. i was wondering what that puddle was under my quad.. memory goo everywhere ;p
I don't think so. I left one on over 24 hours once and it was still running.
Hi Ian,
Like Rob I have also left a pixhawk running for 24 hours. I have done one up as a logger for different purposes. All I did is set the standard copter code to log while disarmed.
IMO some of this "hanging" that has been noticed could be attributed to the OS / device driver side and not the pixhawk side. I just wanted to mention this if anyone is using machine virtualization to run windows, and uses the windows VM to connect to usb hardware devices. things can get flakey right quick. Heck, windows is flakey enough without virtualization thrown into the mix :D
question- maybe a bug? i just took the big quad out for a maiden flight today, got her up in the air no problem on AC 3.3 RC12, using PosHold, Drift and AltHold modes just to test things out. in Drift mode, the auto-stop was a bit sloppy, there was one time it just kept going even with all hands off the sticks. but other than than really nice. i need to go back out and do an auto tune session.
my report of a possible bug - the pitch control is backwards. Sure I immediately modified Ch2 Ele on my Taranis radio, and that fixed it, but this should not have been needed- nothing in Mission Planner indicates a reversed ch2, and in the radio calibration screen, moving sticks shows typical normal orientation for ch2. but flying, the pitch control is reversed. this is with the copter facing away from me so both myself and the copter have the same forward orientation.
Has anyone else seen this happen? it was not dependent on flight mode, it was just reversed across the board. all other channels were normal (A,T,R) and not reversed.
-
151
-
152
-
153
-
154
-
155
of 558 Next