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
Yes, of course I have done it.
But thank you for suggestion ;)
A suggestion like this is always welecome since most errors are made by simpy forgetting something.
I have found that with AC3.3 rc8 it does arm.
The main problem is that when I'm on the ground if I touch/move too much my esacopter it display "compass variance".
If I plug in the LiPo and carefully go away from the copter without touch anything I can arm it without any error.
Basically: now it is very very sensible if you rotate/move the copter after the power up, before arming (Or at least, I think. Soon I do some other test to confirm this).
I have already posted a similar somewere in this thread. We only have to find it =P
I just purchased this board a few min ago! I hope it works w/ 3.3!!
Does anyone else have one of the pixhawk lites?
on my official pixhawk, w/ 3.3rc7, if my GPS/Compass rotates a tiny bit on its mast, I get that error until I recalibrate the compass.
Is there any chance it's a similar mechanical issue in your case? Maybe the 'issue' was there w/ 3.2, but 3.3 is more sensitive to such things?
"on my official pixhawk, w/ 3.3rc7, if my GPS/Compass rotates a tiny bit on its mast, I get that error until I recalibrate the compass.
Is there any chance it's a similar mechanical issue in your case?"
No, it is not possibile. I had tried also with only internal compass.
With only internal compass I get the same issue.
The log attached is with only the internal compass.
"Maybe the 'issue' was there w/ 3.2, but 3.3 is more sensitive to such things?"
Dunno XD
About the PixHawk Lite/PX4Lite.
I have it but acualty I'm not using it for flying.
I do not trust at 100% this board.
Mine have 3 problems:
-It get hot when powered
-It have some problems with 3.3
-They send it to me with PPM encoder broken
I have some other boards.
With PixHawk by 3DR, VrBrain and HKPilot 32 it is all fine since rc7 (The first board where I tried the rc8 is the PixHawk Lite/PX4 Lite).
I think only more or less supported mini board is AUAV. on that one you got you will probably be on your own.
http://arsovtech.com/?page_id=1502
AUAV has its Chinese clones getting sold on ebay as well. Not sure if it is worth doing, better get it from the maker, even if takes time. Vertical pins model is more compact, it is one on the Tarot image above. You can see even in the case (from shapeways) it fits in between 45mm posts - case has 45mm mounts, where those posts go into, screwed in and superglued. An awesome board for its compactness, but, has some quirks too.
Mast is not helping at all and causes EKF issues when your compass wobbles.
Best way is to do proper EMI blockade is to sit GPS on top of a carbon plate that has a layer of copper foil glued to it. copper foil like same that is used for electric guitars. It works better for me than any mast mount.
Just make sure not to use any metal bolts/posts on the GPS unit you will use as a compass.
When I checked the Loiter PID's in MP the Loiter PID's are greyed out and not adjustable.
[URL=http://s1239.photobucket.com/user/86burbguy/media/Mobile%20Uploads/DBBF1154-7A31-42CE-998D-C13C8C6B12DD.png.html][IMG]http://i1239.photobucket.com/albums/ff502/86burbguy/Mobile%20Upload...[/IMG][/URL]
A little off topic as this has nothing to do with airworthiness. My mapping rigs running 3.3rc8 are doing funny things in the processing phase. Can't sync the geolocation info with the images using mission planner. All I get is "aboring" as seen in the image I attached. I can use Pix4d to syc the data up, but Pix4d thinks all the images are portrait mode instead of landscape. First thing I check the next flights was the camera facing forward was checked in survey grid, but Pix4d still thinks it's portrait orientation.
Portrait.JPG
GeoRef.JPG
Hello everyone,
@Shaun, this mistake is due to the inclusion of the variable "Timeus" to CAM messages and restructuring of the message CAM data. Note that the variable "Timeus" has been included in all messages, so the messages ATT and GPS are also affected. To fix this, simply adjust properly "offtsets" in the setup screen Geotag Mission Planner tool.
Your configuration is incorrect, with new releases, for ArduCopter, Mission Planner must be set like this:
I hope I've helped.
Regards from Spain,
Dario
I just performed a mapping flight and I'm having this exact same issue trying to geo-ref my images with 3.3-rc7.
Using AMSL Altitude True
Reading log for GPS Messages in order to get AMSL Altitude
Log file problem. Aborting....
I'm guessing it's because of the size of the log file with all the fast IMU logging enabled (80mb). Does anyone have a workaround? It's quite important to get these images geotagged!
Edit; I can see the CAM messages are in the log if I filter them out. Is there any way to export these into their own log or otherwise work with them?
Good to have these reports.
It's possible that it's because of the changes to the size of the time field. I've created an item here for the Mission Planner to investigate/fix this.
-
305
-
306
-
307
-
308
-
309
of 558 Next