[Adam Bercu] and [Dan Landers] from Artisan’s Asylum in Somerville, MA brought a very, very cool toy to Maker Faire this year. It’s a two hundred pound WiFi repeater deploying robot able to amble across unforgiving terrain and my foot.
The robot is controlled through a web interface with the help of a front-mounted web cam with pan and tilt controls. All the signals are sent through a WiFi connection to a node.js web server; not the best way to communicate with a robot over long distances, but [Adam] and [Dan] have a few tricks up their sleeve.
On the back of the robot are two Pelican cases loaded up with a battery and a Linksys WRT54G wireless router. When the robot reaches the limits of its range, it activates a solenoid, dropping a WiFi repeater. This repeater has enough battery juice to stay powered for about a day and a half, meaning the robot can make multiple trips to deploy a wireless network through some very hostile terrain. Perfect for disaster and search and rescue operations.
There are two videos after the break: the first is [Dan] going over the capabilities of his tank bot and the second is a short demo of the bot tearing up the grass at Maker Faire.
Continue reading “200 pound, WiFi deploying robot ran over my foot”
In the latest episode of XDA TV [Adam Outler] turned his Android phone into a webserver. At first this might sound comical, but the ever-increasing power of our handhelds makes it a pretty legitimate option. It’s hard to come up with concrete uses off the top of our head, but we’re sure there’s value in being able to pull the phone out of your pocket and serve some content.
The app BotBrew Basil makes the installation process nearly automatic. It gives you point-and-click access to install the lighttpd webserver package and set the daemon to run automatically at boot time. That’s it! Of course you need to supply your own HTML to be served. [Adam] used an HTML5 website template for this.
Next you also need a way to resolve the address of the phone. In this case it’s assigned a static IP from the router, and a dynamic DNS service provides a link that maps to the router’s location. But since these phones are running Linux (at least on the lowest level) it should be pretty easy to add a cron job which will send IP address updates to the service if you want to take the ‘webserver’ out in the world with you. You can watch the entire video after the break.
Ironically this is a big hardware upgrade for [Adam’s] webserver. The previous version was running from an Evalbot.
Continue reading “Using an Android as a webserver”
[Dodgy] wrote in to talk about his power meter data harvesting programs. This uses the same hardware by CurrentCost as the hack we looked at over the weekend but [Dodgy’s] implementation is different. It’s separated into two parts, the first is a webserver written in C that harvests the data and makes it available at an address on the network, the second is written in Perl to format and upload data to Google PowerMeter.
The C program serves data on a configurable port, defaulting to 3090. All of the data can be accessed in one line of code by loading http://127.0.0.1:3090, or individually with subdirectories like /watts, /time, or /tempr. From there you can do what you want with the data. The second part of [Dodgy’s] suite is a Perl script that polls the C server and sends the data to your Google account.
One thing that interests us is his comment that you should be able to compile the server side C code for an embedded device. It would be a nice energy savings to be able to upload data regularly without a PC running constantly.
The Arduino platform should be perfect for throwing together a lightweight webserver because of the availability of quality shields that take care of the hardware for you. As [Ovidiu Predescu] found, there are a few hiccups along the way and he’s put together a guide that covers the workarounds. Specifically, using an Ethernet shield and data logging shield at the same time produces a bus conflict which he sidesteps by cutting the CS pin trace on the data logging board and moving it to a different pin. There is also a bug with one of the chips on the Ethernet shield that is fixed using a similar method. So if you’re not just going to etch your own webserver hardware maybe this is the next best thing.
Within a ten-hour window [Wes Brown] threw together this toaster with a web interface for one of his classes. He sourced the WIZnet embedded webserver for the project but this could be pulled off with a homebrew webserver as well. When you point your browser to the correct address you’re greeted with images of bread that have been charred to various degrees. This greatly complicates the act of making breakfast while at the same time presenting a possible fire hazard. Check out the video after the break.
Continue reading “Toaster web interface”
Reader [john] finished up his home power monitor over the holiday weekend. It uses a pair of current transducers clamped onto the mains. These output 0-3V and are read by the Arduino’s ADC. The Arduino averages samples over a 20 second period, calculates power used, and uploads it using an Ethernet Shield. The shield can’t do DNS lookups, so he uses a WRT54G to negotiate with the remote webserver. He admits that the system could be more accurate; it can’t detect small loads like wall warts. He also says that money could be saved by talking serial to the router instead of over ethernet. Here are the current usage charts.
You can find many power monitor projects like this in out Home Hacks category.
On a recent trip to New York City, [sherri] noticed the abundant “NYPD Security Camera” signage. She Ò on her little sousveillance tour and did some digging to learn more about the system. According to a recent NY Post article, the city intends to have 2,000 cameras installed by 2009. Each unit has at least two cameras, an onboard DVR, battery backup, a webserver, and wireless connection. The CrimeEye product line is manufactured by Total Recall—the people who brought you BABYWATCH. While the company site doesn’t list any specs, we found a price list that was provided to New York State. Each unit lists for $28-39K. They can have image sensors up to 2 megapixels, hold 30fps video for 5-15days, and transmit wirelessly on the 4.9GHz public safety band.
[sherri] wonders what systems are in place to guarantee the security of the camera network and to make sure the data is handled properly. We’ve seen bad implementations of cameras with webservers
in the past. She suggests a third-party system to verify security, operation, and storage. Right now there’s no reason the government won’t use footage for invasive data mining. As a publicly funded system monitoring public areas, we see no reason why the video streams from these devices shouldn’t be widely available.