Developer

Help wanted for top secret project

Happy new year folks!

3689383891?profile=original

DIYdrones hardware development team needs some help, if you think you can contribute in something please PM, our requirements are:

-Any microcontroller capable to handle a little web server can be used.

-The hardware must have WiFi access (behave as an access point).

-The hardware must have SD card slot (where you can store html files).

-Must be cheap (< $100).

 

The system must be capable to read a HTML file stored on the SD card (including pictures) and create a web server accessible via WiFi (acting as an access point). When the user is connected to the Wifi device-must type any direction like "http://192.168.1.100" and be able to load the HTML files stored on the SD. Something similar to a home router.

 

The HTML files must be able to read/write to the IO, analog and UART pins of the same microcontroller....

 

What we need from you are suggestions of the right hardware, software contributions and connections to anybody capable to help us.

 

Anyone? ;-)

 

E-mail me when people leave their comments –

You need to be a member of diydrones to add comments!

Join diydrones

Comments

  • BeagleBoard: open source, card reader, web server and WiFi.

    BeagleBoard.org - community supported open hardware computers for making
  • @bGatti: goog point. it can be done by id/pass list on the SD or it needs some other server to store id permited to acess the drone. The list shall be edited by the drone owner or administrators...this can be for some next step?

     

  • @Michael Smith: You can't use any ball of wax or hummingbird in this project :-)
  • @Coby

    It was suggested that the SD is only to serve up the initial Web Page.

    Comm virtualization (What FTDI cables do) - would allow a Wi-Fi connected client to experience the raw data stream - with latency - though minimal if streaming (All latency discussions ~200ms are dealing with polled requests IIRC.

    Logging can be a GCS feature.

     

  • Developer

    @Coby there is no need to write the data to files.  The JSON broker can synthesise replies to GET requests directly in RAM.

    Note that I'm using JSON as a strawman here; anything sufficiently RESTful will work.  The actual data rate involved is going to be low; probably no more than a few tens of KiB/sec, tops.

     

    @Petr what is faster, a hummingbird or a ball of wax?

  • AJAX is is a way for the web browser to open a socket and send tcp/HTTP/XML packets. XML can be a simple binary-64 encoded stream, making it easier to parse.

    Maybe just use a netduino plus, 512K of Flash, 127K of RAM, add a shield of the microchip wif with xbee.  It has SD card already.  The only reason for a lot of RAM/ROM, is the complexity of web pages etc, they take space.

    For a good web server use goahead for the first pass, it has a embedded file system etc, works with lwip, using it right now on a blackfin.

    I've done web servers for embedded devices (graphs, AJAX, etc), the main issue is when you have several applications talking to the web server, is the number of sockets able to process, when using a browser, sometimes images etc, the web browser will open a new socket to help speed the refresh of the page.

     

     

  • Thank for your notes and sudgestions i answer and tell me please what do you think.

    I did a long reserch on this subject in about a year ago. Any profesional coul'd propose me solution for 200ms web update and they were looking to me with a smile saing why do you need it guy? It is a web browser! The solution is stand alone solution except you put an applet into the browser (javascript,javaapplet,flash or processing?).

    The video link showing a finger writing onto ipod display and LCD displaing elsvere using websocket isn't fast even devices are 1cm one from each otherenoght (you can even see the delay!).

    In this project, the refresh frequency was asked to be minimum 5Hz, it means 200ms. It is not about seconds, it is about miliseconds and the tendancy of acceptable latency and the delay will be decreesing in the time. Today 200ms, tomorow 50ms, next year 20ms. Just what internet physicaly allows us. Depending the wifi+internet connection today, you have normaly between 20 to 200ms latency and up to 2 second randomly

    => by the solution, you can't add any other latency to get datas.

  • @Petr I am just guessing at the architecture above.  And I don't think you can compare AJAX to TCP/UDP - Different layers in the stack and AJAX is really more of a method.  UDP is in use with MAVLink.  The problem these folks are trying to solve is how to get that into a browser.  And I am assuming they are trying to do it without a client side application written in Java or Flash.  Yes, you will have latency.  But if you start with the basic assumption they one is not trying to fly the thing in real time via the browser than it makes little difference.  I can wait a second to see the data if the events I am controlling are not millisecond critical.  And I would submit that you should not try to use a browser for anything millisecond critical.  Use it to produce a cross-platform view that will enable a few small changes to things like flight plan and call it good enough for version 1.
  • I am not sure about AJAX. Does AJAX has da same latency as TCP or is it as fast as UDP?

  • So in review...

    - UAV to/from GCS is handled by xbee using MAVLink (pretty much like it is now)

    - GCS now also parses MAVLink messages and reads/writes JSON to SD card

    - Web server then reads same JSON files and uses AJAX push (HTTP Streaming or whatever they call it these days) to browser via wireless

    - Browser can update said JSON files using AJAXy methods via wireless

    - GCS does reverse with any changes from browser

     

    @Michael I think the architecture is important to know because I am not sure what kind of hardware it would take to pull the above off.  I am *guessing* if you keep the simultaneous connections to a minimum you are OK.  But what about things like file system IO limits?  Can you refresh the data on SD quick enough and maintain some kind of state using sub 100 hardware.  Perhaps this stuff is all done in some kind of high speed cache.  I really don't know and am just asking as I think this is a great idea and looking forward to learning more.

This reply was deleted.