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
Thanks Randy,
I've seen this page, but I'll take closer look at it once more.
Hi Guys ,
this is the video of our first optical flow test with VR Brain 5.2 lidar and APM 3.3rc8 ... there are some bugs in pre arm check so we disable for start the test .. so actually is a good option only for dev and beta tester .
https://www.youtube.com/watch?t=112&v=HbAxfs5TUC0
best
Roberto
yeah, the optical flow on that copter is looking great actually!
Yes Randy but is not already available for end user ... the pre flight check need patch and some times in initialization stage there are some iusse and then then the drone drift and don't mantain the position so well as when it work fine so we are near to have a good option , but need a bit of work to do for finish the implementation could be great if in 3.3 official will be finish or is too near the next release ?
best
Roberto
After weeks of unsuccessful attempts using this $52 version of PX4FLOW optical flow sensor (http://www.goodluckbuy.com/px4flow-v1-3-1-optical-flow-smart-camera...), finally I was able to run it with RC8. The problem is there is no indication for the scaling factor of FLOW_FXSCALER and FLOW_FYSCALER in the wiki page. The latest MP has a description range of -200 ~ +200 and I was able to guess 200 means 20%. So the suggested range is -20% ~ +20. This version of PX4FLOW requires a scaling factor of 350%
EKF_FLOW_GATE,5
EKF_FLOW_NOISE,0.15
EKF_GPS_TYPE,3
FLOW_ENABLE,1
FLOW_FXSCALER, 3500
FLOW_FYSCALER, 3500
LOG_BITMASK,131071
The performance is quite good. Under windy condition the drift is below 0.5m with altitude of 1.5m. I found two cases that optical flow can’t seem to hold position:
- Limitation on height: As soon as I raise the altitude around 6m the quadcopter started to drift away. This problem is reproducible every time. The sonar I used is MB1242 I2CXL-MaxSonar-EZ4.
- Fly mode switching: It worked pretty well from Stabilized ->Altitude hold (a few seconds)-> LOITER. However after flying with altitude hold mode for a while (30 seconds+) then switching to LOITER the quadcopter will drift to one direction. The only way to get it to work again is to land and Disarm->ARM. (GYRO drift?)
I have two questions:
Thanks to the development team for doing such an excellent job.
*Note: I don’t recommend using this version of PX4FLOW sensor with GPS. I could never get a GPS lock when the optical flow sensor is powered. The EMI interference is unacceptable.
I guess there is limitation on PX4FLOW focus. Did you set up sensor focus as it is said in Wiki? I got mine adjusted to 3m distance, and it was NOT set up correctly out of the box (as it is also said in wiki).
I am currently using:
PX4 + IO(stack) + 3DR FLOW (i2c) + MKBL ESC(PWM)
IRIS X quad.
The thing is that on 3.2.1 firmware my PX4 failed to see PPM receiver. I moved on to 3.3 rc8, surprisingly it worked very well (I haven't autotuned copter yet, because build is in progress).
Flashed FLOW module with recommended on wiki 2014 firmware and adjusted focus.
Funny thing: I was trying to tune flow_Scale indoors and I had not enough limits as in case above, but when I got outside in good lighting conditions limits ended up 0%.
Concerning sonar, there are recommendations to use Lidar height meter because of dire unreliabilities of sonar. I haven't tested posHold and sonar alt hold yet, but these actions are very close on my work list, so we can compare results.
Hi, Marco:
Interestingly enough after reading your observation regarding the Flow_Scale I tried it outside and guess what I am using 3150 instead of 3500. However I can’t be sure if this has anything to do with doing a 6M refocusing. I did follow the instruction and did a 3M focus adjustment on the PX4FLOW sensor before using it.
It appears that there is no change of the optical flow LOITER drifting issue reported before after refocusing at 6M. This time I found even at 4M ~ 5M range it still happened just slower. So I have to assume that the optical flow operation range is below 4M. This is quite sad that the flyaway issue cannot be prevented using this optical flow sensor or can it?
The new beta Mission Planner did issue a warning when you entered the FLOW_FXSCALER and FLOW_FYSCALER beyond the -200 ~ +200 range. However it did accept the value which is good for the sensor I am using now. I wish the next release RC9 can solve the mode switching issue so user can enter the optical flow LOITER from other modes.
Randy- I agree, OF has been working very well. Check out my blog post about my experiences with it.There are still some bugs to get through, but it has been pretty exceptional so far!
I bought a PX4 optical low/sonar module more than a year ago and could not get it operational then. If it is at all strait forward I would love to make another go at it! just need to sort out some vibration issues first.
The video show the quad holding position and altitude very well, great job!
Wes- I have been using the OF sensor for a few days now! Check out my blog post, I can answer any questions you have. http://diydrones.com/profiles/blogs/iris-optical-flow-lidar-lite-lo...
-
282
-
283
-
284
-
285
-
286
of 558 Next