Jack Crossfire's blog - Page 51 - RC Groups
Jack Crossfire's blog View Details
Posted by Jack Crossfire | Dec 07, 2012 @ 05:46 AM | 5,405 Views
It doesn't work on the stock image, but there is an easy solution.


Go to http://esrlabs.com/android-transport...-raspberry-pi/ in which a buried link currently goes to
http://esrlabs.com/downloads/esrlabs...2012-10-02.zip
a magic image with versions of the networking tools which work with the rtl8192.

The serial port login is pi & passwd is raspberry.

Once that's flashed & booted, disable all the android crap & CPU hogs.

vi /etc/init.d/mdnsd
vi /etc/init.d/atc

They use dnsmasq for DHCP. Edit /etc/dnsmasq.conf to fix the IP address range.

Their networking is configured in /etc/init.d/ap. Change it to a useful IP address & bring up eth0 here.

Change hostapd to a useful ssid & encryption.

vi /etc/hostapd/hostapd.conf



This image doesn't have a useful kernel. To get runtime CPU frequency scaling & the full 512MB of RAM, you need to overwrite the /boot directory with the /boot directory from the latest image.

Mount the latest image on your desktop.

parted <image file>
unit
b
print
quit

mount -o offset=<offset in bytes of 1st partition> <image file> /mnt
scp -a /mnt/boot/* pi:/boot

The following directories aren't needed: /usr/share/doc /usr/share/icons /usr/share/scratch

Better yet, make all these changes in the ESR image.


That gives a screaming 900Mhz ARM with 512MB of RAM & full iPad compatible access point so you can make your aircraft talk to apps.

In other news, the stock image met its goal of a standalone autopilot which can be powered on anywhere with batteries suitable for the pi's 1.5A 12V requirement & flown at the press of a button.

Raspberry Pi flies Blade MCX (2 min 33 sec)



It's fortuitous that someone invested the time to make an rtl8192 access point work on the raspberry pi, but there was so much demand for such a feature, the odds were good that someone would do it. It's too bad the changes didn't make it into the main branch.
Posted by Jack Crossfire | Dec 06, 2012 @ 05:47 AM | 4,469 Views
The object of the game was to make a box that could be set up anywhere & fly the vehicle with 1 button press & no GUI. That's mostly possible, except for the 1 issue of calibrating the compass. A user interface of some kind was necessary, but could also be done with aural cues.

Playing uncompressed sound files on a pi with 2 webcams is done thus:

amixer -D hw:2 sset 'PCM' 65535
aplay -D hw:2 test.wav

The webcams take up the 1st 2 devices.

Next, you need to restore the last of a pair of 28 year old, amplified speakers, in which the other one stopped working, but you threw out the electronics not knowing it merely required an easily obtained LA4461 audio chip.

As a standalone box, it takes 80% of the CPU during flight. The maximum stable frequency remanes 900Mhz. Active cooling made no difference at 1Ghz & isn't necessary at 900Mhz. What does need active cooling is the voltage regulator. The total power with the cooling fan, servos, cameras, & CPU is 1.5A at 12V. It still takes quite a bit of power to do machine vision.

With a network GUI enabled, it goes to 90% of the CPU. A system with at least a tablet interface is a lot more useful. Unfortunately, while an access point based on the rtl8192cu was possible in Linux 3.2.9 for Ubunt, it no longer is in 3.2.27 for the pi.

It now can't change the interface to master mode. A different dongle may be required, simply because the software no longer works.

Some things that got it farther along:


modprobe hostap
modprobe cfg80211
Posted by Jack Crossfire | Dec 05, 2012 @ 07:07 AM | 4,413 Views
After some major rework & a new round of bugs, the pi flies it.

So far, the pi only goes to 900Mhz with active cooling, before it starts crashing. Forget about mounting a heatsink on it. It's a double stacker.

At 1Ghz, reducing the video resolution to 320x240, the complete flight load fits neatly before it crashes. At 900Mhz, it uses 95%. It consumes 1A with the full software, servos, & cameras going. Below 900Mhz, the framerate drops & the flight becomes subjectively less stable. It actually crashed a few times at 700Mhz without active cooling.


Using an LM317 to provide the 5V 1A has proven the most reliable.

Certain uses of memcpy to shift a buffer by 1 byte don't work on the pi. You need for loops.

The mane task was completely removing the flight software from the GUI & making the entire user interface connect through the network. It still has a long way to go, before becoming a self contained flying box.

Amazing for all its hardware multimedia for set top boxes, it can barely do machine vision. According to the goog, this is the 1st time anyone has ever done anything that couldn't be done without overclocking it.
Posted by Jack Crossfire | Dec 04, 2012 @ 01:26 AM | 3,862 Views
Its vision processing future looks bleak. With no preview video, it does a single 640x480 camera at 28fps. With preview video, it does 24fps. That's with it at 1Ghz, consuming 0.6A. Usage is evenly divided between JPEG decompression & blob detection.

The easiest solution is less resolution or downsampling to 640x240. 640x240 barely goes at 30fps with preview. 320x240 would be the maximum for stereo.

To get the CPU frequency in khz:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

To list the available governors:


cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

For comparing CPU usage of the different modes, fix it at the highest speed:

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 900000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed

It does occasionally crash. It could be a flaky molex connector for power or the LM317 overheating. The servos aren't even being used, yet.
Posted by Jack Crossfire | Dec 02, 2012 @ 11:15 PM | 4,348 Views
Keeping the camera mount in its laser painter form wasn't an option, because there wasn't enough room to store every gadget. Now, the tripod blind nut & more of the wood had to go. 3 circuit boards have to go on it.

There were a number of options. Wifi ended up having too many dropouts to be used in any feedback loop, but would have to be used when communicating with a tablet.

So all the intense vision processing had to be done on the camera mount, wired to the cameras. The camera mount required an access point to communicate with a tablet for the user interface.

In the old days, this would have required an FPGA or DSP with custom software. Nowadays, a 1Ghz linux board computer can do it very cheaply. The computational requirement meant the STM32F407 was completely out of this project. A common webcam + board computer was the cheapest method.

Once the SD card is flashed & the right pins are soldered to 5V, GND, & UART, the raspberry pi runs exactly like any other board computer you know & love. It has a single serial console, network interface, & USB. USB is your only realistic path to the hardware world.


Steps to bringing it up:
log in as

user: pi
passwd: raspberry

enable root login:
sudo passwd root

step up to 1Ghz & reduce video RAM:
raspi-config

/boot/config.txt contains the settings

enable static ethernet:

vi /etc/network/interfaces

change

iface eth0 inet dhcp

to

iface eth0 inet static
address 10.0.0.11
netmask 255.255.255.0
gateway 10.0.0.9

disable swap file:
vi /etc/init.d/dphys-swapfile

fix slow ssh login:
vi /etc/hosts


Maximum CPU speed:

echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed



Download cross compiler from:

https://github.com/raspberrypi/tools

So far, it needs 0.5A when idle. That requires a modern USB charger wall wart, a PC power supply, or a really big, heavy, bench supply.
Posted by Jack Crossfire | Dec 02, 2012 @ 03:53 AM | 3,985 Views
Good Blade MCX autopilot (2 min 43 sec)


Another aircraft converted to autopilot was dead accurate, vindicating the machine vision & autopilot system in flying a super microscopic indoor copter. The previous Blade MCX had a natural oscillation when flown manually, which the autopilot couldn't cope with.


It turned out the problem in internet lingo was "toilet bowl effect" & the solution was soaking the flybar assembly in 3 in 1 oil. So now there are 2 autopilot capable Blade MCX's in the apartment.


Comparing a stock Blade MCX with an autonomous one, the full autopilot with hot glue is only 3.7 grams.

A ladybird with simulated payload but no power usage flew for 5 minutes.

A stock Blade MCX with no autopilot flew for 11 minutes. Those 3.7 grams + 180mA of current take away a lot. The blade was freakishly stable. It drew the battery to 3.4V unloaded.

The blade with autopilot drew the battery to 3.9V before losing yaw control....Continue Reading
Posted by Jack Crossfire | Dec 01, 2012 @ 03:53 AM | 3,859 Views
The oscillation is a real problem. Attempts to overcome it began with cyclic phase adjustment. That was the most successful, but just created a standing wave of its own & might have been just compensating for a calibration error.

There was delaying the velocity readout by slightly less than a period of the oscillation, which amplified it. It looked good on paper, but the delayed output became the new velocity readout, making its own standing wave.

If there was a way to exactly align the heading readout, it might work, but the heading readout is never going to be stable. It shouldn't be that much of a problem if the position feedback is doing its job.

Next comes the age old trick of using cyclic to predict future velocity. You have the instantaneous cyclic from the P & D feedback & know anything nonzero is going to make velocity grow.
Posted by Jack Crossfire | Nov 30, 2012 @ 02:39 AM | 5,237 Views
Blade MCX autopilot (2 min 0 sec)


After all that work, the Blade MCX was stable enough for a video. The limit in accuracy of a pan/tilt camera has probably been reached. The next step is to refill the tires, get soaked in the rain, & take it all to a larger room, to fly waypoints.

Pan/tilt vision tracking has been in use for 18 months. Its weaknesses are now known. It was a good way to fly a very stable monocopter, but hasn't been great with more unstable copters.

Except for monocopters, a common theme has been vehicles which are extremely stable being hard for the machine to fly. Though normally passively stable, they have occasional slips which the quick responsiveness of a human can dampen but a machine tuned to very minor feedback can't.
Posted by Jack Crossfire | Nov 28, 2012 @ 09:53 PM | 5,425 Views
Finally got it to where it could drain an entire battery in a hover. It only lasts around 2 minutes. The IR leds consume enough power to make the voltage regulator hot.


The Edmond Optics IR filter ended up necessary. The higher shutter speed it requires got the framerate up to 30. The floppy disk required a shutter speed that was too slow to get 30fps. Some more software optimization got the position sensing good enough to do it.

It was entirely a matter of improving the position sensing speed. A pan/tilt camera using PWM to estimate the pan/tilt angles for every frame is going to max out in a 2m hover radius. It basically needs all the empty space in the room to hover.
Posted by Jack Crossfire | Nov 28, 2012 @ 02:54 AM | 5,273 Views
So the servocity mount was voted off the island. With all the requirements for sensing its position, it was too slow. After PWM recalibration & a voltage experiment, the home made mount came back.

Another attempt to slow it down by running it on 3.3V made the motors stall. Tower hobbies said it ran on 3.3V. It must have been rediscovered many times but lost to memory that 3.3V makes it stall.

Then, the task of aircraft tuning resumed. There is a lot of noise in the position sensing, but given enough balancing, it can fly itself for a short time. Without a very good position readout, the feedback needs to be bare minimum & the balancing needs to be exact. The IR cameras only do 20fps while the visible cameras did 34fps, making for a much slower position reading.

The Syma X1 was more forgiving of balancing, but the Blade MCX is the vehicle of choice for micro UAVs because it is the smallest with full cyclic yet has the highest payload for its size.


Ended up putting a follower amplifier on the digital to analog converter, to eliminate any chance of the rc transmitter failing to receive the right voltage. That turned out to not be the problem.
Posted by Jack Crossfire | Nov 26, 2012 @ 10:24 PM | 4,914 Views
This thing arrived. It's big, heavy, linear & expensive. $180 for 2 variable outputs & a 5V fixed output. It doesn't give the settings without being on. To test a new circuit, you could short the outputs to calibrate the maximum current. In reality, you'll turn the current to maximum, turn the voltage to minimum, & slowly ramp up the voltage.
Posted by Jack Crossfire | Nov 26, 2012 @ 02:56 AM | 4,971 Views
The $350 camera mount lives, for now. With PWM as the only position estimation, the servo movement has to be extremely slow or it oscillates, but it's already built up. The cheap mount had servo wobble which equaled the position inaccuracy of the expensive mount, but speed may still bust the $350 camera mount.

Now comes intensive balancing. A slight PWM adjustment & the Blade MCX lifted off with the electronics. It barely has enough power to do it before maxing out the motors & going into a left yaw.
Posted by Jack Crossfire | Nov 25, 2012 @ 03:06 AM | 5,282 Views
It looks like the PT785-S Pan & Tilt System is getting voted off the island. It's perfect for smooth motion of a manually controlled camera to rough positions, but the application here is automated motion control to precisely reproducible positions, which it can't do.

It returns to a very rough position & can't return to the same position if manually pushed out of position or restarted. Using either an IMU or the raw pot voltages to detect the position was worse than just using the PWM values, so the position readout eventually used the PWM values & accepted any discrepancies in the translated position.

The only advantage it had was very smooth motion, but the pointing errors were bigger than any jerkiness in the motion of a servo. Developing a precisely reproducible motion control platform is a full time job for a 6 month timescale & all this investment in squeezing the last bit of accuracy out of robotics probably isn't worth as much as making a good tablet interface.
Posted by Jack Crossfire | Nov 24, 2012 @ 11:48 PM | 5,171 Views
The quest for powering the 580EX II revealed only 1 of its 4 lithium cells actually died. Testing the voltage of all of them instead of just 1 revealed 1 cell had 1.3V while the others had 1.4V. But the new trick was measuring current. The 1.3V cell had 0 current. Didn't measure the 1.4V cells. Not sure how much a fully charged lithium cell would generate.


The 580EX II was powered by a single set of NiMH's ever since it arrived in April 2008. It very quickly showed it wouldn't work with anything but brand new batteries, yet new & old batteries showed the same voltage. The same 4 NiMH's made the only photographs of M.M. in 2010 & suddenly stopped working with the flash in Sep 2012.


The Fluke 87V finally revealed why. Their ability to provide current decreases with age. Fully shorting a new NiMH gives 7A while a 4 year old NiMH only gives 1A. The flash needs 7A while a mouse can get by on only 1A. Don't try this with a Lipo. There are ways of doing it with a resistor.
Posted by Jack Crossfire | Nov 24, 2012 @ 04:40 AM | 4,806 Views
That was amusing. The $30 filter either has a wider pass band or less attenuation than the floppy disk. You can layer the filter or just whack a single floppy disk layer on. The camera lenses have a finite number of filter swaps before their focus has to be redone.

The guy mentioned the floppy disk was merely attenuating the entire spectrum instead of selecting for IR, while the $30 filter was selecting for IR. If that was true, a bright white LED would show through the floppy disk, but it doesn't. Only a red LED shows.

Also, looking through the floppy & the $30 filter with the naked eye shows the same pass band, with slightly more light passed through the $30 filter.
Posted by Jack Crossfire | Nov 22, 2012 @ 05:05 AM | 4,942 Views
An el cheapo $30 5x7" sheet of IR filter arrived from edmondoptics.com. With the naked eye, the view looks exactly the same as through a floppy disk. The problem is of all the DIY IR filters on the internets, none is made of something still in production. Floppy disks & film are no longer made.

It breaks apart like glass & hot glues on the lens easily. It seems to be common charcoal baked into acryllic plastic.

Next, the next camera mount was fully assembled & powered up with PWM. Be sure to keep the cables clear of the gears. The gears chew them up, instantly. If you accidentally turn it more than 180' & shift the center point of the pots, turn it the opposite way more than 360' until the pots are reset.

Also, discovered PWM above a certain point causes the servos to spin forever.

Another hack to use direct pot readings has given much better accuracy than an IMU. Other than motor magnets, it's hard to understand why the IMU was so inaccurate & was so hard to calibrate. The iPAD IMU gives very accurate compass headings with very little calibration. It may just be inaccurate alignment of the accelerometer & magnetometer.

The amount of energy devoted just to building up yet another camera mount brings the sensation of going in circles. This is the 3rd unique camera mount built since Summer 2011.

They only exist because someone else is paying for them, there needs to be 1 here for testing while he brings another on travels....Continue Reading
Posted by Jack Crossfire | Nov 21, 2012 @ 04:39 AM | 4,657 Views
So after all its calibration, the IMU on the camera mount was not accurate enough to improve camera pointing. Magnetic heading was always slightly off & required very precise calibration. It may have been magnetism from the servos. That led back to hacking into the servo pots.



The only way inside the winch servos was to desolder the motors. That revealed the pot was indeed exposed on the outside, but undetected due to a probing error. Those $50 winch servos have some beefy MOSFETs & a big motor. $50 buys a lot more than $10.

While staring at this $50 servo's crumbling lead free soldering with no conformal coating, it should be noted that it's no good for a mission critical aerospace application. The soldering is going to have tin whiskers.

The servos only use 1V of the full range of the pots. They leave a 1V buffer on each end. This seems to be because of the strange behavior of the pots. They don't have upper & lower stop points.

With no PWM, they can be manually spun beyond the maximum revolutions, using some kind of slip ring, then wherever they reverse direction becomes the new boundary. The servos have the 1V buffer to avoid changing their center points.

Of course, this means the center point changes depending on how the camera mount is rotated when it's off. The easiest solution is to put mechanical stoppers in the mount to stop it from rotating beyond the boundaries.
Posted by Jack Crossfire | Nov 20, 2012 @ 05:43 AM | 4,866 Views
The answer is no. The motor in this $50 servo can't be pulled out without damaging it. Maybe the motor terminals can be soldered to some wire to apply more force to it. Those right angle traces are things you don't see every day.

Using the servo pots to detect where they're pointed would be nearly as accurate as an IMU for determining camera angle.

The IMU for camera pointing is a buster to implement & configure, but it is the most accurate measuring device. It would eliminate all methods besides PWM if it didn't improve the accuracy.

The process of integrating the IMU & ground station on the camera mount is long & hard. Future soldering & development has to be done on the floor, with a portable iron & laptop. The quest for an ideal bench has never yielded anything. Eevblog seems to have the ideal bench for electronics, but not for a computer.
Posted by Jack Crossfire | Nov 19, 2012 @ 06:26 AM | 8,069 Views
Then there was the MPU9150. A day of banging on it revealed this: it's an MPU6050 & AKM8975 in the same package & connected by the same I2C wires. To actually see the AKM8975 on the I2C bus, page 28 of the product spec says enable pass-through mode, but doesn't name any registers. Page 30 of the register map says INT_PIN_CFG has a I2C_BYPASS_EN bit, which sounds right, but setting I2C_BYPASS_EN didn't work.

The ES_DA & ESCL pins ended up soldered to the MCU_SCL & MCU_SDA pins before the AKM8975 appeared. It didn't help either that every datasheet & every schematic had different labels for the pins. At least the MPU9150 demo board only required VDD, GND, SCL, & SDA.

Next, the AKM8975 read out perfectly, but the accelerometer showed only 0. Enabling the highpass filter did nothing. Together with the lack of a functioning I2C_BYPASS_EN bit or any interrupt enable bits, it appeared the accelerometer wasn't turned on.

There was also some research in the DMP firmware. It apparently was a science project to get it to work. It required many calibration constants written by many I2C writes, uploading firmware over I2C, a highly restrictive license. The Invensense ARM board used to demo it required a Windows program with proprietary USB protocol, nothing that would run on a rasberry pi in the field. It was hardly the cut & dried interface found in a speech synthesizer chip.

Since the project is only a 1 off demo to be discarded, the MPU9150...Continue Reading
Posted by Jack Crossfire | Nov 18, 2012 @ 06:07 PM | 4,686 Views
So the 18f14k50 in use since 2009 had yet another silicon error where PORTA 0:1 couldn't be read unless the IOCA bits were set. Also, the pullups on 0:1 don't work. This is why microcontrollers get standardized on for years, until they're either discontinued or become useless for the application. There are always a myriad of errors to be discovered.


Next, discovered the Rigol samples at 500megsamples/sec in long memory mode, but 1gigsamples/sec in short memory mode. Nothing has required that fidelity & the probes probably can't do it either, but now you know.


Finally, the quest to power the Canon 580EXII never ends. Lithium batteries only lasted 2 months. There seems to be no reliable solution besides AC power.


The servocity pan/tilt module is so slow, it requires an IMU to know where the camera is pointed in each frame. The mighty MPU-9150 is set to do this. There are horror stories about the licensing of its firmware where Invensense charges an outrageous fee to sell a product which actually uses their product.


At least a supply of AKM8975's was located, providing a stop gap solution to the magnetometer issue. The limits of weight, size, update rate, & power supplies make finding the right magnetometer very involved. The AKM8975 is the only one which has fit in the requirements of a microscopic vehicle.