Written by Steven Hansen about our ECEN 490 Senior Project BYU Robot Racer 2009

A fundamental piece of the project was actually controlling the steering angle and driving speed of the robot in order to successfully navigate the complicated pylon courses. After deciding early in the semester that we would drive directly towards the pylon we simply had to build an algorithm that could use the vision data to perform that principle action. First we created a few principle parameters that would be used throughout the control code. This including the parameters for driving straight speed, turning speed, number of encoder ticks to count per radian, and the distance before pylon to start turning. We were able to first successfully run the control code through the given simulator. Which allowed us to do some initial adjustments to our design and test our idea of driving directly towards the pylon.

We implemented this design with a simple state machine. During iterations through the main loop it would call the control state machine after analyzing a new frame of data from the camera. The state machine consisted of 6-7 states that the truck could be in at any given moment. The states included:
1. Pylon searching. During this state it was assumed that the pylon was in the given view. However it would only move out of this state when the vision software successfully recognized a pylon. If no pylon was currently recognized our final design simply had the truck continue straight at a slower speed while giving the vision algorithm more passes to analyze the data.
2. Pylon following. During this state the truck would make simple steering adjustments in order to maintain the pylon x-coordinate plus the width of a pylon in the center of the truck. Bigger distances from the center of the screen would mean larger adjustments of the steering angle during this state. The truck would continue in this state until the distance from the pylon was calculated to be less the threshold set in the global parameters as the distance before the pylon to turn.
3. Setting up the turn. There were two hard coded states that depended only on the parameters set for the truck. These two steps including turning slightly away from the pylon in the opposite direction then needed to be turned around the pylon and then driving straight a set distance in order to line up with the pylon nearly perpendicular from the line at which it was driving towards the pylon. If the vision consistently gave accurate values for the distance of the pylon these state worked perfectly every time. We assumed during this state that we would lose site of the pylon and we therefore did not use any of the vision calculations while in these states.
4. Dead-Reckoning turn around the pylon. Upon entering this state we simply saved the current Encoder value plus the number of ticks we needed to travel to complete the turn. This extra number of ticks was calculated by the angle given in the course description. When we approached a pylon of the same color as the previous pylon we added an extra 10 degrees to every turn due to the manner that we were entering the turns from an angle slightly less the perpendicular to the line straight from the previous pylon. When the truck approached a pylon of a different color then the previous pylon we added an extra 45 degrees to the turn in order to compensate for the fact that in this case the truck was crossing over the straight line between the two pylons and actually entered the turn much further back in the turn. The number of ticks per radian was set by a global parameter that we also could change through our gui. This variable of the ticks per radian needed to be adjusted when we tested new faster speeds navigating the course. When the calculated number of ticks had been completed the truck then moved back into the pylon searching state.

Full Chronological Review and other files

Here is a quick video of one of the more simpler pylon courses our truck was able to complete at the practice competition last week. The truck is only told the color of the next pylon, the truck then drives itself towards the closest pylon of that color, goes around it and then looks for the next pylon of the correct color. The on board camera and FPGA are doing all of the vision processing internally. Besides myself, Steven Hansen, there are 3 others on my project team: Brandon, Luke, and Jaren

As of today, Steven Hansen is a BYU undergrad in the Electrical Engineering program.  He is currently working on a fun project to design an automous race truck that can navigate around a swimming noodle pylon course.  He is planning to graduate in December of 2009 (this year!) with a B.S. in Electrical Engineering and minor degrees in Spanish, Mathematics, Physics, and Computer Science.

The main reason Steven Hansen has this blog is to give himself and other’s that might run accross this blog an archive of a few random things that would otherwise be hard to find.  It also has turned into a bit of an archive for school assignments and other little projects.  Once he is out of school this blog will probably turn into a record of my progress at work.

The only complaint Steven Hansen has with life are long lines or being required to park extraordinarily, excessively far from his classes at BYU.  It is hard to find anything else that is really in need of complaining about on a regular basis.

Here is a link to the Steven Hansen website.

The article, “Multicore Is Bad News For Supercomputers” published November 2008 in the IEEE Spectrum, introduced some interesting points that are very significant for the future of computers. The main motivation for this article is the fact that current processor engineers have been reaching what people feel are plateaus in the technology and the only way to increase processor performance further is to add more and more processors together. This article details on a high level the performance of computers as multiple cores are added to the same system. Adding additional cores to multi-core systems does not necessarily mean an enhancement in overall speed or processing power.

The article notes that adding more processors doesn’t speed up the process specifically for informatics processing requiring very large data processing with requiring large databases of information. For many circumstances like solving differential equations the calculation can be split up into “grids” so that the physical location of the multiple processors can handle the data in their corresponding grid, and so the multiple cores are able to perform separately and achieve faster results. Nevertheless, there are increasing instances that in data processing in large systems require data being processed from another core, creating dependencies that slow down the overall system. Adding more core processors only splits the process up more and creates more dependencies on other cores.

Another problem is that the multi-core is limited by the surrounding architecture and this traditional architecture standard that computer manufacturers have been implementing for years is not adequate for the large multi-core processors. There are significant bottlenecks in the memory, bus, and peripheral communication that create limits to the amount of data that the processors can actually receive, leaving the processors to waste time waiting for the data to arrive.

According to the sources cited in the article after about 8 multi-cores there is no significant increase in performance and it actually can level off or decrease depending on the situation. This has caused the government to form an organization to research and communicate with hardware developers to create new standards that can be followed in the next 5 to 10 years that will allow for a new breed of computers that can really utilize the power of multiple processing cores.

This article actually proves the point of staying on top of current news and information in technology. The only way advancements can really be made is if we are always on the cutting edge of technology increasing our boundaries and keeping up on the future. Without understanding the future of technology current development could leave out critical pieces that will only slow down the ever increasing pace and need for growth in all industries.

All it requires stay informed with the advances and issues is setting up a few methods of easily receiving new information. A few methods include: adding the IEEE spectrum feed to a frequented feed reader, reading the news of some favorite companies and industries, and continuing education both in traditional classroom methods and industry seminar style information sessions.

By Steven Hansen