<< CCC | Progress Report | >>

    Last updated: 1 August 2000 &beetung <Tue> 4:35pm
 
 

 1. Aim of this Report

The main purpose of this report is to present what has been completed during the first three months of our CCC project. Our goal this year is to make enhancements on our previously built computer controlled car prototype both in terms of software and hardware.

 2. Relevant Background Information

The idea of a utilizing a computer to achieve a fully automated vehicle is not new. It was the subject of various researches during the past few decades [1,2]. In our prototype model [5], we utilize visual information alone provided by a CCD camera which enable us to extract sufficient hints to navigate a model car around a designated track in a safe manner.

The following diagram illustrates how our prototype comes into realizing its surrounding visually, where does it process this information and eventually perform navigation control. The shaded area is where I have been mainly focused on during the first semester. For a full description of our prototype model, please refer to our project website.
 
 

Our initial goal  is to:

1) bridge the existing system to work under Linux, hence:

 Establish a DIN8-RS232 connection

 Purchase frame grabber/video capture card

 Code the frame capture routines

2) Implement an advanced navigation system which make use of various “smarter” algorithms.
 
 
 

3. Progress Summary

The following table lists out the major milestones which I have completed so far. A detailed discussion follows.

3.1 Build a RS-232 to DIN-8 cable
The initial connection from computer to RF-Controller is a DIN-8 to DIN-8 connection (Refer to the diagram below). A DIN-8 port is commonly found on Macs and INDYs. Yet, most PCs are commonly equipped with RS-232 instead of DIN-8. Since our prototype controller is designed to work with a DIN-8 connection, our initial idea in enabling our existing computer-controller interface is to built some circuitry to enable us to bridge the DIN-8 connection to work with RS-232 so that we can interface it with a PC. However, after some research into DIN-8, it was found that both of their terminal voltage and Specs are compatible with each other. It turns out that we only have to build a cable and flip some pins in order to interface our existing controller with RS-232. Eventually, a RS-232 to DIN-8 cable was built.
 
 

3.2 Testing the limits of car
After the cable was built, we are faced with another difficulty: There is no documentation on what transmission parameter(baud, parity, size, stop) to use for the RS-232 connection. A detailed look into previous year’s source code doesn’t reveal any hints at all. Eventually, we tested it with the standard Unix TTY connection parameters (9600,none,8,1) and the car responded accordingly.

Two separate programs, written under two different OS, were produced to confirm that our selected parameters are suitable. They are attached in our Appendix A.

In addition, we have also made measurements on the size of the wheel and its maximum turning angle. Ultimately, we compared our estimated full 360 degree turn diameter (ie: the least diameter of a circle when performing a 360OC circle turn) with a few actual measured ones. This was done under different floor surface conditions but with the same load condition (batteries) to allow for possible error. Note that our measured result is only a typical value and it is very likely to vary under different circumstances.
 
 

3.3 Mapping car control command
As mentioned previously, we have no documentation on the controller design at all. How do we know what command to sent so that the car would respond in a correct manner. (ie: if we choose to turn left, what command should we sent to the RS-232 port?) Again, this problem arises due to a lack of documentation.

Eventually, I managed to map the response of the car by sending ASCII value (0 ? 128) to the car. Our result is summarized in the following table. The port parameters used are: 9600, none, 8, 1, representing baud, parity, data and stop respectively.

 

Value*	Symb	Action
0		NIL
1		Backward
2		Forward
3		Forward (fast mode)
4		Right turn
5		Right & Back
6		Right & Forward
7		Right & Forward (fast mode)
8		Left
9		Left & Back
10		Left & Forward
11		Left & Forward (fast mode)
12		NIL
13		Same as 1
14		Same as 2

*value represent the value as (char) being sent to the serial port. (ie: value 0 means ’\0’)

Again, the previously written programs (under two different OS) were altered to enable further testing of these sequences of command. Eventually, we were able to utilize the cursor keys on the keyboard alone to control the movement of the car directly.
 
 

3.4 Testing out borrowed frame-grabber cards
After meeting with Prof. H. Wu from the CSSE department and Mr. T. Cornell from the ECSE department, I obtained some very useful practical information regarding a frame-grabber device. I also managed to borrow a WINNOV VO frame-grabber card from Mr. T. Cornell to test out the operation of our prototype under Linux. The following section describes what I have done in order to test out this card.

The first obvious step when introducing a new hardware to Linux is to search through the Linux Web site and relevant newsgroups. I managed to find a Linux driver [6] for this particular card. A new Linux Kernal was complied with various frame-capturing functionalities enabled as modules. After going through the documentation for Video for Linux [4] and downloading several capturing programs, the capability of the card was tested.

Eventually, we successfully establish a connection from the CCD camera to our computer screen. Our setup configurations are the same as those illustrated in Figure 1. Using the arrow keys and the real-time captured images received, we successfully navigate the car manually through obstacles.

This exercise has proven to be very useful and practical. It allows me to better understand the various hardware and software issues that we must iron out before we can implement our track identification algorithm. Also, it gives us a new insight into how we could perform navigation control directly using the captured images.
 

3.5 Coding frame grabbing routine in C++ and building simulator
After that exercise, I decided to build a simulator to simulate the received images. This simulator would enable me to test out my Track Identification Algorithms directly without the need to setup all the necessary equipment in order to test it out.

In previous years, all frame-grabbing related routines are handled by a third party library (provided by Silicon Graphics, as standard on INDY machines). Since we are attempting to utilize a PC instead this year, all this frame-grabbing routines would not be available under Linux. I have put in a lot of effort during the first semester to create from scratch a faster and a much more programmable video sequence manipulation library in an attempt to eliminate the identifed bottleneck between transferring an image from the CCD to computer.

Eventually, an X-intrinsic library, a customerized Linux kernal and a simulator were built. Currently, I am in the process of merging all three together. I expect the final product would enable us to depart from the time-consuming frame capturing routines by a SGI-INDY since the process of frame capturing is much more accessible.
 

3.6 Other Completed Goals

Testing XSHM extension for Linux
XShm allows direct X image mapping from memory to screen without utilising the slower X interface. Hence can draw on screen faster! In a sense, it is similar to DirectX for Windows 95. I managed to achieve 44fps on a P-III. From several newsgroup article, it seems quite possible that frame rate above 100 can be achieved.

Basic Algorithm object structure
I have implemented the basic structure of my algorithm design. Track folding seems to work quite well but there are lots of different issues to be addressed still! Ie: where should the folding window be, how does this interact with short-term history mapping,etc. Refer to our project website for more information

P-Thread package
A multi-threaded library(p-thread) has been tested under Linux to perform some concurrent calculations. We might utilise this library later on for various purposes.

Reading Tim’s 1999 C code
I have thoroughly read Tim’s navigation system code. His navigation system is quite logical and simple to understand.

Other Hardware Testing
Measuring the latency between sending a command and respond of car. SLOW! This effectively limits our achievable maximum speed. Full detail in my personal log book.
 
 
 

 4. Current Progress

As mentioned previously, I am currently working on merging my simulator with our customized Kernal functionality. Since I have returned the frame grabber card to Mr. Cornell, I have been focused on writing the simulator.

As part of my research in collusion avoidance and track extraction, I have gone through several papers discussing the advantages and disadvantages of various methods. It is expected that during the second semester, several algorithms on track extraction can be implemented.

Currently, I am still searching for a suitable frame-grabber card which fall under our budget range.
 
 
 

5. Future Research Area

Basically, my research area mainly focus on Track Identification and Collusion Avoidance as highlighted in our project website. Both of these would be implemented in software although a hardware implementation is also possible. For more information refer to my proposed algorithm under our project website.
 

 6. References

 
[1] Parag Batavia, “The Navlab Group at CMU,” http://www.cs.cmu.edu/afs/cs/project/alv/member/www/navlab_home_page.html, last visited:14 July 2000.

[2]  John McCarthy, “Computer Controlled Car”, http://www-formal.stanford.edu/jmc/progress/cars/cars.html, Last Visited: 13th July 2000.

[3] John McCarthy, “Computer Controlled Cars (April 1999)”, http://www-formal.stanford.edu/jmc/future/cars.html, Last Visited: 13th July 2000.

[4] Alan Cox, “Building Number Three –Video for Linux Group,” http://roadrunner.swansea.uk.linux.org/v4l.shtml, Last Visited: 17th July 2000.

[5] Tim Bruton, “A Vision Based Navigation System for a Computer Driven Model Car,”http://www.csse.monash.edu.au/hons/projects/1999/
Tim.Bruton/report.html, Last Visited: 16th July 2000.

[6] B. Dirks, “Winnov Videum Linux Page” http://millennium.diads.com/
bdirks/winnov.htm, Last Visited: 2 June 2000.
 
 

 7. Appendix A: Source Code Print-out

-please refer to my hard-copy submission
Application 1
Listing I - DOS program for sending commands to RS-232

4025 Jul 28 01:00 JOYM.C
2861 Jul 28 00:59 DCOMM.C
4362 Jul 28 00:59 DCOMM.H
4783 Jul 28 01:00 DCOMM2.H
 
 

Application 2
Listing II – Linux program for sending commands to RS-232

1020 Jul 28 01:00 main.cpp
1961 Jul 28 01:00 timer.cc
1539 Jul 28 01:00 Makefile
 
 

Application 3
Listing III – Simulator program

 2000 Jul 28 01:15 main.cpp
 3184 Jul 28 01:15 xwin.h
18900 Jul 28 01:15 xwin.cpp
 4015 Jul 28 01:15 box.h
 1768 Jul 28 01:15 file.cc
  960 Jul 28 01:15 misc.c
 1961 Jul 28 01:15 timer.cc
 1629 Jul 28 01:15 Makefile