NIOS II Software

           The purpose of the Nios II software was to perform complete robot control.  In other words, it was responsible for reviewing data generated by the hardware as well as data sent by the robot in order to determine how to move the robot in order to get to a specified target.  On startup of the program, a target location for the robot to move can be set by the user.  Once the location is set, a command can be issued that will start the Nios II controlling the robot.  The program will end and wait for another target location after the Nios II has determined that the robot has reached the target.
            This section of the project was basically accomplished through trial and error.  The key function to this part of the code is getMedians.  After several test runs with the robot, we realized that the distance values being reported by the hardware varied, sometimes greatly.  This can possibly be explained by varying room conditions and changes in the speed of sound.  It also could be caused by variation in the Nios II processing, which seems to happen more frequently than we would like.  To rectify this problem, the getMedians function is designed to collect a certain number of distance samples.  It orders these samples from low to high.  It then takes the middle samples and performs an average on them.  The median average values are then returned to the main processing loop as the actual distance values.  In our current setup, the getMedians function is designed to take 20 samples and take the average of the 4 middle values.
            Another important function in the Nios II software was the faceNios function.  In order to get a good sound reading, it is necessary for the robot to be facing the FPGA board.  Otherwise sound reflections interfere, and the sound reading is unpredictable (which makes it impossible to get an accurate distance value and find the robot location).  The faceNios function causes the robot to turn in place by a small amount sending pings back to the FPGA.  If the distance value corresponding to a ping gets larger, it is known that the robot is turning the wrong direction.  Its direction is switched, and it continues searching for the FPGA.  After the robot turns a second time, it is known that it is close to facing the FPGA.  It therefore performs the distance comparisons to find the FPGA one more time.   Once it determines that the distance values are once again getting larger it stops turning.  At this point it turns back by one turn and returns from the function.  The calling function can then assume that the robot is facing the FPGA board.
            The calTurn function performs similarly to the faceNios function.  The purpose of this function is to determine the amount of time for the robot to turn 360 degrees.  All turn amounts are then based off this value.  The robot is told to drive in a circle.  After about ¾ of the circle, the robot begins pinging in order to find the FPGA.  Once it is again facing the FPGA, it returns the amount of time that it calculated to perform the circle.
            The main function of the Nios II software was designed to determine the robot’s location and move the robot toward the specified target.  On entering the main loop of the function, the user is asked to choose a target location for the robot to move towards. This is done by entering commands into the console.  The target location in respect to the FPGA is shown on the VGA monitor.
            After a target is selected, the code begins by having the robot face the Nios.  On the first time through (or after a certain number of robot moves), the calTurn function is also called.  This gives the robot a time basis for making turns.  Once the robot is facing the Nios, a distance reading is taken.  An angle and Cartesian coordinates are then calculated by the hardware based on the conditioned distance values from the Nios II software.  The robot’s location is drawn on the screen based on the Cartesian coordinates.
            Using the Cartesian coordinates, the distance to the target value is calculated.  If the robot is found to be close to the target in both the x and y directions, a done signal is set.  Once this occurs, the robot stops moving and the user is allowed to set a new target location.  If the robot is not near the target location, it uses its current angle in respect to the Nios II in order to decide how to move toward the target.  It is setup to turn the least amount as possible and to always turn in such a way that it is easy for the robot to once again find the Nios.  The code is also designed such that the farther away the robot is from the target the longer it will move.   Upon moving the robot, a variable is set such to tell the system that it has not yet reached the target.  This process continues until the robot reaches the target.
The most difficult function to write was the getAlcohol function.  This function gets the alcohol level being seen from the robot.  Although this function was simple to understand, we ran into complications using the receiver of the Nios II UART.  The Nios II UART receiver is very unpredictable in that it doesn’t always register receiving values.  In order to rectify this problem, we used a handshaking mechanism between the robot and the Nios II software.  When the Nios II finally receives an alcohol reading from the robot, it sends a ‘G’ to tell the robot that the value was received.  The robot continues to send the alcohol value until the ‘G’ is received.  While this should not be necessary, we found that it solved the problem that was occurring and allowed us to continue working on other matters with the system.

For further detail regarding the Nios II software please refer to Appendix H. 

Atmega32 Software

The code on the AVR is responsible for 4 tasks:

• Sensor Collection
• Motor Control
• Producing Pings
• Communicating with NIOS II

Producing the Pings, Motor Control, and Sensor Collection is all handled by the microcontroller peripherals. The only time they are changed is when a command to do so is received from the NIOS. The firmware spends most of its time blocking, waiting to receive a packet from the NIOS. Once it gets one, it runs through a switch statement to perform the necessary actions.

Due to problems with the NIOS, when reporting the alcohol level the AVR needs to keep sending the data until it receives a confirmation packet from the NIOS.