(a) trying to figure out how to get the server-side application to send the steering and acceleration controls to the serial port
(b) how to retrieve the video pixel data from the serial port to be displayed on the client side
(c) how to create streaming video using the pixel data

Valdis:

I've finally made contact with both candidate RF companies: Digital-Wireless and RF Monolith.  Digital Wireless has precisely the kind of product we're looking for, except that they want $3450 for a pair of wireless tranceivers.  After a week and a half of calling all over the country, I finally (just) made contact with Mr. Larry Heep from RF Monolith headquarters.  Their 115kbps-capable kits don't hit the market for 4 months, but he was very helpful and is going to do all he can to send us a prototype at the least.  I'm also having Digital Wireless look into other alternatives for me as a back-up.  I feel fairly confident that one of these options will pan out, and if that doesn't turn out to be the case we can just buy a long serial cable and demonstrate proof-of-concept (knock on wood).

Also, today I spoke with some of the robotics club members about servo interfaces, and they said they could provide me with links to very helpful resources.  Basically, the servos are a 3 wire interface.  One is power, the other is ground, and the last is a pulse width modulation signal similar to the accelerometers used in lab.  The pulse width varies from half a millisecond to 2 milliseconds, and must be cycled to repeat every 20 milliseconds.  This shouldn't be too hard-- at the very least I know that servos have been used in past quarters, and (hopefully) there still exists some documentation on that subject.

Update: 5/1 (Valdis Riekstins)

I've learned more about the servo interface.  Things are a little more lax than I first reported.  The pulse width is approximately what I said earlier (from 0.5 milliseconds to 2.0 milliseconds), but the refresh rate is up to the developer.  Basically, every time the servo sees a pulse, it updates it's angle to the amount specified by the pulse.  If no change is needed, a refresh isn't needed unless the servo could wonder out of place.  In an RC car, this is definitely the case, so we'll need to refresh.  But knowing that the refresh rate isn't set in stone helps the design process greatly.

Also, I've picked up all the new parts I needed for the car over the weekend.  This included a new pinion gear (with the least number of teeth possible), a new transmission spur gear (with the most number of teeth possible), and a new engine (with a high wind count-- this equals out to slower top speed, but greater torque).  All of these modifications should slow the car down nicely.  We can still electronically limit the top speed too if we have to.  These new parts will be installed on the vehicle tonight, and then I can give the car a quick shake-down with the stock electronics before making irreversible changes to the on-board electronics.

Update: 5/4 (Valdis Riekstins)

All mechanical modifications to the car are complete.  The new motor has leads soldered onto it and new gears have been installed.  The car ran funny during a test run, but I think this is because of damage caused to the RF receiver when I took it apart.  I will try another run with a different receiver.  If it is still acting funny, I will try a new speed control servo.

I've been working on the UI, and currently I'm investigating several technologies in parallel... J++, VB, DHTML, and others (and combinations of the aforementioned).  So far, I've got it LOOKING right about 3 different ways, and now I'm trying to get the underlying code in place.  I will work more on this tonight.

Also, the servo control module is almost complete.  I've created a verilog block that takes in two 8-bit numbers, and outputs two pulse-width modulation signals that will drive the servos.  Simulations have been promising so far, and I'm about ready to download it to the FPGA.  More on this soon!

Update: 5/5

We've pretty much decided to use ActiveX controls for the server and client web applications.  There is an ActiveX control to send and retrieve data from the serial port, so we should have that part working pretty soon.  All that's left is to figure out how to create streaming video from the pixel data coming from the camera.  All of this work with the ActiveX controls is being done in Visual Basic.

Update: 5/5 (Valdis Riekstins)

Last night I finished re-building the car, and now it works perfectly with the new motor and gears.  Ripe for tearing down and adding electronics!  I've already started building areas in the car for power supply and for the XS40 board that will eventually get mounted.

Also, a few hours in the lab resulted in a Verilog module that can output the correct pulse-width modulation signals for the steering servo and throttle control!  I was unable to download it to the FPGA and test directly due to pin limitations (are there even 11 free pins on the XS40?).  But, all of my simulations were entirely successful.

Also, Ngochan, Duy, and I all met and laid out our high level diagram and created a plan of attack for the next few weeks.  Currently my focus is on the mechanical aspects of the car, and learning VB so that we can create our ActiveX controls on the UI.  Duy is going to be working on the COM port interface on the Web Server.  And Ngochan is still working with the camera and getting that to work flawlessly.  Next week we will concentrate our efforts on getting the Xbus into our project and working with the camera interface and with the servo control.  Then all that is left is the Web Server stuff, the serial communication issues, and debugging.  Granted, that still is a lot (even though it doesn't sound like it), but I think we can do this!

SCHEDULE & PROGRESS

Valdis:

Duy:

• Week of May 8 to May 12

  • Web interface

    • (5/12) Worked on presentation slides, so the web interface hasn't been completed yet. I will add the Winsock control and the box for the video display onto Valdis' existing Web UI code over the weekend.

• Week of May 15 to May 19

  • The serial port to server interface should be done by the middle of this week. Once we have the pixel data get output to the serial port, we can test this more thoroughly.

  • (5/16) Added the TCP/IP control to the client UI and modified the look of the UI a bit over the weekend. Today I worked on sending the steering and throttle control values to the server. I got it to work correctly, but after modifying some other code, the client starting sending incorrect values again. So that still needs to be fixed. Once that works, I'll work more on the serial port to server interface.

  • (5/19) Still no luck in sending the steering and throttle values to the server correctly.

  • Figure out how to create image files from the pixel data, in a format such as .bmp or .jpg, which will be transmitted from the server to the client.

  • Haven't found any info on this yet, so we may end up just transmitting all the pixel data from the server to the client, store this data in a buffer in the client, and then output each pixel to the display using a loop (after the entire image data has been received).

• Week of May 22 to May 26

  • Get the video display on the client working.

  • (5/23) Figured out how to create bitmap files for the video images. Basically just ripped out the header from an existing .bmp file for an 8-bit grayscale 128x120 image file. The pixel data will be appended to this header to create a file. The only difference is that pixel data for a .bmp file is stored starting at the bottom left of the image, whereas our memory will have it stored starting at the top left. Also added the code for the serial port interface to the server program. Can't really test it out until the hardware is ready.

  • (5/25) Figured out the problem with the client sending incorrect control values to the server. Now to figure out how to fix it.

  • (5/26) Helped Ngochan debug the serial port interface. Deepak found that the reset button was incorrectly wired up, and we found that pin 68 didn't work for the external clock. Hooked the clock up to pin 28, and the serial port interface worked. Then hooked it up to pin 68 again, and it worked this time, oddly enough. Tested the server program at 9600 baud, so it took a little over 10 seconds to get enough data for 1 image. Tried setting the baud rate higher, but the baud rates allowed by Visual Basic don't match the ones we can get from the hardware... we need to find a solution quickly.

  • Help get the servo controls working properly for the car steering and throttle.

    • Haven't gotten there yet.

• Week of May 29 to June 2

  • Make sure everything works properly

  • Document the project

  • (6/2) Worked with Valdis and Ngochan, and got our board setup working pretty well. The camera is now programmed using an EEPROM instead of commands at the DOS prompt. XBus works, and seems to send data from memory to the microcontroller correctly. We have raw data output from the camera into our server. I just need to figure out how the conversion to grayscale works, and then I can either convert the pixel values to work with my .bmp palette, or even better, adjust the palette in the .bmp header to display the raw data correctly. Also the board outputs the correct center values for steering and throttle, when we first configure the board, but I'm not sure if it's taking the control values from the server correctly, since I haven't been able to get the board to change the pulse width for steering and throttle.

  • (6/2) Another update today: Ngochan and I figured out that the EEPROM had the wrong camera configuration data. We configured it first using the EEPROM, and looked at the display on the VGA monitor. Then we reprogrammed it using another board and the command line method, and the display on the monitor seemed different (from what we could make of the garbage on the screen). We ran into some problems with our second board later on, so I borrowed a spare FPGA from Group A (thanks guys) to program the camera, only this time I tried displaying the image on our server application rather than the monitor. Here's our very first somewhat successful frame grab.

    

    So it turns out I already knew what the pixel values represented (the pixels get whiter as the values increase from 0 to 255). Now to figure out how to fix that strange problem with the mushed image.

  • (6/4) No luck the past 2 days. Things seem to to be going backwards. I have only been able to get images similar to the one above 1 other time. Otherwise I just get garbage on the screen.

  • (6/5) Turns out that I have to power up the camera a couple of times before it works right. Sometimes it just gives us garbage, so unplugging the power and replugging it sometimes fixes the problem.

    

    There it is. An image (enlarged using a photo editor) from our first successful camera setup using the server. It turns out the last image before this (see update for 6/2) only needed one change to the camerain module. Instead of setting it up for 159 pixels per line, I just changed the value to 160. Now we just need to fix a problem with frames getting clipped. It seems that we don't let a frame get completely written to memory before we switch banks to read and write to. And the problem I had of getting our test setup to display on the monitor... after loading up the Xilinx project, and configuring the camera using the command line, I had to load up the project again before it displayed correctly.

Created By: Valdis Riekstins

Last Updated: 5/5/00