|
DMI News |
Previous Entry.. Next Entry.. Car Updates
January 07, 2003 15:18 The video transmitter has been ordered. I should have it by friday, but assume the worst and predict receival by the middle of next week. This will solve the problem with the RC Car running out of range of the cam, as it won't need to be observed from a static cam any longer. However, there will be a host of new problems. First off, there's that ledge.... I will probably build some steps with a wide cascade. In the meantime, I'll just forbid people from driving over it, and ban anyone who does. End of problem. :) There's also the problem of the first come, first serve method of command acceptance. Steering commands respond immediately. However, power commands, moving forward and backwards, take time to complete. They operate by giving power to the car for a specified period of time, typically about half a second, then releasing power. There's also a 1-2 second cooldown period after any power command to make sure the car is at a standstill before it receives the next command. Otherwise, it could accumulate velocity over several commands and do some undesireable things, like slamming into a wall full speed, or even flipping over. The other problem is simply a one of coordination. The server takes the commands from whoever sends them, in whatever order they come in. If three people are trying to drive the car, it will go in all different directions. Don't even try to think about what it will be like with 20 people. To solve these problems, two separate queues are being implemented. An event queue, and a wait queue. The event queue takes the car's power commands and adds them to a queue, instead of immediately executing the commands. A separate process thread will then take care of each queue command one at a time. Also, any host can only have one event on the queue at a time. Any more commands from that host will be ignored. This prevents people from sending hundreds of commands while waiting for the car to move. This slows down everything else. A similar queue will be implemented for the X10 devices, which have a similar delay problem. The wait queue is harder. This will allow only one host at a time to control a specific device. This is primarily for the car, but might apply to other appliances as well. A user will be able to lock a device for up to a certain length of time, probably 5 minutes by default, during which only their host can control the device. When the device is locked and someone else wishes to play with it, they add themselves to the wait queue. When the initial lock expires, the next person in the queue gets the lock, and therefore will have 5 minutes to play, uninterrupted. The problem with wait queues, there is no easy way to feedback information to the client without using an applet of some type. While an applet is an ideal solution, and one I intend to add for several features on the site, the more I am capable of doing with simple html and javascript, the better.
|