Date: Fri, 17 Mar 2006 01:51:50 -0600 (CST) Subject: limited time makes decisions X-UID: 150 Content-Type: IMAGE/JPEG; name="img2823.jpg" Content-Type: IMAGE/JPEG; name="img2824.jpg" Content-Type: IMAGE/JPEG; name="img2825.jpg" I'm driving the robot at least twice a week. This means the development and test cycle is around three days. The near term objective is to give the robot as much capability as possible in four to six weeks. That gives me about 12 more test runs maximum which is not much when you think about it. The weather forecast here in Dallas is a high probability of thunderstorms (which tend to be extreme) from tomorrow evening through the weekend. That means I must drive the robot immediately after work. I considered testing in a few hours at around 5 am but decided against it. Development will proceed from what I have - a basic teleoperated system - towards increasing levels of automation. So cruise control with increasing capability of road following and obstacle avoidance is the objective. This allows a graceful progression from the known quantity of manual operation. The other direction, a fully autonomous system with manual override, is the wrong way to look at it. I expect to put at least one laser back on the robot. At night, the laser is easily visible. This allows structured light vision techniques. My hope is that this allows avoiding complicated image processing. Specifically, I hope that the paint stripes and edge of the road stand out enough from the black asphalt to be easy for the robot to see. The two demos are: 1. autonomous cruise down a road 2. the robot moves at low speed and follows me as I walk or run around I want to demonstrate basic capability with both of these demos by the end of April. By demonstrate, that means an interesting video with overlaid graphics indicating the internal state of the robot. From the test last Tuesday night, some operational limitations were discovered. The normal pattern of operation will be: 1. Power up laptop 2. Power up robot 3. Establish WiFi comms between laptop and robot 4. Upload robot software from laptop 5. Start robot software 6. Start laptop software 7. 900 MHz radio comms established 8. Robot starts mission 9. Robot moves out of range and WiFi comms are lost After this, only the 900 MHz radio will be available. Given the requirement for full-time manual control, that means the 900 MHz serial radio will be used for the full mission. WiFi will only be used for uploading software and returning telemetry, especially video, at short range. The Dell laptop LCD driver electronics are flaky when running off batteries. It is more convenient to run in VGA text mode with virtual terminals and not require any graphics as that runs into the Dell LCD bugginess. As I don't have much time, this further supports a decision not to have a GUI. Everything will run from a command line. However, there will be graphics overlaid over the movies from the robot cameras. This synthetic view will both look cool and also allow for easy visualization of what happened during a mission. Specifically, it should show where the robot believes it is relative to the environment as well as system status. As these overlaid graphics will be generated offline during batch processing, it does not have to be fast and efficient. Again, as development time is limited, this decision allows for a decent chance of meeting the deadline. It is my belief that decisions are made when resources are limited. If you have unlimited time, unlimited money and resources, and flexible requirements, then you'll never make any choices or progress. There's no reason to. I've only made significant progress on this project when there has been an imposed timeline. I believe that this is why places which are resource limited with a high cost of living still can be so productive. Competitive pressures take hold and decisions are forced. People work more efficiently when they have to, especially if survival is at stake. In the first picture, note the wheel positions. It is true Ackermann. The inner wheel on the left is turned in more than the outer wheel on the right. The guy at the club is wrong. The reversed Pitman arms are correct. The second picture is a view over the top of the robot with the camera mounted where the 900 MHz antenna mast would normally be. I plan to drive the robot with the camera there for fun. I'm a little concerned about shock through the frame into the camera as there is no suspension at the rear. The third picture shows the improvised fiberglass screen material used to hold the cables away from the wheels. They should help avoid snagging which could cause cables and wires to be ripped out of the electronics box. It looks messy but I don't have time to spend making a shell for the robot right now. Weight is becoming a problem and any shell would have to be light in weight.