[OpenRelief Developer] you may find some CanberraUAV code useful

[George Harkin]

Small comment about the Pi connection to the APM:
I believe we can use the onboard UART that is provided by both the
raspberry pi and the apm2. See
http://elinux.org/RPi_Low-level_peripherals#General_Purpose_Input.2FOutput_.28GPIO.29
This will leave two USB ports free on the raspberry PI (well, the A version)
Not sure about the Pi's SDHC card connection.  It may be over the USB bus
too.  Hopefully not. I can test tonight.
On Thu, Jun 14, 2012 at 9:06 AM, Andrew Tridgell <tridge at samba.org> wrote:
> Hi again,
>
> A few other things that may be useful for you while I think of it.
>
> I believe the Raspberry PI has just one USB port, so I think you'll
> probably need a small USB hub if you want a USB serial connection to the
> APM plus a SSD for storage. How is the camera attached? (we use a USB
> PtGrey chameleon).
>
> We found that USB voltage/current levels for the peripherals were
> critical. We power the APM using a switching UBEC (a castle creations
> 10A), but we don't want that fighting the USB port for power, so we use
> a USB cable with the 5V line cut.
>
> You also need to be very careful with vibration on that USB cable, as if
> it connects/disconnects it will make the FTDI/ACM driver most unhappy
> (see cuav/patches for mods to the FTDI and ACM drivers to cope with this
> a bit better without causing the APM to reboot due to DTR toggling).
>
> For on plane storage we use a 64GByte SSD connected over USB. The
> ARM/Linux usb-storage stack is not great, and we found that we can't
> sustain more than about 15 Mbyte/s to the disk. That limited the rate we
> could capture images, especially as on the panda (and presumably the
> Raspberry PI?) everything is USB. Even the ethernet adapter runs over
> the USB bus (we connect the Ubiquity radio over ethernet to the
> pandaboard).
>
> One thing we found extremely useful was to get the image capture going
> as quickly as you can, saving the raw images (we use raw bayer grid
> PGMs) to disk. We've now collected around 30 thousand images in flight,
> which we can play back through our software stack to tweak the feature
> detection, radio link code, GCS interface etc (see the
> cuav/tests/playback.py code for the playback harness).
>
> You need to be very careful about synchromising the camera capture
> timing with the MAVLink stream from the APM if you want to do good
> geo-referencing of the data. You should be able to relax that timing a
> bit if you roll/pitch stabilise the camera (you can use a couple of PWM
> channels from the APM to do that), otherwise small timing discrepancies
> lead to quite large errors in the geo-referencing. It looks like you
> have a slow flying and very stable high wing airframe, so it should be
> less of an issue for you, but I still think you should try to get the
> timing info as well synchromised as you can.
>
> That's all I can think of right now :-)
>
> Cheers, Tridge
>
> _______________________________________________
> Developer mailing list
> Developer at openrelief.org
> http://openrelief.org/mailman/listinfo/developer_openrelief.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openrelief.org/pipermail/developer_openrelief.org/attachments/20120614/d97208e3/attachment-0001.html>