AP_HAL::UARTDriver* _uartA, // console
        AP_HAL::UARTDriver* _uartB, // 1st GPS
        AP_HAL::UARTDriver* _uartC, // telem1
        AP_HAL::UARTDriver* _uartD, // telem2
        AP_HAL::UARTDriver* _uartE, // 2nd GPS

As near as I can tell from looking at the numbers, the primary advantage of the MR props over the SF props is the difference in the APC Suggested RPM Limits or Safety Limits for MR and SF props. 

The MR prop RPM limit is 105,000 RPM / dia. in Inches, the SF limit is 65,000 RPM / dia. in Inches. That gives the MR props some advantage in that they can be run with confidence at an RPM that is up to 40% higher than the SF props. And I say "with confidence" because the APC RPM limits appear to be conservative. They can be used up to their limits and even a little over without shedding blades. 

The SF prop will do better on less power at lower RPM and then, as the RPM increases, the MR prop will come into the zone where it is better. So this is like arguing that apples are better than oranges. 

The recommended RPM limits on the 10" and 12" APC SF props in the comparison testing summary charts posted above would 6,500 and 5,416 RPM. The MR 10" and 12" props would be good up to 10,500 and 8,750 by the maker's recommendations. 

When the SF props do appear to be holding their or with or even outperforming the MR props on thrust, it is when they are being used beyond their recommended limits. Not a good idea at all. 

The thrust from a prop comes with the RPM. And the input power required to attain a specific RPM will be fairly constant. Any motor that is fairly well matched to the prop as far as the Kv and battery voltage, and that can handle the input power without overheating, will give you about the same thrust with a given prop. So using one specific motor and trying to compare the performance 10" and 12" props and slow fly and non-slow props is going to have some combos that are not as well matched as others and some points in the RPM range where one cannot do as well as the other. 

And then how you fly the props will change things again. You can't really expect to take a motor and prop combo that works well for a lower energy type of flying (photo, FPV, etc.) and expect it to do as well in higher energy types of flying. 

Essential Parameters

GPS/Positioning related	Default	Current	Remark
GPSGLITCH_RADIUS	200	100	GPS refresh rate is 5hz. 1m deviation per 0.2 sec should be a reasonable range
GPSGLITCH_ACCEL	1000	1000 to 900?
GPSGLITCH_ENABLE	1	1
FS_GPS_ENABLE	1(land)	2(althold)
FENCE_ENABLED	0	0	NOT used currently
AHRS_EKF_USE	0	0	EKF is in beta stage still, do not try to use it

Comparing Floating Point Numbers, 2012 Edition

Comparing Floating Point Numbers, 2012 Edition

Pixhawk LED and sound AC3.2

EKF / InertialNav Failsafe

EKF / InertialNav Failsafe

ArduCopter 3.2 adds an EKF (Extended Kalman Filter – Pixhawk only) and Inertial Nav (Pixhawk and APM2) check to catch flyaways caused by bad position estimates.

When will it trigger?

Once the vehicle is armed with GPS lock, the EKF / InertialNav check runs 10 times per second and checks the health of the EKF (if using Pixhawk with AHRS_EKF_USE = 1) or the InertialNav system (APM2 or Pixhawk with AHRS_EKF_USE = 0).

• the EKF’s health is checked using it’s compass and velocity “variance”.  This “variance” increases as the estimates become untrustworthy.  0 = very trustworthy, >1.0 = very untrustworthy.  If both variances climb above the EKF_CHECK_THRESH parameter (default is 0.6) the EKF/Inav failsafe triggers.
• the Inertial Nav’s (i.e. 3rd order complementary filter) health is checked using it’s horizontal acceleration corrections.  These corrections grow large (above 1m/s/s) when the filter is having trouble reconciling the GPS and accelerometer data so when they grow above the EKF_CHECK_THRESH the failsafe is triggered.

related commits:

Copter : Distinguish between EKF and INAV errors

Copter: prevent false triggering of ekf_check

Copter: clarify EKF check msg to GCS

Color Detection & Object Tracking [reference]

Color Detection & Object Tracking

Mat imgThresholded;

inRange(imgHSV, Scalar(iLowH, iLowS, iLowV), Scalar(iHighH, iHighS, iHighV), imgThresholded); //Threshold the image

The function checks the range as follows:

• For every element of a single-channel input array:
  
• For two-channel arrays:
  
• and so forth.

That is, dst (I) is set to 255 (all 1 -bits) if src (I) is within the specified 1D, 2D, 3D, ... box and 0 otherwise.

//morphological opening (remove small objects from the foreground)
erode(imgThresholded, imgThresholded, getStructuringElement(MORPH_ELLIPSE, Size(5, 5)) );
dilate( imgThresholded, imgThresholded, getStructuringElement(MORPH_ELLIPSE, Size(5, 5)) ); 

//morphological closing (fill small holes in the foreground)
dilate( imgThresholded, imgThresholded, getStructuringElement(MORPH_ELLIPSE, Size(5, 5)) ); 
erode(imgThresholded, imgThresholded, getStructuringElement(MORPH_ELLIPSE, Size(5, 5)) );

MinAreaRect angles

MinAreaRect angles - Unsure about the angle returned

I'm going to assume you're using C++, but the answer should be the same if you're using C or Python.

The function minAreaRect seems to give angles ranging from -90 to 0 degrees, not including zero, so an interval of [-90, 0).

The function gives -90 degrees if the rectangle it outputs isn't rotated, i.e. the rectangle has two sides exactly horizontal and two sides exactly vertical. As the rectangle rotates clockwise, the angle increases (goes towards zero). When zero is reached, the angle given by the function ticks back over to -90 degrees again.

So if you have a long rectangle from minAreaRect, and it's lying down flat, minAreaRect will call the angle -90 degrees. If you rotate the image until the rectangle given by minAreaRect is perfectly upright, then the angle will say -90 degrees again.

I didn't actually know any of this (I procrastinated from my OpenCV project to find out how it works :/). Anyway, here's an OpenCV program that demonstrates minAreaRect if I haven't explained it clear enough already:

Tesseract - change language file location

http://stackoverflow.com/questions/6950977/tesseract-change-language-file-location

Yes, you can, by setting the TESSDATA_PREFIX environment variable

tesseract-ocr parameters in 3.02 version

„Tesseract is extremely flexible, if you know how to control it. There is a large number of control parameters to modify its behaviour. While these change from time to time, most of them are fairly stable.“ (Tesseract ControlParams wiki)

If you want to get all list of parameters (variables) with its description and default values, you have to search tesseract code. Or continue reading… ;-)

There are two way how to set parameter:

• config file
• Tesseract-OCR API

Contours : Getting Started

Task Parallel Library: 1 of n

Fine tune of new frame - YAWING issue

Parameter:

new V type :

• during yaw, front motor gain 0.5, rear gain 0.68. This is supposed to cancelled any rolling moment in steady yawing (but not during acceleration)
• pitch gain (1.0) is higher than roll gain (0.71), compensating shorter longitudinal length, compared to span.

result:

yaw rate is limited drastically, but it is still reasonably fast

• roll/pitch:
• yaw:

test RC_FEEL_RP:

• 100
• 90
• 80 feels much smoother
• 50

test ATC_ACCEL_Y_MAX:

test ATC_RATE_FF_ENABLE

Performance Measurement and Improvement Techniques

Measuring Performance with OpenCV

Default Optimization in OpenCV

Many of the OpenCV functions are optimized using SSE2, AVX etc. It contains unoptimized code also. So if our system support these features, we should exploit them (almost all modern day processors support them). It is enabled by default while compiling. So OpenCV runs the optimized code if it is enabled, else it runs the unoptimized code. You can use cv2.useOptimized() to check if it is enabled/disabled and cv2.setUseOptimized() to enable/disable it. Let’s see a simple example.

# check if optimization is enabled
In [5]: cv2.useOptimized()
Out[5]: True

In [6]: %timeit res = cv2.medianBlur(img,49)
10 loops, best of 3: 34.9 ms per loop

# Disable it
In [7]: cv2.setUseOptimized(False)

In [8]: cv2.useOptimized()
Out[8]: False

In [9]: %timeit res = cv2.medianBlur(img,49)
10 loops, best of 3: 64.1 ms per loop

See, optimized median filtering is ~2x faster than unoptimized version. If you check its source, you can see median filtering is SIMD optimized. So you can use this to enable optimization at the top of your code (remember it is enabled by default).

• Stabilize Roll/Pitch P controls the responsiveness of the copter’s roll and pitch to pilot input and errors between the desired and actual roll and pitch angles.  The default of 4.5 will command a 4.5deg/sec rotation rate for each 1 degree of error in the angle.
  • The higher the P the faster the copter will be asked to turn to get to the desired angle.
  • A high P will cause the copter to oscillate back and forth like a seesaw a few times a second.
  • A low P will cause the copter to move very slowly. A very low P will cause the copter to feel unresponsive and could cause a crash if the wind disturbs it.
• Rate Roll/Pitch P, I and D terms control the output to the motors based on the desired rotation rate from the upper Stabilize (i.e. angular) controller.  These terms are generally related to the power-to-weight ratio of the copter with more powerful copters requiring lower rate PID values.  For example a copter that accelerates very quickly might have Rate Roll/Pitch P number of 0.08 while a more sluggish copter might use 0.18.
  • Rate Roll/Pitch P is the single most important value to tune correctly for your copter.
  • The higher the P the higher the motor response to achieve the desired turn rate.
  • Default is P = 0.15 for standard Arducopter.
  • Rate Roll/Pitch I is used to compensate for outside forces that would make your copter not maintain the desired rate for a longer period of time
  • A high I term will ramp quickly to hold the desired rate, and will ramp down quickly to avoid overshoot.
  • Rate Roll/Pitch D is used to dampen the response of the copter to accelerations toward the desired set point.
  • A high D can cause very unusual vibrations and a “memory” effect where the controls feel like they are slow or unresponsive.
  • Values as low as 0.001 and as high as .02 have all been used depending upon the vehicle