35 replies to this topic

[Corvus Corax]

Hi

A colleague just suggested to me to look for a tablet with an nvidia Tegra chip. Apparently those are designed for embedded use and combine high graphic power for video operations with low size, weight and power consumption.

The idea is as follows:


                
GPS <- serial -> INS <-(spi?)-> OP PRO <-(USB)-> x86 embedded

OP PRO <- 2.4 GHz ->  flight control TX


OP PRO <- serial telemetry -> <GCS>
and/or
x86 embedded <- WLAN/GPRS/UMTS -> <GCS>

- the INS would run sensor fusion as usual
- the OP pro would run stabilization and Guidance as well as actuator control (and possibly Telemetry)
- on the x86 would also run an instance of OpenPilot using a modified (and hardened) sim_posix and share all UAVObjects with the OP PRO (through UAVTalk, but not a regular telemetry connection but a special link that transfers each and every object "on change") (sim_posix running in a real_time thread on linux)
- the x86 would run additional modules that deal with
- camera control
- image recognition
- SLAM
- SLAM based navigation (object avoidance, etc)
- high level tasks ( swarm navigation, visual ground object tracking and following, ... )

such a solution would be powerful, and possibly still small enough to fit on a big quad and/or a medium sized fixed wing

I am searching for suggestions regarding the x86 platform (boards/cpu's/vendors)

[ThomasB]

Seems this is going to a similar direction like the plan from Chris Anderson.
Their top secret new board (so secret that no one has seen it shall have a lot of power and they are planing some swarm control and image recognition.

best

   Thomas

[Corvus Corax]

boards with a high end CPU are hard to design due to the high clock rates involved, even in a system-on-a-chip solution (unless even the memory is on chip) I'd like to see that mysterious board

[peabody124]

Corvus Corax, on 07 September 2011 - 07:18 PM, said:

boards with a high end CPU are hard to design due to the high clock rates involved, even in a system-on-a-chip solution (unless even the memory is on chip) I'd like to see that mysterious board

Look at Gumstix.  They are easy to add as an add on module and avoid most of those challenges.  It's the same thing paparazzi does.

[Brian]

I second Gumstix, but if you're looking for even more power, we're flying a Pandaboard, which has an OMAP4 and WiFi/Bluetooth builtin.  The biggest problem we've found is that Linux (Ubuntu) takes forever to boot compared to an embedded O/S.  It could probably be improved by building up a system from a very basic Linux distribution, but it's still going to be more than the couple of seconds that the OP board takes to boot.  A separate battery would also likely help, that could be kept on between flights.

[Mathieu]

I was going to suggest gumstick too.
It runs on arm (more power efficient), the latest has the cortex A8.
It runs linux so your sim.posix will be easily portable.

I don't see the advantage of the Tegra here.

Gumstick are stackable too, so you can dedicate one for video processing, and another one for something else.

[Mathieu]

Brian, on 07 September 2011 - 08:21 PM, said:

I second Gumstix, but if you're looking for even more power, we're flying a Pandaboard, which has an OMAP4 and WiFi/Bluetooth builtin.  The biggest problem we've found is that Linux (Ubuntu) takes forever to boot compared to an embedded O/S.  It could probably be improved by building up a system from a very basic Linux distribution, but it's still going to be more than the couple of seconds that the OP board takes to boot.  A separate battery would also likely help, that could be kept on between flights.

+1 for Pandaboard but maybe too big/heavy with tool many peripheral?

[Corvus Corax]

Bootup time isn't an issue. the main flight control would run on the OP board

Thing is I'd want to do a lot of real time video processing. I'd prefer some board with a graphics processor that can be used with OpenCV (which supports Nvidia's CUDA as well as some intel acceleration features. But I double checked - even the tegra doesnt support CUDA).

I looked at the specs of the Gumsticks, and it doesn't really look like it has the necessary power. It would have to do all in the CPU and its single core, we'd likely look at over a second processing time per frame.

At the speed and altitude our vehicles are flying it needs way faster processing than that. (About 20 times that fast)

Multiple Gumsticks might be an option but I think it gets very expensive very quickly that way.

[Corvus Corax]

I checked the pandaboard. looks good - dualcore with 1 ghz might just have the raw processing power in CPU. lots of unnecessary metal on that board though, but those hdmi ports can probably be unsolered - or broken off in a crash or something leaves the question where to get a 5V source powerful enough for it

[dankers]

Quote

leaves the question where to get a 5V source powerful enough for it

Just use a separate SBEC, you can get them up to 5 amps cheaply for the larger Helis.

[Brian]

dankers, on 07 September 2011 - 10:47 PM, said:

Just use a separate SBEC, you can get them up to 5 amps cheaply for the larger Helis.

We run the Pandaboard off of a separate 2 amp SBEC, and it works fine.  We also use OpenCV on it.  It's not a speed deamon, but it gets the job done.

[StarRider]

Hi,

Take a look at the OMAP5432, don't know of any comercial board using this SoC, but sure is a powerfull beast .


Regards,
PA

[cwabbott]

StarRider, on 08 September 2011 - 01:06 AM, said:

Hi,

Take a look at the OMAP5432, don't know of any comercial board using this SoC, but sure is a powerfull beast .


Regards,
PA

That's because it hasn't been released yet, AFAIK. The A15 processors aren't supposed to come out until later next year.

[StarRider]

cwabbott, on 08 September 2011 - 01:13 AM, said:

That's because it hasn't been released yet, AFAIK. The A15 processors aren't supposed to come out until later next year.

You're being optimistic ... I stick with the original estimate for 2013, or not.

Regards,
PA

[Corvus Corax]

hmm Pandaboard seems to be out of stock everywhere with no date of restocking yet. this issue seems familiar

[D-Lite]

Corvus Corax, on 07 September 2011 - 04:53 PM, said:

- on the x86 would also run an instance of OpenPilot using a modified (and hardened) sim_posix and share all UAVObjects with the OP PRO (through UAVTalk, but not a regular telemetry connection but a special link that transfers each and every object "on change") (sim_posix running in a real_time thread on linux)

What would be the benefit of that? If OP already takes care of all the realtime stuff, wouldn't it be sufficiant to connect the higher level (navigation, path planning, image processing whatever) parts on the x86 via standard telemetry? That would be more modular, less complex and may still work well.

[Brian]

Corvus Corax, on 08 September 2011 - 09:12 AM, said:

hmm Pandaboard seems to be out of stock everywhere with no date of restocking yet. this issue seems familiar

It took me 3 months to get my Pandaboard.  Kinda like getting a CC board...

[Maniac]

Colibri T20 with NVIDIA® Tegra 2


and this

[Wellenbrett]

What about the the "Raspberry Pi" ? It will cost $ 25.- !
It is a Broadcom BCM2835 SoC with an ARM1176 Processor.
Here are some links concerning this board:
http://www.raspberrypi.org/
http://mobile.osnews...ing_1080p_Video
http://www.broadcom....roducts/BCM2835
http://www.arm.com/p...m11/arm1176.php

[Corvus Corax]

D-Lite, on 08 September 2011 - 10:51 AM, said:

What would be the benefit of that? If OP already takes care of all the realtime stuff, wouldn't it be sufficiant to connect the higher level (navigation, path planning, image processing whatever) parts on the x86 via standard telemetry? That would be more modular, less complex and may still work well.

The standard Telemetry is to be used for exactly that Telmetry - and will always connect OpenPilot to a GCS.
Update rates are supposed to "fit" on a radio link. And are controlled by the update rate fields of the metadata in each UAVObject.

An external component ON the UAV should not be limited to those update rates at all. It can fully utilize a high speed data connection without negative side effects on either. And it should be able to access UAVObjects independently of what update rates the user sees fir to transpher to/from the GCS.

Therefore - while using an UAVTalk instance and existing functionality to connect to the OP board, it would NOT use (and thus hog) the Telementry Module, but use its own Module to transpher exacly those modules it needs (similar to how AHRSConnection INSConnection module does)

Whether it makes sense to extend the metadata to make it configurable which objects to transpher and how often, or its better to mirror the entire object set and transpher every object "onChange" has to be seen. I would favor the latter because it doesn't need changes to the metadata of existing objects, but I don't know if the EventSystem / USB bandwidth can handle that.


The code to do so would be easy. If you look at the existing Telemetry Code, all it does is setup update queues based on each objects UpdateRate (either periodic or onChange), then calls its UAVTalk instance to format the object into a binary stream to be sent.

Thats a very straightforward approach and allows to do the same with a separate UAVTalk instance to do

- logging on disk (if extrenal storage is applicable) using the already existing flight logger metadata in the UAVobjects for control
- transpher UAVObjects to and fropm any separate components using UAVTalk and any available communication chanel.

thats much cleaner than raping the Telemetry module to do something its not meant to - while at the same time allowing regular Telemetry to still work.