Let me introduce myself... My name is Dan, and I work for Astrium, an aerospace engineering company who mainly produce satellites. We are the largest space company in Europe & 3rd largest in the world.
I am principally a network engineer, been using the wi-fi shield for a few months....and not so far away from you.
We decided we'd make use of the WiFi shield and create our own webpage that people can view the sensor readings on at the science fair (we will have a laptop connected to it at all times).
An immediately attractive idea but one with a mass of headaches.
The biggest issue you have is the lack of runtime and RAM available to your Mega. HTTP is a loose (vague) protocol. Decoding the protocol is relatively costly, as the host (server) must parse many strings of indeterminate length, within multiple contexts. Arduino developed and just released the Yun because it is such a big ask for an M/C to do on it's own. Alternatively, I have been experimenting with a Beaglebone Black for a few months, achieving a roughly similar, single board sensor/web server solution.
I concur with PaulS and XBee would be a much better choice of wireless protocol for your use case - longer range, lower power, fewer dependancies.
Given how little time you have, there may be a half way house using what you have and what you can download. Design things so the robot sends no more than it needs to send, and the laptop does the heavy lifting of processing and presentation.
1. Utilise the Wi Fi shield on the robot.
2. Run a web server on your laptop. A laptop has more than enough CPU and RAM to run IIS, Apache or lighttpd, freeing you from developing your own HTTP parser.
3. Connect the robot to the web server by writing a simple receiving application which will run on the laptop. It just needs to be able to access the IP stack, assemble a web page and write it into the web server file space.
4. Implement a simple proprietary protocol for sending the sensor readings over a Sockets interface (UDP or TCP by any other name).
Personally, I would write the receiving application using Xojo (Real Basic / Real Studio in a former life). A BASIC like, cross platform OOP language, which runs on Mac, Windows and Linux, compiles to machine code, and comes with some ready to roll Sockets classes. It should be a cinch for anyone with an ounce of programming skills to pick up the syntax and write a simple server. Xojo is proprietary but you can download the demo for free.
For the protocol choice, I would go with the lower overheads of the uncompelled UDP.
So what now? Do I need to upgrade the firmware on the WiFi shield or Mega, is that my only option? I can't understand why it's not working. This is one of the last things we need to do but unfortunately crucial to the whole project!
You may have more than one problem!
The Wi Fi shield is not without it's issues. Barring hardware fault/failure, the WiFi shield will indeed (just about) work but the firmware version must match the version of Library code used by the IDE. So, to find the right WiFi shield firmware files (on a Mac)
1. Download the latest 1.0.5 arduino.app and install to your /Applications folder as usual
2. Open finder, select Go to folder and enter /Applications/arduino.app/Contents
3. Navigate down the folder tree to Resources/java/hardware/firmwares/wifishield
Keep in mind WiFi shield firmware flashing is a two stage process. There are two controllers on board, one looking after the WiFi, while the other communicates with Arduino.
Will the firmware fix your Chrome issue? I doubt it.
The example web server code has a HTTP semantics issue going on. The server code declares a HTTP1.1 response, then goes and implements a HTTP1.0 response. The resulting browser behaviour falls into the 'undefined' catch all. Some browsers will accept the response, others (Chrome) reject it as non-compliant garbage.
HTH. Good luck with the competition.