[OpenRelief Developer] you may find some CanberraUAV code useful
montana.harkin at gmail.com
Thu Jun 14 16:20:00 BST 2012
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
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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Developer