uni

writeup.tex (19127B)

---

 \documentclass[a4paper,12pt]{article}
 
 \usepackage{tabularx}
 \usepackage{geometry} 
 \usepackage{pgfplots}
 \usepackage{titling} 
 \usepackage{titlesec}
 \usepackage[english]{babel} 
 \usepackage[hidelinks]{hyperref} 
 \usepackage{listings} 
 \usepackage{graphicx} 
 \usepackage{float}
 
 \graphicspath{ {./images} }
 
 \titleformat{\section} {\large\bfseries} {} {0em} {}[\titlerule] 
 \titleformat{\subsection} {\bfseries} {} {0em} {}[\titlerule] 
 \geometry{a4paper,total={170mm,257mm},left=25mm,right=25mm}
 \setlength{\parindent}{0pt}
 \setlength{\parskip}{10pt}
 
 \pgfplotsset{width=15cm,compat=1.9}
 
 \author{Lucas Standen} 
 \title{Robotics report}
 
 
 \begin{document} 
 \maketitle
 \newpage
 \section{How does the robot work?}
 I designed my system to repeatedly poll the sensors, and adjusting the motors based on the input, I made functions called \lstinline{stepMove} and \lstinline{stepTurn} which each moved or turned the robot a small amount. These function ran in a very short amount of time, allowing them to be called as often as possible, letting me read the sensors more often. This aloud me to make my robot react to changes, such as going off course or touching the barcode, a lot faster than if I halted the program while the robot moved. Thanks to this I didn't have to worry about distances or angles in my code, as I could tell the robot to keep moving until something happened.
 
 The sensors were polled by a function called \lstinline{getState}, which would be called as often as possible and updated the readings of the sensors in the robot, and updated the state of the motors depending on how long they had be turned on for. My step function worked by storing a time stamp of when they were called (using \lstinline{millis}), then every time the get state function was called, I could see if it had been over 19 milliseconds since the motors had been told to move, if it had been, I could turn them off. The reason I did this was to avoid the need to turn the motors off in my behaviour functions and line following functions, as having that in them, would have made them more complex than they needed to be.
 
 \subsection{What went well?}
 I was happy with the robots attraction and avoidance behaviours, they both worked very well, and were reliable. The LED state functioned as expected, flashing repeatedly, this worked in a similar way to the motors, checking when the last call was made to flash the LED, allowing the code to spend more time on the sensors readings than the state of the LED. 
 
 I was also happy with my use of a state \lstinline{struct} to hold all of the robots internal values, thanks to this my robot used almost no global variables. I declared it as \lstinline{static} inside of the \lstinline{getState} function, this meant that I could reassign the state variable in my \lstinline{loop} function, while not losing data, such as LED flash state.
 
 A final thing that I was proud of in my code was my debug macros, I wrote a macro that aloud entire code segments to be toggled, in a neat and clean way. I used this a lot over my code to get readings from all the sensors. It also is used to enable testing upon starting the robot.
 
 \subsection{What didn't go well?}
 
 I found my robot can sometimes get stuck while reading barcodes, if it did not enter them straight on, it would think that it needs to turn. This was partially fixed by adding an error correction, that would try to detect when this happened and turn in the opposite direction, to line the robot up with the barcode. This did help, however it still got stuck sometimes.
 
 \section{Comparing my code to the design brief}
 \noindent\begin{minipage}{\textwidth}
 \subsection{Working with Light Dependant Resistors}
 	When the robot starts up, and has been compiled with DEBUG enabled, it will start a testing program, this program will perform all tests on the LDRs. The code that does so is presented here. This code will read 10 values from each sensor and output the readings, it will also write the values to EEPROM. I think this code properly achieves the target of testing so I would say it is worth 70\% of the maximum mark for this section.
 
 \begin{verbatim}
 void
 testLDR()
 {
 	SEprintf("Testing LDRS\n");
 	for (int i = 0; i < 2; i++) {
 		SEprintf("Please turn on the lights, and place the robot 
 			  on a %s surface (press button A to continue)\n", colors[i]);
 
 		waitButton(BUTTONA, HIGH);
 		reading r = readSensorsMean(TESTREADINGS);
 
 		if (strcmp(colors[i], "black") == 0) {
 			EEPROM.put(6, (uint16_t)r.left + 100);
 			EEPROM.put(10,(uint16_t)r.mid + 100);
 			EEPROM.put(14, (uint16_t)r.right + 100);
 		} else {
 			EEPROM.put(4, (uint16_t)r.left);
 			EEPROM.put(8,(uint16_t)r.mid);
 			EEPROM.put(12, (uint16_t)r.right);
 		}
 
 		SEprintf("Test complete, please turn off the lights 
 			  (press button A to continue)\n");
 
 		waitButton(BUTTONA, HIGH);
 		readSensorsMean(TESTREADINGS);
 	}
 	SEprintf("finished testing LDRS, please check the values are expected 
 		  for lighting conditions\n");
 }
 
 \end{verbatim}
 \end{minipage}
 
 \begin{center}
 	\textit{These lines have been wrapped, so this code will not compile.}
 \end{center}
 
 Note the use of the \lstinline{SEprintf} function, this is one of many helper functions I made. It uses \lstinline{snprintf} from the C stdlib adn then prints it using the Arduino's \lstinline{Serial} class. This makes it equivalent to the C \lstinline{printf} function.
 
 \subsection{Light source following and obstacle detection}
 \noindent\begin{minipage}{\textwidth}
 To make the robot follow the line, I made a move function that checks the current state of the LDRs and will adjusts the course accordingly.
 
 \begin{verbatim}
 void
 move(state *s)
 {
 	/* small adjustments */
 	if (s->right && s->mid)
 		stepTurn(RGT, s);
 	else if (s->left && s->mid)
 		stepTurn(LFT, s);
 
 	/* large adjustments */
 	else if (s->right) {
 		s->prevDir = RGT;
 		stepTurn(RGT, s);
 	} else if (s->left) {
 		s->prevDir = LFT;
 		stepTurn(LFT, s);
 
 	/* drive straight, nominal */
 	} else if (s->mid) {
 		for (int i = 0; i < 20; i++)
 			stepMove(FWD, s);
 	} else {
 		/* try to recover from not being on the line by moving in the prevDir
 		   only updated on large turns */
 		while (!s->mid) {
 			s = getState();
 			stepTurn(s->prevDir,s);
 		}
 	}
 }
 \end{verbatim}
 \end{minipage}
 
 \noindent\begin{minipage}{\textwidth}
 	To make the robot stop and wait when an obstacle, I simply have this code at the top of my loop function, if an obstacle is seen, the code will just keep on going to the top of the loop function. The \lstinline{flash} function will cause the LED to flash.
 
 \begin{verbatim}
 void
 loop()
 {
 	state *s = getState();
 
 	/* do nothing while there is an obstacle */
 	while (isObstacle()) {
 		flash(YELLOW_LED, s);
 		return;
 	}
 	.... 
 \end{verbatim}
 \end{minipage}
 
 \noindent\begin{minipage}{\textwidth}
 	The barcode reading function compares the time that the robot was last on a barcode from the current time and if it is longer than a certain time, then a barcode has been passed.
 
 \begin{verbatim}
 void
 checkBarcode(state *s)
 {
 	long t = millis();
 	if (s->timeStamp > 500) {
 		/* long barcode */
 		if ((t - s->timeStamp) > 3000)
 			runBehave(&stepAvoidanceBehave);
 
 		/* short barcode */
 		else if ((t - s->timeStamp) > 800)
 			runBehave(&stepAttractionBehave);
 	}
 	s->timeStamp = t;
 }
 \end{verbatim}
 \end{minipage}
 
 \noindent\begin{minipage}{\textwidth}
 	The avoidance and attraction behaviours are both very similar, just having inverted directions, they work by comparing the raw values of the LDRs, meaning they should work in many light conditions.
 
 \begin{verbatim}
 void
 stepAvoidanceBehave(state *s)
 {
 	flash(RED_LED, s);
 	DBG({
 		/* WARNING this causes the program to stutter when left on,
 		     not too bad for debugging but very bad for general use! */
 		SEprintf("Avoid: %d, %d, %d\n", s->rawleft, s->rawmid, s->rawright);
 	});
 
 	/* left is noticably larger */
 	if (s->rawleft > s->rawright + 50)
 		stepTurn(RGT,s);
 	/* right is noticably larger */
 	else if (s->rawright > s->rawleft + 50)
 		stepTurn(LFT,s);
 	else
 		stepMove(FWD, s);
 }
 
 
 void
 stepAttractionBehave(state *s)
 {
 	flash(GREEN_LED, s);
 	DBG({
 		SEprintf("Attract: %d, %d, %d\n", s->rawleft, s->rawmid, s->rawright);
 	});
 
 	/* left is noticably larger */
 	if (s->rawleft > s->rawright + 50)
 		stepTurn(LFT,s);
 	/* right is noticably larger */
 	else if (s->rawright > s->rawleft +50)
 		stepTurn(RGT,s);
 	else
 		stepMove(FWD, s);
 }
 
 void
 runBehave(void (*stepBehave)(state *))
 {
 	while (true) {
 		state *s = getState();
 		stepBehave(s);
 	}
 }
 \end{verbatim}
 \end{minipage}
 
 For this section I believe my code was effective and defensive, I included debug statements, didn't rely on global variables and split my program into manageable functions. While testing I found it didn't always work perfectly on edge cases, like the robot coming onto the line from an angle, because of this I believe my code is worth 60\% of the total marks for this section.
 
 \noindent\begin{minipage}{\textwidth}
 \subsection{Robot states}
 	The robots states were handled through a \lstinline{flash} function that could cause any one LED to flash at a given point. The code was effective and worked nicely, however the \lstinline{flash} and \lstinline{getState} functions, have to be called very frequently to properly flash the LEDs. Due to this I believe this code is worth 65\% of the maximum mark for the section.
 
 \begin{verbatim}
 void
 flash(int pin, state *s)
 {
 	switch (pin) {
 	case GREEN_LED: s->gstate = millis(); break;
 	case YELLOW_LED: s->ystate = millis(); break;
 	case RED_LED: s->rstate = millis(); break;
 	}
 }
 
 void
 stepFlash(int pin)
 {
 	/* we define this a static to preserve its value across function calls */
 	static uint8_t flashCount;
 
 	if (flashCount < FLASHTIME)
 		digitalWrite(pin, HIGH);
 	else if (flashCount > FLASHTIME / 2)
 		digitalWrite(pin, LOW);
 
 	/* this value wraps which is by design, this will cause the flashing to reset */
 	flashCount++;
 }
 
 void
 updateFlash(state *s)
 {
 	/* turn off the leds if they arent ment to be on anymore */
 	if (millis() - s->gstate > FLASHTIME) {
 		s->gstate = 0;
 		digitalWrite(GREEN_LED, LOW);
 	} if (millis() - s->ystate > FLASHTIME) {
 		s->ystate = 0;
 		digitalWrite(YELLOW_LED, LOW);
 	} if (millis() - s->rstate > FLASHTIME) {
 		s->rstate = 0;
 		digitalWrite(RED_LED, LOW);
 	}
 
 	/* turn on the leds if needed */
 	if (s->gstate) stepFlash(GREEN_LED);
 	if (s->ystate) stepFlash(YELLOW_LED);
 	if (s->rstate) stepFlash(RED_LED);
 }
 \end{verbatim}
 \end{minipage}
 
 \subsection{EEPROM}
 \noindent\begin{minipage}{\textwidth}
 	My code only relied on the black calibration value, along with the motor values, so not all the values were read. I wrote a simple program called calibrate that could however fill all values, and perform simple calibration of the LDR's (although the \lstinline{testLDRs} function was more effective at finding proper values). I believe, as I achieved the brief of filling in all the values and reading them too, this code is worth 70\% of the available marks for this section.
 
 	\begin{center}
 		\textit{Code for reading values from EEPROM} 
 	\end{center}
 \begin{verbatim}
 ....
 
 /* let the user attach the battery, attaching the battery 
    while code is running caused strange behaviour */
 
 delay(3000);
 setupRobot();
 
 /* servo speed values */
 EEPROM.get(0, SERVOA_ZERO);
 EEPROM.get(1, SPEEDA);
 EEPROM.get(2, SERVOB_ZERO);
 EEPROM.get(3, SPEEDB);
 
 ....
 
 /* read the calibrated values that should be in EEPROM, 
    these values will be made by the calibrate program */
 
 EEPROM.get(6, LDRA_SWITCH);
 EEPROM.get(10, LDRB_SWITCH);
 EEPROM.get(14, LDRC_SWITCH);
 ....
 \end{verbatim}
 \end{minipage}
 \newpage
 \noindent\begin{minipage}{\textwidth}
 	\begin{center}
 		\textit{Code for setting default values into EEPROM} 
 	\end{center}
 \begin{verbatim}
 /* repeatedly changes calibration values for each ldr 
    until returning consistant data */
 
 while (isLDRBright(LDRA)) LDRA_SWITCH++;
 while (isLDRBright(LDRB)) LDRB_SWITCH++;
 while (isLDRBright(LDRC)) LDRC_SWITCH++;
 
 SEprintf("%d, %d, %d\n\n", LDRA_SWITCH + 100, 
 	 LDRB_SWITCH + 100, LDRC_SWITCH + 100);
 
 EEPROM.put(6, LDRA_SWITCH + 100);
 EEPROM.put(10, LDRB_SWITCH + 100);
 EEPROM.put(14, LDRB_SWITCH + 100);
 
 /* setting robots values, my robots values for fwd motion, and turns */
 
 EEPROM.put(0, (uint8_t)SERVOA_ZERO);
 EEPROM.put(1, (uint8_t)SPEEDA);
 EEPROM.put(2, (uint8_t)SERVOB_ZERO);
 EEPROM.put(3, (uint8_t)SPEEDB);
 \end{verbatim}
 \end{minipage}
 
 
 \section{Testing}
 \begin{table}[H]
 	\resizebox{\linewidth}{!}{
 		\begin{tabular}{|| l | p{0.6\linewidth} | p{0.4\linewidth} ||}
 			\hline
 			\textbf{Test} & \textbf{Method}  & \textbf{Result} \\
 			\hline 
 			\hline 
 			Push-button left & 
 			I made a function called \lstinline{testButton} repeatedly asks the user to press the button, counting how many times the program receives the button press, the user can compare this to how many times the button was pressed. &
 			Pass \\
 			\hline 
 			Push-button right & 
 			My \lstinline{testButton} function is requires an argument of the pin number, meaning a button on any pin could be tested. &
 			Pass \\
 			\hline
 			Servo left & 
 			I made a \lstinline{testServo} function, it spins the servo at its default speed for 10 seconds, the user can see if this acts as expected. &
 			Pass \\
 			\hline
 			Servo right & 
 			Like with the \lstinline{testButton} function, any value can be passed into this function, allow the user to test the other servo. &
 			Pass \\
 			\hline
 			IR transmitter \& receiver & 
 			I made a function called \lstinline{testIR} that expects the user to hold an item in front of the sensor and takes multiple readings, checking if the value outputted was consistent for more than 8 times out of 10. &
 			Pass \\
 			\hline
 			LDRs & 
 			I made a function called \lstinline{testLDRS} that asks the user to place the robot on different colours and in different lighting conditions, then takes many readings, the user can then compares these to expected values for the input. &	
 			Pass \\
 			\hline
 			\hline
 			Object avoidance &
 			To test the object avoidance, I simply used the robot repeatedly, in a variety of lighting conditions, and confirmed that the robot stops and that the orange LED turns on. I ran this test 10 times, with the object \~10cm away from the robot. &
 			8 / 10 Passed. 2 times resulted in robot entering attraction behaviour due to detecting shadow from object \\
 			\hline
 			Line following &
 			To test the line following, I placed the robot on the start of the line, and turned it on, I then saw if the robot was able to follow a straight black line. I repeated this 10 times. &
 			7 / 10 Passed. The robot sometimes has issues when travelling over barcodes if it doesn't go straight on, as this causes it to act as if it is on the line diagonally. \\
 			\hline
 			Barcode reading &
 			To test the barcode reading, I let the robot run over the 2 types of barcode 10 times each, and recorded how many times it was able to determine the correct type of barcode. For this test I repeated it if the robot failed to follow the line, as this was to test if the robot could read the barcode, not follow the line. &
 			9 / 10 Passed for long barcode.
 			8 / 10 Passed for short barcode.
 			All the times this test failed, was because the robot was detecting the other kind of barcode, this is most likely due to the reading being based on time since last line, causing a slow travel to detect as the long barcode, and vice versa. \\
 			\hline
 			Light attraction and avoidance &
 			To test the light attraction and avoidance, I modified my program to put the robot straight into these modes, I then used my phones flashlight to see if the robot did the expected behaviour. I repeated this 10 times for each behaviour and assessed it based on how well it worked. &
 			All 10 times were consistent for each behaviour, however I found while the robot was turning that it wasn't very smooth, I am not sure why this is, as turning in the line following behaviour was smooth, this did not effect its ability to move towards or away from the light. \\
 			\hline
 		\end{tabular}
 	}
 	\caption{\centering{\textit{All tests were performed in a well lit room, using lines and barcodes provided, unless otherwise stated}}}
 \end{table}
 
 \begin{center}
 \begin{tikzpicture}
 	\begin{axis}[
 			title=Graph showing LDR readings on a white background with the room bright,
 			ymin=0, ymax=600,
 		]
 		\addplot[
 			color=blue,
 			mark=square,
 		]
 		coordinates {
 			(0,223)
 			(1,226)
 			(2,225)
 			(3,215)
 			(4,233)
 			(5,270)
 			(6,304)
 			(7,321)
 			(8,323)
 			(9,308)
 		};
 		\addplot[
 			color=red,
 			mark=square,
 		]
 		coordinates {
 			(0,182)
 			(1,187)
 			(2,189)
 			(3,183)
 			(4,191)
 			(5,218)
 			(6,243)
 			(7,256)
 			(8,259)
 			(9,248)
 		};
 		\addplot[
 			color=green,
 			mark=square,
 		]
 		coordinates {
 			(0,214)
 			(1,219)
 			(2,220)
 			(3,217)
 			(4,228)
 			(5,255)
 			(6,278)
 			(7,290)
 			(8,290)
 			(9,292)
 		};
 		\legend{LDR A, LDR B, LDR C}
 	\end{axis}
 \end{tikzpicture}
 
 \begin{tikzpicture}
 	\begin{axis}[
 			title=Graph showing LDR readings on a white background with the room dark,
 			ymin=0, ymax=50,
 		]
 		\addplot[
 			color=blue,
 			mark=square,
 		]
 		coordinates {
 			(0,11)
 			(1,11)
 			(2,11)
 			(3,11)
 			(4,11)
 			(5,11)
 			(6,11)
 			(7,11)
 			(8,11)
 			(9,11)
 		};
 		\addplot[
 			color=red,
 			mark=square,
 		]
 		coordinates {
 			(0,15)
 			(1,14)
 			(2,14)
 			(3,15)
 			(4,15)
 			(5,15)
 			(6,16)
 			(7,15)
 			(8,15)
 			(9,15)
 		};
 		\addplot[
 			color=green,
 			mark=square,
 		]
 		coordinates {
 			(0,8)
 			(1,8)
 			(2,8)
 			(3,8)
 			(4,9)
 			(5,9)
 			(6,9)
 			(7,9)
 			(8,9)
 			(9,9)
 		};
 		\legend{LDR A, LDR B, LDR C}
 	\end{axis}
 \end{tikzpicture}
 
 \begin{tikzpicture}
 	\begin{axis}[
 			title=Graph showing LDR readings on a black background with the room bright,
 			ymin=0, ymax=200,
 		]
 		\addplot[
 			color=blue,
 			mark=square,
 		]
 		coordinates {
 			(0,110)
 			(1,108)
 			(2,102)
 			(3,101)
 			(4,105)
 			(5,112)
 			(6,118)
 			(7,119)
 			(8,114)
 			(9,104)
 		};
 		\addplot[
 			color=red,
 			mark=square,
 		]
 		coordinates {
 			(0,77)
 			(1,89)
 			(2,86)
 			(3,86)
 			(4,93)
 			(5,99)
 			(6,104)
 			(7,105)
 			(8,99)
 			(9,90)
 
 		};
 		\addplot[
 			color=green,
 			mark=square,
 		]
 		coordinates {
 			(0,88)
 			(1,101)
 			(2,99)
 			(3,99)
 			(4,105)
 			(5,111)
 			(6,116)
 			(7,116)
 			(8,111)
 			(9,103)
 		};
 		\legend{LDR A, LDR B, LDR C}
 	\end{axis}
 \end{tikzpicture}
 
 \begin{tikzpicture}
 	\begin{axis}[
 			title=Graph showing LDR readings on a black background with the room dark,
 			ymin=0, ymax=10,
 		]
 		\addplot[
 			color=blue,
 			mark=square,
 		]
 		coordinates {
 			(0,1)
 			(1,1)
 			(2,1)
 			(3,1)
 			(4,1)
 			(5,1)
 			(6,1)
 			(7,1)
 			(8,1)
 			(9,1)
 
 		};
 		\addplot[
 			color=red,
 			mark=square,
 		]
 		coordinates {
 			(0,2)
 			(1,2)
 			(2,2)
 			(3,2)
 			(4,2)
 			(5,2)
 			(6,2)
 			(7,2)
 			(8,2)
 			(9,2)
 		};
 		\addplot[
 			color=green,
 			mark=square,
 		]
 		coordinates {
 			(0,0)
 			(1,0)
 			(2,0)
 			(3,0)
 			(4,0)
 			(5,0)
 			(6,0)
 			(7,0)
 			(8,0)
 			(9,0)
 		};
 		\legend{LDR A, LDR B, LDR C}
 	\end{axis}
 \end{tikzpicture}
 \end{center}
 
 
 \end{document}