After two days of all-nighters, RoboBuggy was ready for rolls!.... or so we thought.
The primary goal of the first rolls was to gather data from the camera plus the odometry. The camera would provide the useful line data, the quadrature encoder would tell us our turning status, and the hall effect sensor would tell us how fast we were going. I would be driving the buggy via RC controller as it went down the hill.
The first night we stayed up, we were planning on getting the buggy ready for "capes". For those of you who are new to buggy, "capes" is short for "Capability" and basically would test whether the buggy could brake in time in case of an emergency, and whether or not it would swerve whilst it was braking. There are a few more specifications for "capes", but most of them were reserved for a human driver, so we didn't have to worry about them. (Someone from the Buggy universe feel free to correct me on my definition of "capes" ).
Here's a video of RoboBuggy caping:
The swerve at the end was my fault. I was trying to overcompensate for the braking maneuver. Most of the other trials we ran were pretty smooth.
The actual rolls were not as successful. Our main goal for them was to gather data from the camera and the sensors. We found qjuickly found out that RoboBuggy was far too light to go fast enough in the free roll. We will be correcting this problem by placing some lead shot in the tail. In addition, Nate and I wanted to take a path directly in the center of the street in order to maximize our data collection, but according all the drivers we've talked to, this is a horrible line to take. Instead, the Buggy should follow closer to the bike line, and then switch bike lanes at a given time. In the end, the buggy rolled to a stop right near the end of the free roll and had to be taken off of the course, because it was taking up too much time.
In addition, as we were taking the buggy back, we noticed some strange quirks that it was having. The IC controlling the brake was jostled out of position and caused the brake to engage randomly. The computer shut itself down too, right before we started rolling. The cause of the computer shutting down seemed to be a result of issues with power consumption. The batteries were tested before rolls, and seemed to supply enough power to the components. After some additional testing, it was determined that the batteries need to be FULLY charged in order for Robobuggy to perform to its fullest potential, rather than adequately charged.
Though, there is a bright side. There is a brand new RoboBuggy computer on the way, its a very expensive piece of equipment that's primarily used on trains. Its also very well encased in a black box, which should make it much more robust that the computer that we are currently using. In addition, the hardware board was laid out using Eagle CAD and ordered through a company. This will make our hardware much more robust.
We will try to roll RoboBuggy at rolls next weekend, even if the new hardware doesn't show up. We'll continue to run it on RC until Nate is comfortable with giving the software a test run.
Stay Tuned!
