Jack Crossfire's blog View Details
Archive for February, 2013 - Page 2
Posted by Jack Crossfire | Feb 05, 2013 @ 08:47 PM | 4,600 Views
So a BMP085 arrived. It was an improved barometer that came after the mighty SCP1000, but the current state of the art is the MS5611. The MS5611 is the one giving the bouncy, ground effect altitude hold on the latest ardupilot videos.

It's still not fast enough to compete with ground based vision or sonar, but closer. The problem is any barometer is only useful in an outdoor vehicle, which resurrected the idea of flying outside again.

Flying outside is super expensive, $100/hour in broken parts. The last outside flight was in 2011. There was a plan to abandon the tri copter & convert it to an H quad. The H quad was the 1st vehicle I envisioned in 1988, but only now is it becoming popular with RC fliers.

As in the military industrial complex, evolution is slow in the RC hobby. In both industries, it's extremely expensive relative to the participant incomes to try new ideas. Simple changes take years to popularize. After years of Y frame tri copters, the T frame tri copter finally started catching on & the H quad once again seemed less desirable.

The T frame is always going to be cheaper & lighter than an H quad, using 1 less motor & requiring fewer propeller replacements. Any return to outdoor flight would begin with purely manual flying with a camera. The accuracy & reliability of consumer GPS, barometer, & IMU still isn't good enough to make it a more pleasant experience than manual flying.

The old remote control,...Continue Reading
Posted by Jack Crossfire | Feb 05, 2013 @ 01:37 AM | 4,965 Views
Wireless cameras are 1 area where the conversion to digital requires much bigger electronics. Long range FPV is still entirely analog. The only way to realistically get video from an indoor copter is an old fashioned analog NTSC camera, but synchronizing a camera to a monocopter, when you don't have access to a frame buffer or clock, remanes hard.

You can't synchronize the raw stream on the ground, because there are no longer ways to capture a raw frame buffer & modern MPEG encoders delay the stream.

The most likely solution is to have a LM1881 scanning for the vertical blanking interval in the composite signal. Then a dedicated microcontroller pulls the signal up or down to overlay a code on the right frame.

Software video overlay was done here: http://www.webx.dk/rc/video-wireless/video-osd.htm
Posted by Jack Crossfire | Feb 02, 2013 @ 09:27 PM | 4,893 Views
Ladybird autopilot (7 min 0 sec)

The 1st flights good enough to get on video. It's extremely unstable, but there is hope. The MPU9150 was the only way to get the sensors small enough. It might also be the smallest thing currently flown by a computer, anywhere in the world.

There was some chance noisy stick voltages were making it unstable, but the oscilloscope showed the noise was down near 20mV while flying deflection was near 500mV in the pitch & 100mV in the roll. The Y position has more error because the camera can't sense depth.
Posted by Jack Crossfire | Feb 02, 2013 @ 01:37 AM | 5,371 Views
After a flimsy hot gluing of the board in place, the MPU9150 took its 1st 2 batteries of flying. Results were drastically improved over having the board under the battery. There's still a bit of error because the board isn't perfectly flat, but it manages to recover. The current or the flexing of having it under the battery was the problem.

There was 1 source file for the MPU9150 on http://permalink.gmane.org/gmane.linux.kernel.iio/4339, revealing undocumented register REG_YGOFFS_TC. He never uploaded the header files.

With the full Marcy 3 software & the crystal, the MPU9150 only reads at 80Hz.
Posted by Jack Crossfire | Feb 01, 2013 @ 03:19 AM | 4,954 Views
With the MPU9150 now on the Marcy3 board, it's slightly bigger than the Ladybird board. Mounting it somewhere which doesn't flex is the next great task.

The dual I2C busses & new capacitors accounted for that. A wishful crystal to get the PIC as fast as possible added some more size. If the PIC does nothing else, it can get 140 readings of all 9 sensors per second. Without the crystal, it can get 80 hz. 50Hz is probably enough for the application.

Being the low end PIC that it is, only software I2C was justified. If it was concerned with the full attitude stabilization, it would need hardware I2C for the gyro/accel part. The trend is now to use STM32F ARMs for even these nano quads.