Here would be something cool I have not seen yet.
“Publish” some Fez’s on the Internet live in couple different ways.
Simple text box with c# sample code that user can change. On “Send” click, dynamic compile and deploy code to a fez and send debug output to an output box. Gives ability to really connect with the product in a real way and have some fun. Output compile errors if can’t compile.
Have a live SmoothStream Cam of a few different fez-bots setup. Under the video, have some web buttons to drive the bot. Bot runs inside some guard rails. Maybe a minute control limit on a round-robin.
Other various on the theme with buttons, leds, and sensors.
Launch foam missles at Gus on demand. How fun would that be?
Toss balls in small hoop from simple launcher using cross hairs to get points on score. Cam mounted on fez for aim. Tilt-pan-zoom movement on fixed base. Scoring, movement, and launcher all controlled from same fez.
Pretty cheap to setup, but high coolness factor. MS would probably even host the back-end on Azure for nothing as this would be sweet.
You could allow only one user at a time for a given time period (based on the users IP).
Or just don’t keep connections open. Just handle one webrequest at the same time. You could use my WebServer for this and set up link a callbacks to a given url.
A simple queue algorithm would be very easy to work up.
The person gets unlimited time to control the robot if nobody else is around, but if someone arrives, use is limited to 5 minutes. Commands are passed from the webpage (simple AJAX) to a php script on the server that opens and submits the control data over sockets to the robot.
I am more a server service guy, so everything looks like a server object to me :).
I would forget about the web ui part at first and design more from service perspective.
Create a server object with tcp sockets. The server object does all the robot controls (move, stop, etc). Each cmd is exposed as a message. The server object listens to all sockets, but only 1 client socket is “active” at a time based on the round-robin queue. Other users are ignored.
The robot service control network interface is in DMZ.
Now you can “surface” the control via web page, console app, silverlight control, etc. from the public facing side.
If I was doing it. Instead of using raw sockets, I might surface the control with ADO.Net Data Service (Astoria) REST interface. Its nice because it bridges the web-to-.net layer cleanly and gives you nice REST interface that you can just use URL namespace to make commands and/or query on the public side. Your internal DataService class handles the internal state and controls. In this way, someone could easily even make their own client controllers. Also makes incremental testing and dev a nice experience. Then have the html/java guys go nuts on the REST interface.
[url]Microsoft Learn: Build skills that open doors in your career
[url]Microsoft Learn: Build skills that open doors in your career
In my mind, fez is the ultimate server (end-device). But the web traffic needs to be filtered/managed by a “big” server. The big server handles UI and schedule queue, logging, etc. The active “user” gets to send cmds to the Fez device.
So the fez would also have a server service listening (on serial, tcp, wireless, etc) and react to those commands and pushing sensor state.
3-Tier Fez!!!
More I think about it, WCF Data Service (ADO Data service) would be neatest way to expose this. As URL/DNS namespace hierarcy tree would make adding other FEZs and functions very sane and neat and keep everything channeled in single interface point. Free Linq style query takes it over the top (in a good way).
Example:
http://tinyclr.com/FezBot1.svc/Move?degrees=360
http://tinyclr.com/FezBot2.svc/Pivot?degrees=90
http://tinyclr.com/FezBot2.svc/GetLightSensorValue
FEZ Mini over XBee.
Webserver on CWX.
CWX also has a USB webcam taking shots every 5 seconds that are stored and served out to the client webpage which are set to autoupdate ever few seconds.
Control is passed down from the webpage, to the CWX and over XBee to the robot.
I have 99% of the code done to do this since I did a very similar project with RWAR. Some of it’s in FEZZer, but stuff like the webcam lib is not.
I have no doubt that a CWX could keep up with like a 10 user strain, proably much more. Users would have to enter their name and the system would generate an ident and place them in queue to control the bot.
You could even point infrared beams in the goal post and get feedback that way.
When you log in with your name, you’d get routed to one side or the other with a blank counter as your score. Two people would go at a time and the CWX would monitor it and handle the webserver tasks.
I’ve seen similar things before with robots in a room/large box with some obstacles, ramps and objects to push around - as well as a laser pointer on the robot. Was all controlled through a web interface that would queue people up to play.
It wouldn’t be hard to do with the robot kit, if I had some free time I’d do it with some xBee’s or Aerocomm’s and a chipworkx or pc web server.
Ideally though, the mini robot would be running a SPI wifi device on the UEXT connector that talks to the network wirelessly.
I like the soccer idea. That way you can have 2+ robots and 2 people in the queue at same time playing each other. If only 1 person active, then other robot will be idle or random moves. 1 blue fez and 1 red hat. The field would just have some small plywood sides. Add a flat pusher plat on the front of two robot kits.
Out of intellectual curiousity, I ended up doing a proof of concept using WCF Data service to control a Fez. Works really neat. I Self-Hosted a wcf service in a Winforms app. The app then talks to the fez via cdc serial port. Just doing simple cmd/reply pattern with text lines over the serial port. Could upgrade to XBee easy.
The winform and/or the Browser can send commands to the fez. This is nice, as you can have a “control” form for robot back-end operations (i.e. pause, etc) and an Open web interface that can be reached from any browser or web server. The robots could even control each other via same interface.
there are a lot of robots on the internet which use a infrared beam to determine where their docking station is. This technology could be used for this project.
