Happy new year folks!
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? ;-)
Comments
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.
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.
@Michael
1) why?
2) why a completely new GCS architecture is needed for flight visualisation? precission: Existing GCS will be a second possibility to visualise data. The new system surely will have its own GCS.
1) No. What you've said makes no sense.
2) As clearly stated already, the device is part of a completely new GCS architecture.
Hi all. I have two points to ask you for experiencea and need some validation:
1) Do you agree with following? If not why?
The proto HW/SW solution shall be as simple as possible and newer versions can replace it later. For the SW side, when we have an WLAN/LAN/WAN and possibility to have several ports and clients opened at the same time in any SW including arduino, I would sudgest to set a port 80 for webserver, 8000 for TCP connection for securised data transfer and the port 9000 for UDP data stream. This easiest configuration uses all the adventages of TCP and UDP and will be robust and fast enough at the same time. I don't know to implement here mentioned websockets, so I don't propose it for this proto, but a mutation can be made later (There will be many of them :-).
2) This project has to allow to be usable by any GCS. Has anyone already any experiance with a virtual COM creation? Its for any GCS already made.
Maybe it was mentioned before, but a BlackWidow with an SD card shield should do the job quite easilly.
Cheers and good luck.
-
6
-
7
-
8
-
9
-
10
of 17 Next