Go Down

Topic: Temboo + Arduino Yun - Choreo to run totally on the Linino side? (Read 1 time) previous topic - next topic

awardblvr

I am creating an implementation of a device which takes a photo via a USB-connected camera entirely on the Linino side of the Bridge.  The code running on the Arduino (32U4) side triggers the picture-taking by launching python code on the Linino side. But NONE of the actual image data is ever on the Arduino/32U4 side of the bridge.  It would be way too slow to have move that image data back and forth across the bridge (I think).

So... Can the Choreo be written to allow the upload/login/authentication activity to take place entirely on the Linino side of the bridge and not have to actively move any image data through the bridge for uploading via a "sketch"? The photo-taking and initiation of  connection/authentication, etc. can be triggered on the 32U4-side, but actually handled entirely on the Linino-side.

Thanks!

sonnyyu

#1
Mar 09, 2014, 09:18 am Last Edit: Mar 09, 2014, 09:26 am by sonnyyu Reason: 1
Yún   is Chinese word means Cloud.

It has arduino microcontroller ATmega32u4 and  Linux/ linino  microprocessor Atheros AR9331.


The Atheros AR9331 (Hornet) is a Wi-Fi System-On-Chip (WiSOC), typically used in AccessPoints and router platforms. It is based on MIPS @400MHz 32 bits CPU with no floating point support, has 64 MB DDR2 RAM and 16 MB Flash Memory.

Arduino microcontroller ATmega32u4 is 8 bits MCU Clock Speed at 16 MHz. It has 32 KB Flash Memory and 2.5 KB  SRAM.      

One of sample Web Services: Amazon Web Services (cr1.8xlarge) has 32 vCPU (32 of 1.7 GHz Xeon processor 64 bits CPU) and 244 GB RAM plus 2 x 120 SSD driver.

High compute-intensive task should most take place at Web Services by use Yún as middleware connect via ATmega32u4 to sensor.

Quote
Amazon Web Services (abbreviated AWS) is a collection of remote computing services (also called web services) that together make up a cloud computing platform. The service is advertised as providing a large computing capacity much faster and cheaper than building a physical server farm.



awardblvr


sonnyyu

#3
Mar 09, 2014, 04:22 pm Last Edit: Mar 09, 2014, 04:25 pm by sonnyyu Reason: 1
The conclusion is the standard image should be handled entirely on the Linino-side and triggered on the 32U4-side. If we work on high definition image or 3D one or video then process should be handled by Web Services use  Yún as middleware triggered on the 32U4-side.

awardblvr

It is obvious that that is what I am asserting... that the image be captured and moved entirely by the Linino side.... But all the Choreos seem to be written for the 32u4 side, including parts which authenticate and actually move the data... So I am wanting to use the Temboo choreo almost entirely on the Linino side, which the choreo examples do not appear to be designed to do.

So, BTW... I am looking at launching Python code to

1. Log in to the Captive Portal (possibly with curl? or wget, or mechanize or scrapy)

2. Instead of paying for the exorbitant charges for a Temboo account with more than one application, use the Google API info to entirely code this in python without using the Temboo stuff. Here is that url:

https://developers.google.com/picasa-web/docs/1.0/developers_guide_python

Three Projects very similar in some respects:

Any suggestions welcomed.

Go Up