This is the startup procedure for the video recorder
- Check that camera works OK using a laptop with guvcview
- Check all connections, see e.g. Image:FlightMockup-001.jpg
- Connect USB console cable to laptop and the Tobi Console port
- Establish connection between laptop and Tobi (assume /dev/ttyUSB0):
$ kermit -l /dev/ttyUSB0 kermit> set flow-control none kermit> set carrier-watch off kermit> set speed 115200 kermit> connect
- Switch on the recorder and wait for login prompt to appear on the console
- cd video
- Execute the wifioff.sh script to switch off WiFi and BT
- Execute the camon.sh script to override false USB power protection
- Start the capture.sh <cycles>script to start recording
- 1 cycle = 5 minutes
- Keep in mind the shortened recording time due to device I/O errors
- When capturing has started it is safe to disconnect TTY cable
- When rocket is recovered re-establish connection
- If script is still running (i.e. there is no prompt on TTY) it is safe to use CTRL+C
echo 0 > /sys/class/gpio/gpio164/value echo 0 > /sys/class/gpio/gpio16/value
echo 1 > /sys/bus/usb/devices/1-1/bConfigurationValue
To be updated
At last, received the Gumstix Overo Fire. IRL smaller than I expected even though I knew the size. Weight 6g confirmed.
The power connector on the Summit board is very non-standard, see PJ1-022-SMT. I say it is non standard because I couldn't find a single electronics supplier that has this particular size in their series. Do there really expect people to buy that god damn wall plug? I will just mount two wires directly on the board.
Finally created an alternate power connector for the summit board, see http://twitpic.com/oxe4d
Powered up the Gumstix following the instructions on the website. Ångstrom boots up all right. The first boot took a long time because it had to configure god knows how many GNOME games and other stupid things – it took several minutes. The second boot was much, much faster, less than a minute.
No power manager installed.
WiFi and BT seemed alive but of course there was no connection and I don't know how they are configured. I tried to scan for BT devices from my Mac and there was something. I didn't want to connect since I didn't know if it was the Gumstix or maybe something fishy from one of my neighbors. I'll have to find some docs about these. Btw. a quick scan on the website didn't really turn anything up. I hope this doesn't mean that the Gumstix is just another not very well documented thing.
e-CAM32_OMAP_GSTIX - Camera Solution for GumStix’s Overo Series:
With V4L2 drivers. Amazing!
e-con Systems expect to release a 5MPix camera module soon, see blog post. This blog post also suggests that capturing and encoding 720p @ 30fps is possible on the OMAP.
- Had a quick half-day session with my Gumstix Overo.
- Did not find any USB mini-A to mini-B cable in regular computer shop.
- Gumstix Overo is still alive and the boot messages scroll through the tty; however, I did not get any image on the DVI monitor! I tried two different monitors, there is simply no signal. I was wondering if I have damaged the DVI output or something else.
- I decided that I will but a Tobi expansion board, which has Ethernet interface, and also one of these new small breakout boards.
- Ordered a Gumstix Tobi and a Pinto-TH board. Also included a USB mini-A to mini-B cable and an wall plug into the package since I was missing them.
- Package from Gumstix has arrived. They put two USB mini-A to mini-B cables in the package :)
- Decided that we will try to get the Gumstix Overo ready for an amateur rocket flight on 2010.10.03
- Functional scope TBD but it is highly unlikely that we can have live video feed or anything like that.
- Decided that the scope of the rocket flight will be recording video
- Still pending whether we can get the gumstix up and running in time
- Set up the Gumstix Overo + Tobi on a workbench. Thsi will be a permanent setup for now.
- Some issues that need to be resolved ASAP
- Ethernet on Tobi does not work (could be due to old image on NAND)
- Boots from flash but then loads OS from NAND!
Tried with newly flashed image on new µSD card. No luck but noticed an error message right at the beginning of boot:
Texas Instruments X-Loader 1.4.2 (Mar 27 2009 - 08:51:34) Reading boot sector Loading u-boot.bin from mmc U-Boot 2010.06 (Sep 09 2010 - 13:32:51) OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz Gumstix Overo board + LPDDR/NAND I2C: ready DRAM: 128 MiB NAND: 256 MiB In: serial Out: serial Err: serial Board revision: 0 Tranceiver detected on mmc2 Die ID #6b2400040000000004032d460c005010 Net: smc911x-0 Hit any key to stop autoboot: 0 Unknown command 'mmcinit' - try 'help' Booting from nand ... NAND read: device 0 offset 0x280000, size 0x400000 4194304 bytes read: OK ## Booting kernel from Legacy Image at 82000000 ... Image Name: Angstrom/2.6.29-rcfinal+r0+git90 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2723228 Bytes = 2.6 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ...
nand erase 240000 20000
I assumed this had to be done right after stopping the autoboot timer, and indeed it worked. After doing that it booted from µSD card!
Tobi network works fine using the new image.
- Prepared and tested two new microSD cards with desktop and console image from 2010.09.09.
- Console image does not start Tobi Ethernet
- Recorded boot video: TBD
- Had a few kernel panics:
- First while executing opkg update
- Second time while trying to run a Gstreamer pipeline
- After kernel panic neither graphics nor Ethernet worked.
- Disconnecting all power and cables brought back graphics and Ethernet; however, mouse and keyboard were no longer working!
- After this the functionality was random (monitor, keyboard, mouse). Maybe the contents on the SD card got bad during the crashes? Or maybe the image is just unstable?
- Other possibility is that the Overo Fire is running way too hot and things shut down. I have to measure the temperature.
Found out why I was getting the kernel panic and broken, graphics, Ethernet, keyboard and mouse, see photo. I really need to get some of those tiny screws.
- Trying http://www.gumstix.net/Setup-and-Programming/view/Overo-Setup-and-Programming/Installing-additional-sw-packages/111.html
- Errors during opkg update:
- pkg_parse_from_stream_nomalloc: Excessively long line at 1. Corrupt file? (many of these)
- pkg_parse_from_stream_nomalloc: Missing new line character at end of file! (many of these too)
- opkg_download: Failed to download http://www.gumstix.net/feeds/unstable/ipk/glibc/armv7a/debug/Packages.gz, wget returned 1.
- Errors during "opkg upgrade":
- update-alternatives: Error: cannot register alternative readprofile to /sbin/readprofile since it is already registered to /usr/sbin/readprofile
- Thanks to this I found how I can see which packages are available: http://www.gumstix.net/feeds/unstable/ipk/glibc/armv7a/
I think the upgrade broke system! After next reboot I had these messages at the end of boot screen:
Starting advanced power management daemon: No APM support in kernel (failed.) Starting ntpd: done Starting Samba: smbd nmbd. Starting syslogd/klogd: done * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon [ ok ] Starting Bluetooth subsystem: Initialization timed out. Starting Network connection manager daemon: NetworkManager. Starting PVR Usage: insmod filename [args] ADDRCONF(NETDEV_UP): wlan0: link is not ready net eth0: SMSC911x/921x identified at 0xd08c8000, IRQ: 336 WARNING: Could not open '/lib/modules/2.6.34/kernel/drivers/gpu/pvr/pvrsrvkm.ko': No such file or directory FATAL: Could not open '/lib/modules/2.6.34/kernel/drivers/gpu/pvr/omaplfb.ko': No such file or directory WARNING: Could not open '/lib/modules/2.6.34/kernel/drivers/gpu/pvr/pvrsrvkm.ko': No such file or directory FATAL: Could not open '/lib/modules/2.6.34/kernel/drivers/gpu/pvr/bufferclass_ti.ko': No such file or directory mknod: missing operand after `0' Try `mknod --help' for more information. chmod: cannot access `/dev/pvrsrvkm': No such file or directory cups: started scheduler. Starting GPE display manager: gpe-dm .-------. | | .-. | | |-----.-----.-----.| | .----..-----.-----. | | | __ | ---'| '--.| .-'| | | | | | | | |--- || --'| | | ' | | | | '---'---'--'--'--. |-----------' '-----'-'-'-' -' | '---' The Angstrom Distribution overo ttyS2 Angstrom 2010.7-test-20100824 overo ttyS2
Also note the version string! I should be Angstrom 2010.7-test-20100909 overo ttyS2
After making a new flash and initializing it I made the mistake selecting a different Enlightenment settings and now it take the desktop long time to come up after the onsole login appears :(
- Connected the Logitech QuickCam Pro 9000. Showed up as /dev/video0 and I could start cheese, but no luck capturing – Cheese said it has captured and LED on camera was ON for a while but image area was blank.
- Can get image up with Gstreamer pipeline.
- Using xvimagesink CPU load is below 50%
- jpegenc blows CPU up (not accelerated?)
- CPU is running a bit hot during capture but it is no more than 5-6 deg above what it was before.
- Since I had to create a new microSD, I decided to give the Gnome R11 image a try. → TBD Boots OK but neither bluetooth nor Tobi Ethernet works.
- Changed display resolution to 1280x1024 → TBD
- Been looking at these TI DMAI stuff... I doubt I can make video encoding work using this within the next two weeks (also need time for testing and mechanical work)
- Capture and save raw video
- Capture and save MJPG video
- Capture and save JPG images at lower rates
Capture and save raw video
This is very easy using a Gstreamer pipeline, e.g.
gst-launch -e v4l2src ! video/x-raw-yuv,format=\(fourcc\)YUY2,width=640,height=480,framerate=5/1 ! multifilesink location=img%05d.yuv
but it requires very high bandwidth. I have a Class 6 microSD, but what is the maximum rate we can achieve on the Gumstix Overo?
- 160x120: 38400 byte/frame
- 320x240: 153600 bytes/frame
- 640x480: 614400 bytes/frame
- 800x600: 960000 bytes/frame
- 1600x1200: 3840000 bytes/frame
- YV12 and YU12 (I420):
- 640x480: 460800 bytes/frame
- 1600x1200: 2880000 bytes/frame
- RGB3 and BGR3:
- 640x480: 921600 bytes/frame
- 1600x1200: 5760000 bytes/frame
→ Measure disk I/O throughput
Capture MJPG video
I don't know how to do it with Gstreamer. I tried the image/jpeg caps as in Pixel formats but can not play the resulting file in anything.
→ Can we find a working pipeline for capturing JP from camera?
Capturing using the guvcview CLI results in a file playable by VLC and mplayer. Unfortunately, the GUI can not be turned off!
→ Can we make guvcview work without having X11?
Capture and save JPG images
Using a Gstreamer pipeline with image/jpg and multifilesink generates unreadable files.
Uvccapture captures JPG from camera and saves to file. Unfortunately, it can not use dynamic filenames or capture with higher frame rate than 1 fps. The good news is that uvccapture is very simple and easy to modify.
JPG image sizes (Logitech QuickCam Vision Pro 9000):
- 320x240: 7297 bytes/frame
- 640x480: 18583 bytes/frame
- 800x456: 35504 bytes/frame
- 800x600: 25698 bytes/frame
- 960x720: 36242 bytes/frame
- 1280x720: 61092 bytes/frame
- 1600x904: 107942 bytes/frame
- 1600x1000: 109873 bytes/frame
- 1600x1200: 124891 bytes/frame
→ Try to modify uvccapture to capture JPG at higher resolutions and at higher frame rates
→ Try to build uvccapture on Gumstix Overo
- Forked uvccapture: http://github.com/csete/uvccapture
- Modified uvccapture to allow capturing JPG at high resolutions
- Modified uvccapture to support sequential file names (img001.jpg, img002.jpg, ...) and to allow specifying the number of images to capture.
- Tried to let uvccapture run in free-running mode, i.e. no delay, but the max framerate I can accomplish is around 15fps, while guvcview gets 30 fps without problems.
- Wanted to try luvcview as well, but it has some weird dependencies...
- Can capture MJPG using gstreamer, provided that I put the stream in a container:
- gst-launch v4l2src ! image/jpeg,... ! avimux ! filesink → works
- gst-launch v4l2src ! image/jpeg,... ! matroskamux ! filesink → can not play resulting file (could be bad jpeg data from camera)
- gst-launch v4l2src ! image/jpeg,... ! jpegdec ! xvimagesink → dies after a while (certain number of frames)
- Did some more testing with jpeg/avi and it seems to be a good option, provided that it will also work on the Gumstix Overo Fire. I have tried it on an old desktop and the MBP where it ran without any noticable CPU load.
- Tried to capture MJPG using the Gstreamer pipelines on the Gumstix Overo Fire. Got good video up to about 800x456 at 30 fps. Above this resolution video becomes bad. See test videos here: http://files.oz9aec.net/video/Gumstix/2010.09.20-mjpg/
- I had to remove keyboard and mouse from USB
- I was using the (presumably slow) 2 GB microSD so performance may be better with the Class 6 microSD I got last week. Did not have time to try this.
- The bad performance could also be due to USB bottleneck
- GST-DSP v0.8.0 has been announced!
- Prepared an 8 GB class 6 microSD card using 201009191347 image. Works okay but OpenGL demos don't run.
- Tried capturing MJPG using the Class 6 microSD card. Results were practically the same as with the slower microSD card, i.e. capture only possible up about 800x456 at 30 fps (or 640x480). See recorded test videos here: http://files.oz9aec.net/video/Gumstix/2010.09.21-mjpg/
- Tried to investigate whether bottleneck is at the USB end or the microSD interface:
- Camera+USB can sustain 1280x720 at 30 fps using a desktop PC ⇒ USB hub is OK
- Camera capturing 800x600 at 10 fps then upsampled to 30 fps using videorate is OK ⇒ microSD card can sustain the data rate
- Camera capturing 800x600 at 30 fps then downsampled to 10 fps is not OK ⇒ Bottleneck is at the USB interface!
- Note: The videorate element in Gstreamer can be used to convert between two different frame rates by either duplicating or deleting frames from the incoming stream.
- Discussed the situation with ERU, given that we can not get higher than 640x480 / 800x456. Options are to go on and use the Gumstix Overo Fire at this resolution or to switch to another off the shelf HD camcorder. We decided to continue since even with this limitation it is a step towards the long term goal of an open source real time video streaming platform.
- Measured power consumption of Gumstix Overo Fire mounted on the Summit expansion board:
- 250 mA during startup.
- 350-400 mA after WiFi gets turned on.
- Still need to measure power consumption of the camera, but it seems that the 850 mA LiPo battery should be sufficient.
- Ordered battery, charger and some other parts for integration from Electrokit
- Package from Electrokit has arrived. There was a small mistake in the package in that instead of 0.75 and 1 mm DC plugs I received microphone plugs! Important but not critical! Everything else looks OK.
- Added new photos to Picasa photo album
- I have weighed the various parts, see below. It looks like camera, batteries and electronics can stay within 120 grams! Not bad.
- Forgot to measure the Pinto-TH :(
|Gumstix Overo Fire||6 g|
|Camera with wire and connector||76 g|
|Camera without wire and connector||35 g|
|USB hub (just in case)||49 g|
|1 Ah LiPo battery||21 g|
|LiPo battery charger (just in case)||8 g|
|5V 1A switching regulator||4 g|
|Gumstix antenna (just in case)||7 g|
- Succeeded disabling WiFi and Bluetooth using the tip from this email thread
# disable wifi echo 0 > /sys/class/gpio/gpio16/value # disable bluetooth echo 0 > /sys/class/gpio/gpio164/value
- Disabling bluletooth does not reduce the power consumption.
- Disabling WiFi reduced the power consumption from 400 mA to 210 mA! Cool!
- Acquired some bits and pieces for creating the frame. Decided to go with a two stage frame held together with plastic screws and bolts.
- Got some plastic material that I intend to use for the base plates, unfortunately, it feels quite hard to work with.
- Mounted power supply unit a board, see photo.
- Learned that I do not have to worry about the mechanical mounting of the video recorder inside the rocket because ERU and Jan has made an acryllic plate mounted vertically that will support the video recorder as well. Glad for this.
- Tried different buffer modes for the file sink to see if it would help on the "jumps". During a 1 minute video:
- 0 - full buffering: 6 small jumps and 1 big jump ← stick to this one
- 1 - line buffering: 2 small jumps and 3 big jumps
- 2 - unbuffered: 5 small jumps and 5 large jumps. Quite useless video.
- Created scripts for disabling BT+WiFi and to start recording.
- Found out that I can not use the Summit board!!! For some reason the USB OTG can not properly configure the hub/devices connected to it. Tried USB host as well but with bad video (just like when using USB host on Tobi)
⇒ We have to use the Tobi board which is bigger and 11 grams heavier. The Tobi wouldn't have fit on a 9.5 cm plate so it is very fortunate that ERU and Jan decided to make the vertical plate!
- Tested the video recorder (using Tobi) for a 30 minute duration – looked OK but didn't watch the whole video yet.
- In the afternoon we worked on the mechanical parts. Drilled wholes for camera, Tobi board and the batteries (see photo). Will continue (and hopefully finish) this on Wednesday.
- Had to rework the power supply unit because one of the damned JST connectors got damaged.
- Tested the setup using the new power supply with the Tobi board ⇒ Passed
- Made an USB cabling mockup; however, I had great difficulties getting the camera to work when connected directly to the USB OTG port (power was bypassed directly to PSU). The USB driver claimed there was insufficient power.
- The solution was to force the device to be activated despite of the error message as suggested here
echo 1 > /sys/bus/usb/devices/1-1/bConfigurationValue
- This will have to be executed after start. It works also if the camera has been plugged in before power-on (TBC)
- Confirmed that forcing camera initialization also works if camera has been connected before power on.
- Finished USB and power cabling and rand a few short duration tests
- Confirmed procedure after video capture has been started:
- Start capture
- Disconnect console cable
- After recovery, reconnect console cable and establish connection
- If capture still running (i.e. no prompt), sen CTRL+C
- First long duration tests using the flight setup:
- Capturing stops at random due to device I/O error from camera
- Confirmed that it is not due to the switching 5V regulator
- Problem appears to be the "hacked" USB data interface
- Changed to capture 5 minute chunks in a loop
- Broken recordings can still be played using mplayer
- Gumstix Overo Fire, Tobi and batteries mounted on the internal frame of the rocket (photo to be added)
- Flight computer finished and tested (video to be added)
- So far weather forecasts have been quite bad :(
No more access to device until Sunday, Oct 3 (launch day)
- Still go for launch
- We had a great day at the Rocket Festival organized by Danish Space Challenge.
- There were 5 rockets built by student and one DSC rocket (ours).
- Launch was fine but engine cut off early. Rocket didn't get higher than 500-600 meters.
- Parachute deployed but rocket got deparated from parachute and crash landed.
- The Gumstix Overo Fire and Tobi boards look extremely well with no visible damage. So did the Logitech Webcam Pro 9000
- Sadly, the microSD card fell out and got lost either during the crash or the recovery.
- Videos from the event:
- Photos to be added
- Took the Gumstix Overo Fire and Tobi boards from each other and could inspect the damage to the connectors:
- Using the summit board, the Gumstix Overo fire could boot without any problems, so it seems only to be the connectors on the Tobi board.
Caught an interesting discussion on the Gumstix mailing list regarding video flickering:
The queue element really seems to help smooth out the stream, not sure why, but it works well. We are capturing frames from two cameras @ 10fps each and merging them into one D1 PAL frame. The cameras are outputting full image data (no compression), so just getting the images in at that rate uses about 15-20% CPU. With the h264 compression and software cropping and saving to RAM disk, total CPU is 44-50%.
It seems in your case you may be using a (UVC?) camera with a direct MJPEG interface. So you can dump the frames straight into an MJPEG container and it should work, as you are seeing. However, I would suggest you try adjusting the compression parameters; it seems you are dropping some of the data. It took some pretty careful driver tuning to get our camera working on the gumstix (even though it works great at 60 fps on a netbook), especially adjusting the parameters of the underlying camera. You should try to lower the frame rate to see if it is still dropping out. I actually set our driver to throw out any incomplete frames; I think part of the weakness is the musb driver. You might try the host port (or maybe that is worse...).
Resuming work on this project :-) Ordered new Gumstix stuff: