00:28 < Rowan> im not entirly sure what i should be writing about. i never had a specific role ... just sorta butterflied around
00:29 < Rowan> learnt a huge amount although havnt done any work that has been needed or used in any final product.
+09:36 < jtanx> I added in some wiki pages last night, about the operating system, required packages and a special mention on pwm control
+09:39 < jtanx> hey
+09:39 < sam_moore> Hi, have to leave for bus now
+09:39 < jtanx> okay
+09:58 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
+16:42 < Rowan> still not entirely sure what i can be helping with. james says hes done with the gui part. should i just ignore him and start again with it mayself
+18:54 < sam_moore> Rowan: James has covered stuff like the design process and library selection etc
+18:55 < sam_moore> It would probably be good to discuss how the GUI is actually meant to work, how people are supposed to use it
+18:55 < sam_moore> Things like: There is a menu bar to go between different pages
+18:55 < sam_moore> List each page and give an overview of what it does
+18:55 < sam_moore> I suggest you have a look at github for the MCTXWeb testing GUI as it is the most complete
+18:55 < sam_moore> And we were using it this week and showing it to Adrian
+18:56 < sam_moore> So, I suggest you read James' section first, then just cover anything you think he's missed
+18:58 < sam_moore> jtanx: The report is looking good, I'm going to add your and my sections last
+18:58 < jtanx> Okay, that's fine
+18:58 < jtanx> Sorry for leaving so abruptly
+18:58 < sam_moore> There is a lot of stuff I can potentially write about, so I think the best idea is to just put all the other stuff in and then work around it
+18:58 < sam_moore> That's OK
+18:58 < sam_moore> Nothing really got done
+18:59 < jtanx> Sure
+18:59 < sam_moore> I ended up getting a bit pissed off with the other teams :S
+18:59 < jtanx> :/
+18:59 < sam_moore> They wanted to test the dilatometer...
+18:59 < sam_moore> And the pressure sensors...
+18:59 < sam_moore> And the microphones...
+18:59 < jtanx> did any of that get tested?
+18:59 < sam_moore> And the can wasn't holding pressure...
+18:59 < sam_moore> Nope
+18:59 < sam_moore> You know how it is
+18:59 < sam_moore> They needed to refocus the dilatometer...
+18:59 < sam_moore> So then someone says "While they do that, we'll test the pressure sensors"
+18:59 < sam_moore> Then everyone gets distracted...
+18:59 < jtanx> ....
+19:00 < sam_moore> Then that gets delayed somehow...
+19:00 < sam_moore> Then the people say "We focused the dilatometer!"
+19:00 < sam_moore> And you try and go back to doing that...
+19:00 < sam_moore> Then someone says "Are we testing the pressure sensors"
+19:00 < jtanx> -.-
+19:00 < sam_moore> And you go, "Well, since the dilatometer isn't working, we'll go back to that!"
+19:01 < sam_moore> Then someone says "What if you just do this little thing to the dilatometer..."
+19:01 < sam_moore> Blergh
+19:01 < jtanx> that sounds stupid
+19:01 < sam_moore> I think that edge detection was really the wrong way to do that dilatometer algorithm
+19:01 < sam_moore> Looking at the images...
+19:02 < sam_moore> It'd be far more reliable to just locate the change between dark and light pixels directly
+19:02 < sam_moore> But either way
+19:02 < jtanx> Yeah, now that I think about it,that'd make more sense
+19:02 < jtanx> would reduce cpu usage too
+19:02 < sam_moore> There are all these creative ways people kept coming up with
+19:02 < sam_moore> That basically boil down to
+19:02 < sam_moore> Making a different image
+19:02 < sam_moore> And then processing that
+19:03 < sam_moore> When really... you should just look at how to process the image you already have
+19:03 < jtanx> Yeah
+19:03 < sam_moore> Kieran's mathematica image thing looks horrendously complicated to analyse
+19:03 < jtanx> Really trying to complicate something that sholdn't be
+19:03 < jtanx> Ah... Kieran
+19:04 < jtanx> Seems to always come up with overly complicated plans
+19:04 < sam_moore> I said "If you can make an algorithm that will take whatever you want to do and spit out a number, we can put it in the software"
+19:04 < sam_moore> "If you come up with an algorithm that says "Make an image and then quantify it somehow" it will not work"
+19:04 < jtanx> Yeah
+19:05 < sam_moore> Unrelated, but about the whole "strain sensors aren't used on the exploding can but get shown in the gui"
+19:06 < sam_moore> I say it doesn't matter
+19:06 < sam_moore> They don't have to plot those sensors
+19:06 < sam_moore> Just put it in the documentation. When you use the exploding can, these sensors are effectively meaningless.
+19:06 < jtanx> Yeah
+19:06 < jtanx> that's fine too
+19:07 < jtanx> future work, if they run out of other things to do
+19:07 < sam_moore> Yeah, but even in future work I wouldn't really want to deal with that issue
+19:07 < sam_moore> It makes the system less flexible to have to specify the sensors you want to appear in the API
+19:07 < jtanx> I guess
+19:07 < sam_moore> Perhaps do it in the GUI
+19:07 < jtanx> perhaps
+19:08 < sam_moore> There's no harm in the server allowing those API requests
+19:08 < sam_moore> But you can hide unused things in the GUI
+19:08 < sam_moore> Enough of that
+19:08 < sam_moore> To the report
+19:08 < sam_moore> Currently adding James' stuff, it seems to fit well
+19:08 < jtanx> That's good
+19:09 < jtanx> do we need more references or something
+19:09 < sam_moore> I've largely abandoned the idea of a chapter of what the system is vs a chapter of the design considerations
+19:09 < sam_moore> Just discuss things as they come up
+19:09 < jtanx> Okay
+19:09 < jtanx> fair enough
+19:10 < sam_moore> References might be good
+19:10 < sam_moore> I suppose for things like the binary search you can reference a wikipedia page on it?
+19:10 < sam_moore> Or for things like "What a thread is"
+19:10 < jtanx> with software it's a bit hard
+19:11 < sam_moore> Yeah, even if you use a known algorithm it still gets dramatically altered based on what you want to do with it
+19:11 < jtanx> Yeah
+19:11 < sam_moore> Rowan: If you are still here, a glossary of terms is also potentially useful
+19:11 < sam_moore> I think we have one in the wiki?
+19:11 < jtanx> But realistically, what sort of 'formal' references are there for software
+19:11 < sam_moore> Stack overflow?
+19:11 < jtanx> the wiki has a glossary, but it could be expanded
+19:12 < jtanx> stack overflow as a formal reference?
+19:12 < sam_moore> Haha
+19:12 < sam_moore> Reference any library we use
+19:12 < sam_moore> They aren't formal though
+19:12 < jtanx> It'll have to be good enough
+19:12 < sam_moore> Look, we didn't use any formal academic references
+19:12 < sam_moore> So we can't reference them
+19:13 < jtanx> Yeah
+19:13 < sam_moore> Computer Science papers would be next to useless on this anyway
+19:13 < jtanx> pretty much
+19:13 < sam_moore> Unless you can find the original paper on things like binary searches
+19:13 < jtanx> ugh
+19:13 < sam_moore> Or whoever first coined the term "thread"
+19:13 < sam_moore> Digging through papers from the 1970s/80s ...
+19:13 < jtanx> pretty sure, binary search is like common knowledge in computing by now
+19:13 < sam_moore> It is taught in first year
+19:14 < sam_moore> It is probably one of the few things that is taught at UWA that was employed in this project...
+19:14 < jtanx> Okay, so lets reference CITS1210
+19:14 < sam_moore> Ahahaha
+19:14 < jtanx> I think it was acceptable
+19:14 < jtanx> reference material from previous units
+19:14 < sam_moore> yes, do that
+19:14 < sam_moore> I can reference my honours course on multithreading :P
+19:14 < jtanx> yeah
+19:14 < jtanx> that's good :P
+19:16 < sam_moore> Rowan: I said some stuff earlier, you may need to scroll back to see it if your IRC client doesn't notify you
+19:18 < sam_moore> jtanx: Should we make "Read the IRC chatlogs" a recommendation? :P
+19:18 < jtanx> Yeah, it would be helpful I guess
+19:18 < jtanx> lots of text to scrawl through though
+19:18 < jtanx> "Read IRC chatlogs" and "commit history" of git repository
+19:18 < sam_moore> If you look though you can find design discussions
+19:18 < sam_moore> Even some links to things
+19:19 < sam_moore> The git commit history also has some design changes
+19:19 < sam_moore> Eg if someone were considering using SQlite...
+19:19 < sam_moore> I think I put the performance tests in testing
+19:20 < sam_moore> But if they ignored those, there is code that uses SQlite which could be helpful
+19:20 < Rowan> yep just finished reading through it .. ill put together some stuff after i shower :\
+19:20 < sam_moore> Ok, thanks
+19:20 < jtanx> You'd have to go back to the very first commits to see the sqlite code afaik
+19:21 < jtanx> but yeah, since we ran a full blown mysql server on it...
+19:23 < Rowan> did you guys learn all this over this sem. or was it by part from databases and cits1210?
+19:24 < Rowan> and other units..
+19:24 < sam_moore> I knew very little about databases before this project
+19:24 < jtanx> um
+19:24 < jtanx> I'd say most of it was from my own learning
+19:24 < sam_moore> I know a reasonable amount about pthreads due to a course I did last year which involved much more complicated stuff than this
+19:25 < jtanx> databases didn't really help...
+19:25 < sam_moore> Well no
+19:25 < jtanx> bah that unit was shit
+19:25 < sam_moore> I never did Databases
+19:25 < Rowan> i though sqlite and cgi stuff was covered in the database unit?
+19:25 < jtanx> sqlite yeah, cgi no
+19:26 < sam_moore> I've used CGI before, but not that much
+19:26 < sam_moore> When I tested it I realised it would be an absolute pain to synchronise everything
+19:26 < jtanx> pretty much all of the web stuff for this unit, I learnt during this course
+19:26 < sam_moore> I've done low level network programming as a hobby
+19:26 < sam_moore> So I was going to write a custom HTTP server
+19:26 < sam_moore> But fortunately Jeremy found FastCGI
+19:26 < sam_moore> Which I'd never heard of
+19:26 < Rowan> yeha
+19:26 < sam_moore> So there is a lot of stuff I've learned I would say
+19:27 < Rowan> i really gotta learn more of this. i hated this unis cos ive been so pathetically useless ...
+19:27 < Rowan> ive learnt heaps aswell
+19:27 < Rowan> but no where near enough
+19:27 < Rowan> what was your multithreading honours thing you mentioned?
+19:28 < sam_moore> That was for Physics
+19:29 < sam_moore> Parallel Programming
+19:29 < jtanx> you should have used f# :P
+19:29 < sam_moore> We didn't cover f# since I suspect it is not great for low level type stuff
+19:30 < jtanx> I guess not, but apparently functional code is really good for parallelisation
+19:31 < sam_moore> Maybe...
+19:31 < sam_moore> Well, OpenMP is much nicer than pthreads in a lot of cases
+19:31 < sam_moore> It's really simple to make things parallelised
+19:31 < jtanx> have you heard of multithreading without locks
+19:31 < sam_moore> But it's terrible for communicating between threads
+19:32 < sam_moore> Great for doing something like a for loop where each thread calculates part of an array
+19:32 < Rowan> -----> should we have general info about the BBB in the glossary?
+19:32 < sam_moore> That might be useful
+19:33 < sam_moore> We are probably going to go over the 30 pages
+19:33 < jtanx> well
+19:33 < jtanx> lsat I heard, weren't sensors at ~50 pages
+19:33 < sam_moore> Yeah
+19:33 < sam_moore> Write all the things
+19:33 < sam_moore> If people are free tomorrow we will have to have a group meeting if we are over 30 pages
+19:33 < sam_moore> But...
+19:34 < sam_moore> Even though LaTeX uses a large amount of space by default
+19:34 < sam_moore> It can also be tweaked...
+19:34 < sam_moore> Definitely going with 10 point font
+19:34 < jtanx> sounds like a plan
+19:36 < sam_moore> jtanx: OpenMP has a lot of implicit locks by the way
+19:36 < Rowan> im not able to come in tomorrow though. . . i need to stop doing unit i need to be present for.
+19:36 < sam_moore> Which is why it's easy to do stuff with
+19:36 < jtanx> um
+19:36 < jtanx> doesn't rowan have to sign the coversheet
+19:36 < sam_moore> Yeahhhh
+19:37 < sam_moore> We could get a "digital" signature?
+19:37 < jtanx> maybe
+19:37 < sam_moore> One of my friends got a digital signature from their honours supervisor...
+19:37 < jtanx> hahaha
+19:37 < sam_moore> It was a png file containing their signature
+19:37 < jtanx> that could work
+19:38 < jtanx> there's a digital copy of the cover sheet somewhere
+19:38 < jtanx> I figured out why the wiki git repository wasn't cloning properly
+19:38 < jtanx> you can't have colons (:) in the filename on windows
+19:38 < sam_moore> Ahaha
+19:38 < jtanx> :/
+19:39 < sam_moore> Having two people that know linux already is really good for this project by the way...
+19:39 < jtanx> Yeah
+19:39 < sam_moore> I suspect someone who hadn't used linux before would have serious difficulties...
+19:40 < jtanx> ahh yeah that would be a problem
+19:41 < sam_moore> Dinner time
+19:41 < jtanx> Okay
+19:43 < jtanx> aha
+19:43 < jtanx> you can push to the wiki repository
+20:19 < sam_moore> Hmm
+20:20 < sam_moore> Could you push non plain text files to the wiki repository
+20:20 < jtanx> yep
+20:20 < jtanx> I pushed some images
+20:20 < sam_moore> It would be a good way to organise all documentation
+20:20 < jtanx> so all the images reside in the wiki repo
+20:20 < sam_moore> That's good
+20:20 < jtanx> well all of mine
+20:20 < jtanx> I should convert all of those imgur links
+20:20 < sam_moore> We could have put all the documentation and report cruft in the wiki repo!
+20:21 < sam_moore> Oh well, that's good to know for next time I use GitHub for something
+20:21 < jtanx> except half the stuff won't show up on my computer, with them fancy colons
+20:21 < sam_moore> Haha
+20:21 < sam_moore> No problem for me :P
+20:21 < sam_moore> Join us...
+20:21 < jtanx> bah
+20:21 < sam_moore> Any problem can be solved with sufficient use of `apt-get install`
+20:22 < jtanx> I don't think it would be a good idea to put all documentation on the project wiki
+20:22 < sam_moore> Oh?
+20:22 < jtanx> because github doesn't provide the same overview
+20:22 < sam_moore> Hmm
+20:22 < jtanx> you know how you can see the commit history and stuff for a normal repo
+20:22 < sam_moore> Yeah
+20:22 < jtanx> it doesn't have the same thing
+20:22 < sam_moore> But you can do that for the wiki if you clone it as a normal repo...
+20:22 < sam_moore> And...
+20:23 < jtanx> yeah
+20:23 < sam_moore> You can make post commit hooks for repos...
+20:23 < jtanx> but you can't visualise it as easy on github
+20:23 < sam_moore> Alright, fair enough
+20:23 < jtanx> oh right
+20:23 < sam_moore> It might be possible to hack together post commit hooks to have the wiki and an overview of other files in it
+20:24 < jtanx> quite possibly yeah
+20:24 < jtanx> but that's a hack
+20:24 < sam_moore> It might be a better suggestion for GitHub to start adding features for repos that aren't just for coding purposes
+20:24 < jtanx> hmm
+20:25 < sam_moore> Depending on how good the markup language is, you could probably do a report through GitHub entirely
+20:25 < jtanx> quite possibly
+20:25 < jtanx> with github you can have your choice of markup language
+20:25 < sam_moore> Of course, people's brains tend to shutdown when they have to use anything that isn't WYSIWYG
+20:26 < sam_moore> Which may explain why Labview is popular...
+20:26 < jtanx> huh
+20:26 < jtanx> I just realised
+20:26 < jtanx> When you set an image link
+20:26 < jtanx> and say it's imgur
+20:26 < jtanx> github caches it or something
+20:27 < sam_moore> ... Interesting
+20:27 < jtanx> so it appears as if it;s coming from github
+20:27 < sam_moore> I'd still put the images in the wiki repo
+20:27 < jtanx> yeah
+20:27 < jtanx> ...just that there are /so many/ images to convert
+20:28 < jtanx> right
+20:28 < jtanx> time to get out notepad++
+20:28 < sam_moore> I didn't mean you should actually convert all the images...
+20:29 < sam_moore> Just in future it's probably better to do it that way
+20:29 < sam_moore> Our whole repo should be structured more cleanly
+20:30 < sam_moore> Seperate branches probably
+20:30 < sam_moore> Store some install scripts in the master branch that will pull from the other branches...
+20:31 < jtanx> hmm
+20:31 < jtanx> I think I heard that you could have a git repository
+20:31 < jtanx> that links others
+20:31 < sam_moore> That could also work, branches are nice though
+20:31 < jtanx> yeah
+20:31 < sam_moore> git pull <source> server
+20:31 < sam_moore> or `git pull <source> website
+20:31 < sam_moore> etc
+20:32 < jtanx> sounds googd
+20:44 < jtanx> the pressure signal from the regulator was never used
+20:44 < jtanx> right?
+20:54 < sam_moore> Nope, but it could be in future work
+20:54 < sam_moore> Eg: This afternoon
+20:54 < jtanx> haha,okay
+20:54 < sam_moore> The pressure regulator was taking a very long time to reach the values specified
+20:54 < sam_moore> Although
+20:55 < sam_moore> I suspect that might be to do with the fact that Omid had the mains pressure turned down ridiculously low
+20:55 < jtanx> hmm
+20:55 < sam_moore> Like, the higher the mains pressure, the faster the pressure increases when the regulator is active, so the less time it has to wait
+20:56 < sam_moore> I guess it just vents air when it's over pressurized and uses PID
+20:56 < jtanx> most likely
+20:57 < sam_moore> But yeah, there were a lot of times when the mains pressure was cut completely for some reason and the regulator was struggling to set the pressure :S
+20:57 < jtanx> Yeah
+20:57 < jtanx> didn't sound healthy
+20:57 < sam_moore> Even when it was set to zero it would do it though
+20:57 < jtanx> I like how we're so careless with what, $800 equipment
+20:58 < sam_moore> Haha
+20:58 < sam_moore> Apparently the strain gauge circuit is now behaving fine...
+20:58 < sam_moore> the suggestion of testing them was raised...
+20:58 < sam_moore> But that was before I got angry and said "I still have to collate our report and it's 5pm!"
+20:58 < jtanx> Yep
+20:59 < jtanx> A bit too late for that
+20:59 < sam_moore> And if we broke the BeagleBone at 5pm on the second last day of semester...
+20:59 < sam_moore> So much shitstorm
+20:59 < sam_moore> I should have let someone else tell Adrian that snoopy got killed :S
+20:59 < sam_moore> He asked me all these questions about why it happened!
+20:59 < jtanx> :/
+21:00 < sam_moore> "Electronics designed the circuit, I don't know!"
+21:00 < sam_moore> "Don't fingerpoint!"
+21:00 < sam_moore> :S
+21:00 < jtanx> that was stupid
+21:00 < sam_moore> It's fair enough I guess
+21:00 < jtanx> I guess
+21:00 < sam_moore> We should have stopped the testing as soon as that reset button went wierd
+21:01 < jtanx> yeah, well I blame not enough sleep
+21:01 < sam_moore> Yeah, 3 hours sleep the night before...
+21:01 < sam_moore> s/night/morning/ because technically it was the same day...
+21:01 < jtanx> :S
+21:02 < sam_moore> James' section is in the report
+21:02 < jtanx> Cool
+21:03 < sam_moore> 3 pages when put into 10 point font with the figures
+21:03 < sam_moore> Justin's is 6 pages with 10 point font though
+21:03 < jtanx> Okay
+21:04 < sam_moore> The stuff I currently have in my section is 6 pages with 3 pages of figures... but it is referencing figures that aren't included yet :S
+21:04 < sam_moore> Oh well, I'm not taking ownership of the report
+21:04 < jtanx> urp
+21:05 < sam_moore> I've put in exactly what James wrote with no changes
+21:05 < sam_moore> Except a spelling mistake I think
+21:05 < sam_moore> It's a good overview of the libraries to be fair
+21:06 < sam_moore> I really like how "dilatometer" is underlined by the spell checker in the powerpoint slide
+21:06 < sam_moore> Shows it's authentically done in power point
+21:07 < sam_moore> Rowan's sent me me stuff that has screen shots mostly of the "testing" GUI
+21:07 < sam_moore> That's good, because I wanted to put those in
+21:07 < jtanx> Which 'testing gui'
+21:07 < sam_moore> The one we actually used today
+21:08 < sam_moore> Well... some version of it
+21:08 < jtanx> Ah, right
+21:08 < sam_moore> I'm going to update some of the figures, eg: the graph page doesn't show a graph, which can easily be fixed
+21:09 < sam_moore> Annoyingly, all the references and citations are currently giving [?] and ??
+21:09 < sam_moore> Probably because I copied the template from the ENSC1001 report where I screwed up the references somehow
+21:13 < sam_moore> ... Actually using the write references file would be good...
+21:13 < jtanx> What's that?
+21:13 < sam_moore> s/write/right
+21:13 < sam_moore> references/refs.bib
+21:14 < jtanx> ohh right
+21:14 < jtanx> was that vim notation
+21:14 < sam_moore> The s/ yeah
+21:15 < sam_moore> It's for a regex replace
+21:15 < sam_moore> Oddly enough, I tend to use it in IRC more than in actual vim...
+21:15 < jtanx> ~.~
+21:15 < sam_moore> #ucc used to have a regex bot that would interpret it
+21:15 < sam_moore> And do the replace on the last line you said...
+21:15 < sam_moore> Then spit it back out
+21:15 < sam_moore> It got abused and then removed
+21:15 < jtanx> I can imagine...
+21:15 < sam_moore> s/.*/I AM TERRIBLE
+21:16 < sam_moore> Sorry, the reason it got abused
+21:16 < sam_moore> Was because it was the last line *anyone* said that matched the regex
+21:16 < sam_moore> Not just your own
+21:16 < jtanx> well, that could have been fixed
+21:16 < jtanx> but perl scripts... ugh
+21:16 < sam_moore> Probably
+21:17 < sam_moore> I think it might have been a python bot, but I'm not sure
+21:17 < jtanx> huh
+21:17 < jtanx> never heard of a python irc bot
+21:17 < sam_moore> I wrote a bash IRC bot...
+21:17 < sam_moore> It doesn't actually say anything
+21:17 < jtanx> then what does it do?
+21:18 < sam_moore> It reads the channel and pipes things to text to speech
+21:18 < sam_moore> It is amazing
+21:18 < jtanx> uhh
+21:18 < jtanx> whyyyyy
+21:18 < sam_moore> To use it you have to run irssi in screen and setup log files
+21:18 < sam_moore> The script itself periodically parses the log files...
+21:19 < sam_moore> Passes them through a regex to get rid of things that don't pronounce well (eg: 21:18 < sam_moore> becomes "sam moore says")
+21:19 < sam_moore> Then says them through festival
+21:19 < sam_moore> Best thing I ever did
+21:20 < jtanx> Riiiiight
+21:20 < jtanx> sounds useful....
+21:20 < jtanx> *cough*
+21:20 < sam_moore> Well it can be told to only say lines that include a regex
+21:20 < sam_moore> The idea being you go "clubroom: You over there, pick up that rubbish"
+21:20 < sam_moore> And it plays that over the clubroom speakers...
+21:21 < jtanx> that would be creepy
+21:21 < sam_moore> I gave it the closest sounding voice to GladOS that I could find
+21:22 < sam_moore> Which isn't very close, but it's very disconcerting
+21:22 < jtanx> ...
+21:29 < sam_moore> References are fixed
+21:30 < sam_moore> I always screw up the .bib file
+21:32 < sam_moore> I will admit, LaTeX is a very complicated way to produce a document :P
+21:32 < sam_moore> But it looks nice
+21:33 < jtanx> Yes, it is complicated
+21:34 < jtanx> But I'll admit that it does look nice too
+21:34 < jtanx> I definitely know it's better for stuff that involves a lot of equations and the like
+21:34 < sam_moore> Once you've had to include mathematical equations you start to appreciate it a lot more
+21:34 < sam_moore> I quite like it for figures though
+21:34 < sam_moore> \includeimage
+21:34 < sam_moore> You can change the image or whatever you like
+21:34 < sam_moore> Don't have to reimport it
+21:34 < jtanx> Yeah, using MS Word with equations is... not fun
+21:35 < sam_moore> Don't have to screw around with moving where the image is in the text...
+21:35 < sam_moore> If you actually want to have the image somewhere other than just the centre of the page though it could get painful
+21:35 < sam_moore> But why would you want that anyway
+21:35 < jtanx> It looks nice?
+21:36 < sam_moore> Well if you write the document in columns (lots of papers do), centre of page/centre of column is the same
+21:36 < sam_moore> It never looks nice to have a figure randomly to the side with the width of the text changing to fit it in...
+21:42 < sam_moore> Should I put in Rowan's stuff now or wait until tomorrow morning?
+21:42 < sam_moore> He said he wanted to change a lot of it
+21:42 < sam_moore> I'll do Callum's next
+21:42 < jtanx> Hmm
+21:43 < jtanx> Maybe just leave some space for it for now
+21:55 < sam_moore> We'll be pushing it...
+21:56 < sam_moore> Although we can maybe fit some figures in at the end of chapters
+21:56 < jtanx> Appendix?
+21:56 < jtanx> Urgh
+21:56 < sam_moore> Yeah, appendix everything :P
+21:57 < sam_moore> It won't get read, but it's important that the stuff we care about is in the report...
+21:57 < jtanx> :/
+21:57 < jtanx> I really wonder just how much they will understand, or care to understand
+21:58 < sam_moore> It doesn't matter to me, it's more about personal satisfaction of knowing everything is covered
+21:58 < sam_moore> Because I'm not going to remember this project in detail and I'd like to have a good report to be able to look at later :P
+21:59 < sam_moore> Or maybe I will remember the project in detail...
+21:59 < jtanx> Haha
+21:59 < jtanx> Well, I must say this has been the most interesting project that I've been involved in to date
+22:00 < sam_moore> It's pretty cool that we covered so many layers of software yeah
+22:00 < jtanx> Yeah, that was cool
+22:01 < jtanx> I don't really know what to say about the content side of this unit though
+22:01 < jtanx> I can't say I learnt that much
+22:01 < sam_moore> Well, as a result of the teaching, or the project?
+22:02 < jtanx> The teaching, I guess
+22:02 < sam_moore> I didn't really learn that much from the tutorials, although it would have been damn helpful if I did this unit *before* my honours project last year
+22:02 < jtanx> Well, I felt that a lot of material was covered, but so briefly that I didn't learn much
+22:02 < sam_moore> I pretty much made every single rookie mistake he went through in terms of signals/noise/data processing
+22:02 < jtanx> :P
+22:02 < jtanx> Well, you learn more by making mistakes
+22:03 < sam_moore> I was like "There's a fucking capacitor in the system and I don't know why!"
+22:03 < sam_moore> Well... now I think I know why at least
+22:03 < jtanx> Or so they say
+22:03 < jtanx> hahaha
+22:03 < sam_moore> I still don't know why having the DAC on a multiple of 50 was causing the ADC input to drop by exactly 100 channels...
+22:04 < jtanx> uhhhhh
+22:04 < sam_moore> The only explanation is that there was an invisible "if (dac % 50 == 0) adc -= 100;" somewhere...
+22:04 < jtanx> Was this for your honours project?
+22:04 < sam_moore> Yeah, I don't want to think about that again, too painful...
+22:05 < sam_moore> Yes
+22:05 < jtanx> Okay
+22:05 < sam_moore> Not an issue for us as far as I know
+22:05 < jtanx> filtering?
+22:05 < sam_moore> It was too regular though
+22:06 < sam_moore> It also only happened if the dac was stepping in 25 or something wierd
+22:06 < jtanx> Weird...
+22:06 < sam_moore> Great success...
+22:06 < sam_moore> I just got LaTeX to compile a reference inside the references section
+22:07 < jtanx> ....
+22:07 < sam_moore> So... normally to do references you go 'pdflatex; bibtex; pdflatex; pdflatex'
+22:07 < sam_moore> I have no idea why, you just have to do it
+22:07 < sam_moore> But if you put a \cite in the actual refs.bib file, that ends up as an undefined reference.
+22:07 < sam_moore> The solution
+22:08 < sam_moore> is 'pdflatex; bibtex; pdflatex; pdflatex; bibtex; pdflatex; pdflatex'
+22:08 < sam_moore> I do not know why pdflatex needs to be run 5 times...
+22:08 < jtanx> wtf
+22:08 < jtanx> yeah, like why do you need to run pdflatex twice in a row
+22:09 < sam_moore> Well I can try not doing that and see if it breaks it...
+22:09 < sam_moore> You need it at least once because bibtex takes your original output and magically links all the references
+22:09 < sam_moore> Not sure why twice...
+22:10 < sam_moore> Nope, you appear to need it twice :S
+22:10 < sam_moore> Do not question the power that is LaTeX
+22:11 < jtanx> LaTex seems quite esoteric
+22:12 < sam_moore> Apparently when Knuth dies the last version of tex released becomes the final version and any remaining bugs are classified as features...
+22:12 < sam_moore> Also the version number becomes \pi
+22:13 < jtanx> Hahaha
+22:13 < sam_moore> That could be quite a problem if Linus Torvalds had a similar will...
+22:18 < sam_moore> I'm sort of being a bit cunning about adding information to people's sections...
+22:18 < sam_moore> When they mention a library I add a reference to it
+22:18 < sam_moore> And then add a "note" section...
+22:18 < sam_moore> :S
+22:19 < jtanx> Good enough
+22:19 < sam_moore> I wonder if I should add references to filenames...
+22:20 < jtanx> as in, 'sensors.c'?
+22:20 < sam_moore> eg: Where Callum mentions "image.c" I could link that to the current version of image.c in GitHub?
+22:20 < sam_moore> Yeah, that
+22:20 < sam_moore> That could be good
+22:20 < jtanx> Yeah, that might be good
+22:21 < sam_moore> \href command
+22:23 < jtanx> Okay, just about made the wiki page for administration stuff
+22:29 < sam_moore> Cool
+22:29 < sam_moore> I think some of Callum's description is actually not implemented yet :S
+22:29 < jtanx> :/
+22:29 < sam_moore> I don't think dilatometer.c currently has a static variable
+22:29 < sam_moore> Oh wait, it might have...
+22:29 < sam_moore> Not sure
+22:29 < sam_moore> Oh well
+22:30 < jtanx> the dilatometer code is a bit of a mess right now...
+22:30 < sam_moore> I'm just happy it got written
+22:30 < jtanx> Yeah
+22:31 < sam_moore> Ok, that's it
+22:32 < sam_moore> I need to define a latex command to automatically reference files in our github
+22:32 < sam_moore> Because having \href{https://github.com/szmoore/MCTX3420/blob/master/server/image.c}{\emph{image.c}} everywhere is *really* painful
+22:32 < jtanx> Yeah...
+22:33 < jtanx> sort of like a macro
+22:33 < jtanx> ?
+22:34 < sam_moore> Pretty much
+22:34 < sam_moore> \newcommand{\gitref}[2]{\href{https://github.com/szmoore/MCTX3420/blob/master/#1/#2}{\emph{#2}}
+22:34 < sam_moore> Should work
+22:34 < jtanx> Okay
+22:37 < sam_moore> I think this description of the OpenCV stuff would have been more effectively conveyed with a flow chart and some notes...
+22:38 < sam_moore> First we call this function, then we call this function passing these arguments...
+22:38 < sam_moore> Is really hard to read
+22:38 < sam_moore> Probably harder than just reading the source code
+22:38 < jtanx> ... assuming the person knows how to read source code
+22:39 < sam_moore> I suppose
+22:40 < jtanx> I just realised something
+22:40 < jtanx> When you do 'force' on starting a new experiment
+22:40 < jtanx> I don't think the old files are deleted, just overwritten
+22:40 < jtanx> so if for some reason the sensors/actuators change
+22:41 < jtanx> there may be old files still present
+22:42 < sam_moore> File it as a bug under github
+22:42 < sam_moore> ...
+22:42 < sam_moore> Actually if we file everything that doesn't work as a bug...
+22:42 < sam_moore> Then we can go "Recommendations: See the bugs and open issues on github"
+22:42 < jtanx> that would be future work?
+22:42 < sam_moore> Yep
+22:42 < jtanx> yeah
+22:42 < jtanx> good idea
+22:43 < sam_moore> We could have been more rigorous with our use of the issues system on github
+22:43 < sam_moore> But oh well
+22:43 < jtanx> yeah
+22:43 < sam_moore> Issue: PWM doesn't work
+22:43 < sam_moore> springs to mind
+22:44 < sam_moore> Then we could have tracked exactly when/how it was fixed and all our notes...
+22:44 < jtanx> it doesn't?
+22:44 < jtanx> oh right
+22:44 < jtanx> yeah, that would have been handy
+22:44 < sam_moore> Nicer than the technical diary
+22:52 < sam_moore> Callum refers to himself in the first person a lot in his section
+22:52 < sam_moore> Even in a report written by a single author you're still meant to use "We"
+22:52 < jtanx> :/
+22:52 < sam_moore> In a report written by multiple authors...
+22:53 < sam_moore> Who the hell is "I" ?
+22:53 < sam_moore> Unless you say "This section was written by me, <insert name>" at the start of each section
+22:54 < jtanx> Even then, I think "I" is a bit too informal
+22:54 < sam_moore> Yes, I will ask him if it's OK to change it tomorrow
+22:54 < sam_moore> Haha
+22:54 < sam_moore> There's also a bit of implied finger pointing at the sensors team :P
+22:54 < jtanx> :p
+22:55 < sam_moore> "From the graphs"
+22:55 < sam_moore> What graphs...
+23:10 < sam_moore> Compiling other people's sections takes longer than I expected :S
+23:10 < sam_moore> It's mostly copy/paste
+23:10 < sam_moore> But I decided to use monospace wherever a function or variable is referred to inline...
+23:11 < jtanx> :S
+23:13 < sam_moore> Oh well, sleep is for the weak
+23:13 < sam_moore> It's coming together surprisingly well though
+23:13 < sam_moore> ...
+23:13 < jtanx> We're almost there...
+23:13 < sam_moore> I'll get to your bit and have to fit in 100 pages won't I :P
+23:13 < jtanx> Hopefully not :S
+23:29 < sam_moore> Approaching 27 pages...
+23:29 < sam_moore> I think my bit needs some rewriting
+23:30 < sam_moore> Oh, right, we have some basically empty chapters
+23:30 < sam_moore> ...
+23:30 < sam_moore> We don't need that chapter
+23:30 < sam_moore> Introduction, Design, Conclusions
+23:30 < sam_moore> Good enough
+23:31 < sam_moore> I'd have to edit people's work to make it fit in 4 chapters, and as well as being unfair, we also do not have that kind of time left
+23:33 < sam_moore> Have you covered everything you want to cover?
+23:33 < sam_moore> Either you or Rowan is next
+23:33 < sam_moore> To be assimilated
+23:34 < sam_moore> Into the master report
+23:34 < jtanx> I hope so
+23:37 < sam_moore> Right then, here I go
+--- Day changed Fri Nov 01 2013
+00:04 < jtanx> Alright, I think that's it for me today
+00:05 < jtanx> I'll go through it tomorrow if we need to edit anything...
+00:25 < sam_moore> ... 12 pages... :S
+00:58 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]"]
--- /dev/null
+\section*{Glossary}
+
+\begin{itemize}
+ \item {\bf Server} --- Refers to the MCTX3420 program that runs on the system and is responsible for controlling and querying hardware. ``Server'' is often also used to refer to a physical machine (computer or embedded device) that runs a Server program.
+ \item {\bf Client} --- Refers to a program running on a computer that isn't part of the system. This program provides the user with an interface to the system; it will send commands and queries to the server as directed by a human user. ``Client'' is also often also used to refer to a physical machine that runs a Client program.
+ \item {\bf HTTP} --- Hyper Text Transfer Protocol - The protocol used by web browsers and web servers to exchange information. A "web" server is technically called a HTTP server. A "web" client is something like a web browser (firefox, chrome, etc) which uses HTTP to query servers on the internet.
+ \item {\bf HTTPS} --- HTTP itself involves sending plain text over a network, which can be intercepted and read by anyone on the network. The HTTPS protocol provides a layer of encryption to prevent eavesdropping on HTTP traffic.
+ \item {\bf API} --- Application Programming Interface - A standard defined for programs to interact with each other. In our case, the "Server API" (discussed on this page) defines what the Client can request and give to the Server.
+ \item {\bf HTML} --- Hypertext Markup Language - A language used by web browsers to display web pages. Static. HTML files are stored on a system that is running a HTTP server and transferred to web browsers when they are requested.
+ \item {\bf JavaScript} (not to be confused with Java) --- A language that is interpreted by a web browser to produce HTML dynamically (which is then rendered by the browser) in response to events. It can also direct the browser to send HTTP queries (AJAX). The response can be interpreted by the JavaScript. JavaScript files are also stored on the server.
+ \item {\bf JSON} --- JavaScript Object Notation - Text that can be directly interpreted as an Object in JavaScript.
+ \item {\bf CGI} --- Common Gateway Interface - Protocol by which HTTP servers respond to requests by calling an external (seperate) program. The CGI program does not run continuously.
+ \item {\bf FastCGI} --- Fast Common Gateway Interface - Protocol by which HTTP servers respond to requests by passing them to an external (separate) program. Differs from CGI because the external program runs continuously and separately from the HTTP server.
+ \item {\bf IP Address} --- Internet Protocol Address - Identifies a device on a network
+ \item {\bf Hostname} --- A human readable name of a device on a network. The hostname of the device is associated with its IP address.
+ \item {\bf Multithreading} --- A technique by which a single set of code can be used by several processors at different stages of execution.
+ \item {\bf OpenCV} --- A real time Image processing library
+ \item {\bf BBB} --- the BeagleBone Black, ARM processor board acts as the client, and communicates with the server to send and request data for physically running the experiment.
+ \item {\bf nginx} --- Used for website architecture which integrates efficiency with functionality
+ \item {\bf OpenMP} --- Multiplatform memory processing: used for parallel tasks (not used in this project)
+ \item {\bf PThreads (POSIX Threads)} --- A library used for thread management defining a set of c programing functions and constants.
+\end{itemize}
-\chapter{Design Implementation}
+\chapter{Design and Implementation}
-Figure \ref{} shows the earliest high level design of the software for the system created in the first week of the project. At this stage the options were kept open for specific implementation details. The early design essentially required software to be written for three devices; a client computer (GUI), an experiment server (control over access to the system, interface to the GUI, image processing) and an embedded device (controlling experiment hardware).
+% BEGIN Sam's section
+Figures \ref{block_diagram1.png} and \ref{block_diagram_final.png}shows the earliest high level design of the software for the system created in the first and last week of the project. In the early stages the options were kept open for specific implementation details. The early design essentially required software to be written for three devices; a client computer (GUI), an experiment server (control over access to the system, interface to the GUI, image processing) and an embedded device (controlling experiment hardware).
-Figure \ref{} shows the revised diagram at the time of writing this report. To remove an extra layer of complexity it was decided to use a single device (the BeagleBone Black) to play the role of both the experiment server and the embedded device. From a software perspective, this eliminated the need for an entire layer of communication and synchronization. From a hardware perspective, use of the BeagleBone black instead of a Raspberry Pi removed the need to design or source analogue to digital conversion modules.
-Another major design change which occured quite early in the project\footnote{about week 2} is the switch from using multiple processes to running a single multithreaded process on the server. After performing some rudimentary testing it became clear that a system of seperate programs would be difficult to implement and maintain. Threads are similar to processes but are able to directly share memory, with the result that much less synchronisation is required in order to transfer information.
+As the revised diagram in Figure \ref{block_diagram_final.png} shows, to remove an extra layer of complexity it was decided to use a single device (the BeagleBone Black) to play the role of both the experiment server and the embedded device. From a software perspective, this eliminated the need for an entire layer of communication and synchronization. From a hardware perspective, use of the BeagleBone black instead of a Raspberry Pi removed the need to design or source analogue to digital conversion modules.
-\section{Hardware Interfacing}
+Another major design change which occured quite early in the project is the switch from using multiple processes to running a single multithreaded process on the server. After performing some rudimentary testing (see Section \ref{Server Interface}) it became clear that a system of seperate programs would be difficult to implement and maintain. Threads are similar to processes but are able to directly share memory, with the result that much less synchronisation is required in order to transfer information.
-Figure \ref{} shows the pin out diagram of the BeagleBone black. There are many contradictory pin out diagrams available on the internet; Figure \ref{} was created by the software team after trial and error testing to determine the correct location of each pin.
+{\bf Note on filenames:} In the following, files and directories related to the server are located in the \href{https://github.com/szmoore/MCTX3420/tree/master/server}{server} directory, files related to the (currently used) GUI are in \href{https://github.com/szmoore/MCTX3420/tree/master/testing/MCTXWeb}{testing/MCTXWeb}, and files created for testing purposes are located in \href{https://github.com/szmoore/MCTX3420/tree/master/testing}{testing}.
-The final specification of the pins and functions was chosen by the electrical team, although several earlier specifications were rejected after difficulties controlling the pins in software. These pins are identified in Table \ref{}.
-
-
-\subsection{Calibration Methods}
-
-Calibration of the sensors was done at a fairly late stage in the project and only a small number of test points were taken. With the exception of the microscope (discussed in Section \ref{}), all sensors used in this project produce an analogue output. After conditioning and signal processing, this arrives at an analogue input pin on the BeagleBone as a signal in the range $0\to1.8\text{V}$.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/block_diagram1.png}
+ \caption{Block Diagram from Week 1 of the Project}
+ \label{block_diagram1.png}
+\end{figure}
-\section{Server Program}
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/block_diagram_final.png}
+ \caption{Block Diagram from Week 14 of the Project}
+ \label{block_diagram_final.png}
+\end{figure}
+\section{Server Program}\label{Server Program}
\subsection{Threads and Sampling Rates}
The Server Program runs as a multithreaded process under a POSIX compliant GNU/Linux operating system\footnote{Tested on Debian and Ubuntu}. Each thread runs in parallel and is dedicated to a particular task; the three types of threads we have implemented are:
\begin{enumerate}
- \item Main Thread\ref{} - Starts all other threads, accepts and responds to HTTP requests passed to the program by the HTTP server in the \verb/FastCGI_Loop/ function.
- \item Sensor Thread\ref{} - Each sensor in the system is monitored by an individual thread running the \verb/Sensor_Loop/ function.
- \item Actuator Thread\ref{} - Each actuator in the system is controlled by an individual thread running the \verb/Actuator_Loop/ function.
+ \item Main Thread (Section \ref{Main Thread}) - Starts all other threads, accepts and responds to HTTP requests passed to the program by the HTTP server in the \funct{FastCGI_Loop} function (also see Section \ref{Communications})
+ \item Sensor Thread (Section \ref{Sensor Thread}) - Each sensor in the system is monitored by an individual thread running the \funct{Sensor_Loop} function.
+ \item Actuator Thread (Section \ref{Actuator Thread}) - Each actuator in the system is controlled by an individual thread running the \funct{Actuator_Loop} function.
\end{enumerate}
In reality, threads do not run simultaneously; the operating system is responsible for sharing execution time between threads in the same way as it shares execution times between processes. Because the linux kernel is not deterministic, it is not possible to predict when a given thread is actually running. This renders it impossible to maintain a consistent sampling rate, and necessitates the use of time stamps whenever a data point is recorded.
-Figure \ref{} shows a distribution of times between samples for a test sensor with the software sampling as fast as possible.
-Figure \ref{} shows the distribution when the sampling rate is set to 20Hz. Caution should be taken when interpreting these results, as they rely on the accuracy of timestamps recorded by the same software that is being time sliced by the operating system.
-
-RTLinux is a version of the linux kernel that attempts to increase the predictability of when a process will have control\cite{rtlinux}. It was not possible to obtain a real time linux kernel for the BeagleBone. However, testing on an amd64 laptop (figure \ref{}) showed very little difference in the sampling time distribution when the real time linux kernel was used.
+Figure \ref{sample_rate_histogram.png} shows a distribution of times\footnote{The clock speed of the BeagleBone is between 200MHz and 700MHz (depends on power)\cite{cameon.net} which is fast enough to neglect the fact that recording the timestamp takes several CPU cycles} between samples for a test sensor with the software sampling as fast as possible. Note the logarithmic $t$ axis. Although context switching clearly causes the sample rate to vary (\textcolor{green}{green}), the actual process of reading an ADC (\textcolor{red}{red}) using \funct{ADC_Read} (\gitref{server}{bbb_pin.c}) is by far the greatest source of variation.
+It was not possible to obtain a real time linux kernel for the BeagleBone. In theory, real time variants of the linux kernel improve the reliability of sampling rates. However, testing on an amd64 laptop showed very little difference in the sampling time distribution when the real time linux kernel was used.
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/sample_rate_histogram.png}
+ \caption{Sample Rate Histogram obtained from timestamps with a single test sensor enabled}
+ \label{sample_rate_histogram.png}
+\end{figure}
-\subsection{Main Thread}
+\subsection{Main Thread}\label{Main Thread}
-The main thread of the process is responsible for transfering data between the server and the client through the Hypertext Transmission Protocol (HTTP). A library called FastCGI is used to interface with an existing webserver called nginx\cite{nginx}. This configuration and the format of data transferred between the GUI and the server is discussed in more detail Section \ref{}.
+The main thread of the process is responsible for transfering data between the server and the client through the Hypertext Transmission Protocol (HTTP). A library called FastCGI is used to interface with an existing webserver called nginx\cite{nginx}. This configuration and the format of data transferred between the GUI and the server is discussed in more detail Section \ref{Communications}.
-Essentially, the main thread of the process responds to HTTP requests. The GUI is designed to send requests periodically (eg: to update a graph) or when a user action is taken (eg: changing the pressure setting). When this is received, the main thread parses the request, the requested action is performed, and a response is sent. The GUI is then responsible for updating its appearance or alerting the user based on this response. Figure \ref{server_overview.png} gives an overview of this process.
+Essentially, the main thread of the process responds to HTTP requests. The GUI is designed to send requests periodically (eg: to update a graph) or when a user action is taken (eg: changing the pressure setting). When this is received, the main thread parses the request, the requested action is performed, and a response is sent. The GUI is then responsible for updating its appearance or alerting the user based on this response. Figure \ref{fastcgi-flow-chart.png} in Section \ref{API}gives an overview of this process.
-\subsection{Sensor Threads}
+\subsection{Sensor Threads}\label{Sensor Thread}
Figure \ref{sensor_thread.pdf} shows a flow chart for the thread controlling an individual sensor. This process is implemented by \verb/Sensor_Loop/ and associated helper functions.
-All sensors are treated as returning a single floating point number when read. A \verb/DataPoint/ consists of a time stamp and the sensor value. \verb/DataPoint/s are continously saved to a binary file as long as the experiment is in process. An appropriate HTTP request (see section\ref{}) will cause the main thread of the server program to respond with \verb/DataPoint/s read back from the file. By using independent threads for reading data and transferring it to the GUI, the system does not rely on maintaining a consistent and synchronised network connection. This means that one the experiment is started with the desired parameters, a user can safely close the GUI or even shutdown their computer without impacting on the operation of the experiment.
+All sensors are treated as returning a single floating point number when read. A \type{DataPoint} consists of a time stamp and the sensor value. \type{DataPoint}s are continously saved to a binary file as long as the experiment is in process. An appropriate HTTP request (Section\ref{API}) will cause the main thread of the server program to respond with \type{DataPoint}s read back from the file. By using independent threads for reading data and transferring it to the GUI, the system does not rely on maintaining a consistent and synchronised network connection. This means that one the experiment is started with the desired parameters, a user can safely close the GUI or even shutdown their computer without impacting on the operation of the experiment.
-\subsection{Actuator Threads}
+\subsection{Actuator Threads}\label{Actuator Thread}
Actuators are controlled by threads in a similar way to sensors. Figure \ref{actuator_thread.pdf} shows a flow chart for these threads. This is implemented in \verb/Actuator_Loop/. Control over real hardware is seperated from the main logic in the same way as sensors (relevant files are in the \verb/actuators/ sub directory). The use of threads to control actuators gives similar advantages in terms of eliminating the need to syncronise the GUI and server software.
\subsection{Data Storage and Retrieval}
-Each sensor or actuator thread stores data points in a seperate binary file identified by the name of the device. When the main thread receives an appropriate HTTP request, it will read data back from the binary file. To allow for selection of a range of data points from the file, a binary search has been implemented.
+Each sensor or actuator thread stores data points in a seperate binary file identified by the name of the device. When the main thread receives an appropriate HTTP request, it will read data back from the binary file. To allow for selection of a range of data points from the file, a binary search has been implemented. Functions related to data storage and retrieval are located in the \gitref{server}{data.h} and \gitref{server}{data.c} source files.
+
+Several alternate means of data storage were considered for this project. Binary files were chosen because of the significant performance benefit after testing, and the ease with which data can be read from any location in file and converted directly into values. A downside of using binary files is that the server software must always be running in order to convert the data into a human readable format.
+
+
+
+\subsection{Safety Mechanisms}
+
+Given the inexperienced nature of the software team, the limited development time, and the unclear specifications, it is not wise to trust safety aspects of the system to software alone. It should also be mentioned that the correct functioning of the system is reliant not only upon the software written during this project, but also the many libraries which are used, and the operating system under which it runs. We found during development that many of the mechanisms for controlling BeagleBone hardware are unreliable and have unresolved issues; see the project wiki pages\cite{mctx3420_wiki} for more information. We attempted to incorporate safety mechanisms into the software wherever possible.
-Several alternate means of data storage were considered for this project. Binary files were chosen because of the significant performance benefit (see Figure \ref{}) and ease with which data can be read from any location in file and converted directly into values. A downside of using binary files is that the server software must always be running in order to convert the data into a human readable format.
+Sensors and Actuators should define an initialisation and cleanup function. For an actuator (eg: the pressure regulator), the cleanup function must set the actuator to a predefined safe value (in the case of pressure, atmospheric pressure) before it can be deinitialised. In the case of a software error or user defined emergency, the \funct{Fatal} function can be called from any point in the software; this will lead to the cleanup functions of devices being called, which will in turn lead to the pressure being set to a safe value.
+
+Sensors and Actuators are designed to include an optional \funct{sanity} function which will check a reading or setting is safe respectively. These checks occur whenever a sensor value is read or an actuator is about to be set. In the case of a sensor reading failing the sanity check, \funct{Fatal} is called immediately and the software shuts down the experiment. In the case of an actuator being set to an unsafe value the software will simply refuse to set the value.
+
+It is recommended that the detection of signals (a mechanism in GNU/Linux by which a program can detect certain types of unexpected crashes) be investigated. This was attempted in early implementations; however difficulties were encountered because any thread can catch the signal and thus will not be able to execute its cleanup function, or in some cases, continue running after the rest of the program has stopped.
+
+An alternative safety mechanism involves modification of the script that starts the server (\gitref{server}{run.sh}). This script is already able to detect when the program exits, and it should be possible to further extend this script to react accordingly to different exit codes.
+
+\pagebreak
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.1\textwidth]{figures/sensor_thread.pdf}
+ \caption{Flow chart for a sensor thread}
+ \label{sensor_thread.pdf}
+\end{figure}
+\pagebreak
+\pagebreak
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.1\textwidth]{figures/actuator_thread.pdf}
+ \caption{Flow chart for an actuator thread}
+ \label{actuator_thread.pdf}
+\end{figure}
-\subsection{Authentication}
-The \verb/Login_Handler/ function is called in the main thread when a HTTP request for authentication is received. This function checks the user's credentials and will give them access to the system if they are valid.
+\section{Hardware Interfacing}\label{Hardware}
+Figure \ref{pinout.pdf} shows the pin out diagram of the BeagleBone Black. There are many contradictory pin out diagrams available on the internet; this figure was initially created by the software team after trial and error testing with an oscilloscope to determine the correct location of each pin. Port labels correspond with those marked on the BeagleBone PCB. The choice of pin allocations was made by the electrical team after discussion with software when it became apparent that some pins could not be controlled reliably.
-Whilst we had originally planned to include only a single username and password, changing client requirements forced us to investigate many alternative authentication methods to cope with multiple users.
+
+
+
+\subsection{Sensors}
+
+Code to read sensor values is located in the \gitref{server}{sensors} subdirectory. With the exception of the dilatometer (discussed in Section \ref{Image Processing}), all sensors used in this project produce an analogue output. After conditioning and signal processing, this arrives at an analogue input pin on the BeagleBone as a signal in the range $0\to1.8\text{V}$. The sensors currently controlled by the software are:
+
+\begin{itemize}
+ \item {\bf Strain Gauges} (x4)
+
+ To simplify the amplifier electronics, a single ADC is used to read all strain gauges. GPIO pins are used to select the appropriate strain gauge output from a multiplexer. A mutex is used to ensure that no two strain gauges can be read simultaneously.
+
+
+ \item {\bf Pressure Sensors} (x3)
+
+ There are two high range pressure sensors and a single low range pressure sensor; all three are read independently
+ \item {\bf Microphone} (x1)
+
+ The microphone's purpose is to detect the explosion of a can. This sensor was given a low priority, but has been tested with a regular clicking tone and found to register spikes with the predicted frequency (~1.5Hz).
+ \item {\bf Dilatometer} (x2) - See Section \ref{Image Processing}
+\end{itemize}
+
+Additional sensors can be added and enabled through use of the \funct{Sensor_Add} function in \funct{Sensor_Init} in the file \gitref{server}{sensors.c}.
+
+The function \funct{Data_Calibrate} located in \gitref{server}{data.c} can be used for interpolating calibration. The pressure sensors and microphone have been calibrated in collaboration with the Sensors Team; however only a small number of data points were taken and the calibration was not tested in detail. We would recommend a more detailed calibration of the sensors for future work.
+
+\subsection{Actuators}
+
+Code to set actuator values is located in the \gitref{server}{actuators} subdirectory. The following actuators are (as of writing) controlled by the software and have been successfully tested in collaboration with the Electronics and Pneumatics teams. Additional actuators can be added and enabled through use of the \funct{Actuator_Add} function in \funct{Actuator_Init} in the file \gitref{server}{actuators.c}.
+
+\subsubsection{Relay Controls}
+
+The electrical team employed three relays (model: ) for control over digital devices. The relays are switched using the GPIO outputs of the BeagleBone Black.
+
+\begin{itemize}
+ \item Can select - Chooses which can can be pressurised (0 for strain, 1 for explode)
+ \item Can enable - Allows the can to be pressurised (0 for vent, 1 for enable)
+ \item Main enable - Allows pressure to flow to the system (0 for vent, 1 for enable) and can be used for emergency venting
+\end{itemize}
+
+The use of a ``can select'' and ``can enable'' means that it is not a software problem to prevent both cans from simultaneously being pressurised. This both simplifies the software and avoids potential safety issues if the software were to fail.
+
+
+\subsubsection{PWM Outputs}
+
+A single PWM output is used to control a pressure regulator (model: ). The electrical team constructed an RC filter circuit which effectively averages the PWM signal to produce an almost constant analogue output. The period of the PWM is $2\text{kHz}$. This actuator has been calibrated, which allows the user to input the pressure value in kPa rather than having to control the PWM duty cycle corretly.
+
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[angle=90,width=1.0\textwidth]{figures/pinout.pdf}
+ \caption{Pinout Table}
+ \label{pinout.pdf}
+\end{figure}
+
+
+\section{Authentication Mechanisms}\label{Authentication}
+
+The \funct{Login_Handler} function (\gitref{server}{login.c}) is called in the main thread when a HTTP request for authentication is received (see Section \ref{Communication}). This function checks the user's credentials and will give them access to the system if they are valid. Whilst we had originally planned to include only a single username and password, changing client requirements forced us to investigate many alternative authentication methods to cope with multiple users.
Several authentication methods are supported by the server; the method to use can be specified as an argument when the server is started.
\begin{enumerate}
\item {\bf MySQL Database}
- MySQL is a popular and free database system that is widely used in web applications. The ability to search for a user in a MySQL database and check their encrypted password was added late in the design as an alternative to LDAP. There are several existing online user management systems which interface with a MySQL database, and so it is feasable to employ one of these to maintain a list of users authorised to access the experiment. UserCake is recommended, as it is both minimalistic and open source, so can be modified to suit future requirements.
+ MySQL is a popular and free database system that is widely used in web applications. The ability to search for a user in a MySQL database and check their encrypted password was added late in the design as an alternative to LDAP. There are several existing online user management systems which interface with a MySQL database, and so it is feasable to employ one of these to maintain a list of users authorised to access the experiment. UserCake is recommended, as it is both minimalistic and open source, so can be modified to suit future requirements. We have already begun integration of the UserCake system into the project, however a great deal of work is still required.
MySQL and other databases are vulnerable to many different security issues which we did not have sufficient time to fully explore. Care should be taken to ensure that all these issues are addressed before deploying the system.
+\end{enumerate}
+
+% END Sam's section
+
+
+\section{Server/Client Communication}\label{Communications}
+
+% BEGIN Jeremy's section
+
+This section describes the methods and processes used to communicate between the server and client. For this system, client-server interaction is achieved completely over the internet, via standard HTTP web requests with TLS encryption. In other words, it has been designed to interact with the client over the internet, {\bf completely through a standard web browser} (Figure \ref{client_request_flowchart.png}). No extra software should be required from the client. Detailed reasons for this choice are outlined in Section \ref{Alternative Communication}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=1.1\textwidth]{figures/client_request_flowchart.png}
+ \caption{High level flow chart of a client request to server response}
+ \label{client_request_flowchart.png}
+\end{figure}
+
+\subsection{Web server}
+Web requests from a user have to be handled by a web server. For this project, the nginx\cite{nginx} webserver has been used, and acts as the frontend of the remote interface for the system. As shown in Figure \ref{client_request_flowchart.png}, all requests to the system from a remote client are passed through nginx, which then delegates the request to the required subsystem as necessary.
+
+In particular, nginx has been configured to:
+\begin{enumerate}
+ \item Use TLS encryption (HTTPS)
+ \item Forward all HTTP requests to HTTPS requests (force TLS encryption)
+ \item Display the full sever program logs if given \api{log} as the address
+ \item Display the warning and error logs if given \api{errorlog} as the address
+ \item Forward all other requests that start with \api{} to the server program (FastCGI)
+ \item Process and display PHP files (via PHP-FPM) for UserCake
+ \item Try to display all other files like normal (static content; e.g the GUI)
\end{enumerate}
-\subsection{Safety Mechanisms}
+Transport Layer Security (TLS) encryption, better known as SSL or HTTPS encryption has been enabled to ensure secure communications between the client and server. This is primarily important for when user credentials (username / password) are supplied, and prevents what is called ``man-in-the-middle'' attacks. In other words, it prevents unauthorised persons from viewing such credentials as they are transmitted from the client to the server.
+
+As also mentioned in Section \ref{Authentication} this system also runs a MySQL server for the user management system, UserCake. This kind of server setup is commonly referred to as a LAMP (Linux, Apache, MySQL, PHP) configuration\cite{}, except in this case, nginx has been used in preference to the Apache web server.
-Given the inexperienced nature of the software team, the limited development time, and the unclear specifications, it is not wise to trust safety aspects of the system to software alone. It should also be mentioned that the correct functioning of the system is reliant not only upon the software written during this project, but also the many libraries which are used, and the operating system under which it runs. We found during development that many of the mechanisms for controlling BeagleBone hardware are unreliable and have unresolved issues. We attempted to incorporate safety mechanisms into the software wherever possible.
+Nginx was used as the web server because it is well established, lightweight and performance oriented. It also supports FastCGI by default, which is how nginx interfaces with the server program. Realistically, any well known web server would have sufficed, such as Apache or Lighttpd, given that this is not a large scale service.
-Sensors and Actuators should define an initialisation and cleanup function. For an actuator (eg: the pressure regulator), the cleanup function must set the actuator to a predefined safe value (in the case of pressure, atmospheric pressure) before it can be deinitialised. In the case of a software error or user defined emergency, the \verb/Fatal/ function can be called from any point in the software; this will lead to the cleanup functions of devices being called, which will in turn lead to the pressure being set to a safe value. The cleanup functions will also be called if the software exits unexpectedly.
+\subsection{FastCGI}
-Sensors and Actuators are designed to include a \verb/sanity/ function which will check a reading or setting is safe respectively. These checks occur whenever a sensor value is read or an actuator is about to be set. In the case of a sensor reading failing the sanity check, \verb/Fatal/ is called immediately and the software shuts down the experiment. In the case of an actuator being set to an unsafe value the software will simply refuse to set the value.
+Nginx has no issue serving static content --- that is, just normal files to the user. Where dynamic content is required, as is the case for this system, another technology has to be used, which in this case is FastCGI.
+FastCGI is the technology that interfaces the server program that has been written with the web server (nginx). As illustrated in Figure \ref{client_request_flowchart.png}, there is a ``FastCGI layer'', which translates web requests from a user to something which the server program can understand, and vice versa for the response.
-\subsection{Performance}
+\subsection{Server API - Making Requests}\label{API}
-Figure \ref{} shows the CPU and memory usage of the server program with different numbers of dummy sensor threads. This gives an idea of how well the system would scale if all sensors were run on the same BeagleBone.
+From the client side, the server interface is accessed through an Application Programming Interface (API). The API forms a contract between the client and server; by requesting a URL of a predetermined format, the response will also be of a predetermined format that the client can use.
\begin{figure}[H]
\centering
- \includegraphics[width=1.0\textwidth]{figures/server_overview.png}
- \caption{Server overview}
- \label{server_overview.png}
+ \includegraphics[width=1.1\textwidth]{figures/fastcgi-flow-chart.png}
+ \caption{Flow chart of a client request being processed (within the server program). Relevant files are \gitref{server}{fastcgi.c} and \gitref{server}{fastcgi.h}.}
+ \label{fastcgi-flow-chart.png}
\end{figure}
+In the case of the server API designed, requests are formatted as such:
+
+\url{https://host/api/module?key1=value1&key2=value2...&keyN=valueN} (where \verb/host/ is replaced with the IP address or hostname of the server).
+
+
+The API consists of modules that can accept a certain number of arguments (specified as key-value pairs), depending on what that module (Figure \ref{modules}) does. For example, to query the API about basic information (running state, whether the user is logged in etc), the following query is used:
+
+\url{https://host/api/identify}
+
+The server will then respond with this information. In this case, the identify module does not require any arguments. However, it can accept two optional arguments, \texttt{sensors} and \texttt{actuators}, which makes it give extra information on the available sensors and actuators present. This makes the following queries possible:
+
+\begin{itemize}
+ \item \url{https://host/api/identify?sensors=1}
+ \item \url{https://host/api/identify?actuators=1}
+ \item \url{https://host/api/identify?sensors=1&actuators=1}
+\end{itemize}
+
+These give information on the sensors, actuators, or both, respectively. For other modules some parameters may be required, and are not optional.
+This form of an API was chosen because it is simple to use, and extremely easy to debug, given that these requests can just be entered into any web browser to see the result. The request remains fairly human readable, which was another benefit when debugging the server code.
+
+Keeping the API format simple also made it easier to write the code that parsed these requests. All API parsing and response logic lies in \gitref{server}{fastcgi.c}. The framework in \gitref{server}{fastcgi.c} parses a client request and delegates it to the relevant module handler. Once the module handler has sufficiently processed the request, it creates a response, using functions provided by \gitref{server}{fastcgi.c} to do so.
+
+This request handling code went through a number of iterations before the final solution was reached. Changes were made primarily as the number of modules grew, and as the code was used more.
+
+One of the greatest changes to request handling was with regards to how parameters were parsed. Given a request of: \url{http://host/api/actuators?name=pregulator\&start_time=0\&end_time=2}, The module handler would receive as the parameters \texttt{name=pregulator\&start_time=0\&end_time=2}. This string had to be split into the key/value pairs to be used, which resulted in the function \funct{FCGI_KeyPair} being made, which was initially sufficient for most cases.
+
+However, as more module handlers were created, and as the number of parameters required increased, \funct{FCGI_KeyPair} became increasingly cumbersome to use. \funct{FCGI_ParseRequest} was created in response, and internally uses \funct{FCGI_KeyPair}, but abstracts request parsing greatly. In essence, it validates the user input, rejecting anything that doesn't match a specified format. If it passes this test, it automatically populates variables with these values. The \funct{IndentifyHandler} module handler in \gitref{server}{fastcgi.c} is a very good example of how this works.
-\pagebreak
\begin{figure}[H]
\centering
- \includegraphics[width=1.1\textwidth]{figures/sensor_thread.pdf}
- \caption{Flow chart for a sensor thread}
- \label{sensor_thread.pdf}
+ \begin{tabular}{llll}
+ {\bf API} & {\bf File} & {\bf Function} & {\bf Purpose} \\
+ \api{identify} & \gitref{server}{fastcgi.c} & \funct{IdentifyHandler} & Provide system information \\
+ \api{sensors} & \gitref{server}{sensors.c} & \funct{Sensor_Handler} & Query sensor data points or set sampling rate\\
+ \api{actuators} & \gitref{server}{actuators.c} & \funct{Actuator_Handler} & Set actuator values or query past history \\
+ \api{image} & \gitref{server}{image.c} & \funct{Image_Handler} & Return image from a camera (See Section \ref{Image Processing}) \\
+ \api{control} & \gitref{server}{control.c} & \funct{Control_Handler} & Start/Stop/Pause/Resume the Experiment \\
+ \api{bind} & \gitref{server}{login.c} & \funct{Login_Handler} & Attempt to login to the system (See Section \ref{Cookies})\\
+ \api{unbind} & \gitref{server}{login.c} & \funct{Logout_Handler} & If logged in, logout.
+ \end{tabular}
+ \caption{Brief description of the modules currently implemented by the server.}
+ \label{modules}
\end{figure}
-\pagebreak
-\pagebreak
+
+\subsection{Server API - Response Format}
+
+The server API primarily generates JSON responses to most requests. This was heavily influenced by what the GUI would be programmed in, being JavaScript. This particular format is parsed easily in JavaScript, and is easily parsed in other languages too.
+
+A standard JSON response looks like such:
+
\begin{figure}[H]
\centering
- \includegraphics[width=1.1\textwidth]{figures/actuator_thread.pdf}
- \caption{Flow chart for an actuator thread}
- \label{actuator_thread.pdf}
+\begin{verbatim}
+{
+ "module" : "identify",
+ "status" : 1,
+ "start_time" : 614263.377670876,
+ "current_time" : 620591.515903585,
+ "running_time" : 6328.138232709,
+ "control_state" : "Running",
+ "description" : "MCTX3420 Server API (2013)",
+ "build_date" : "Oct 24 2013 19:41:04",
+ "clock_getres" : 0.000000001,
+ "api_version" : 0,
+ "logged_in" : true,
+ "user_name" : "_anonymous_noauth"
+}
+\end{verbatim}
+ \caption{A standard response to querying the \api{identify} module}
+ \label{fastcgi.c-flow-chart.pdf}
\end{figure}
-\pagebreak
-\section{Image Processing}
+A JSON response is the direct representation of a JavaScript object, which is what makes this format so useful. For example if the JSON response was parsed and stored in the object \var{data}, the elements would be accessible in JavaScript through \var{data.module} or \var{data.status}.
+
+To generate the JSON response from the server program, \gitref{server}{fastcgi.c} contains a framework of helper functions. Most of the functions help to ensure that the generated output is in a valid JSON format, although only a subset of the JSON syntax is supported. Supporting the full syntax would overcomplicate writing the framework while being of little benefit. Modules can still respond with whatever format they like, using \funct{FCGI_JSONValue} (aka. \funct{FCGI_PrintRaw}), but lose the guarantee that the output will be in a valid JSON format.
+
+Additionally, not all responses are in the JSON format. In specific cases, some module handlers will respond in a more suitable format. For example, the image handler will return an image (using \funct{FCGI_WriteBinary}); it would make no sense to return anything else. On the other hand, the sensor and actuator modules will return data as tab-separated values, if the user specifically asks for it (eg: using \url{https://host/api/sensors?id=X&format=tsv})
+
+\subsection{Server API - Cookies}\label{Cookies}
+
+The system makes use of HTTP cookies to keep track of who is logged in at any point. The cookie is a small token of information that gets sent by the server, which is then stored automatically by the web browser. The cookie then gets sent back automatically on subsequent requests to the server. If the cookie sent back matches what is expected, the user is ‘logged in'. Almost all web sites in existence that has some sort of login use cookies to keep track of this sort of information, so this method is standard practice.
+In the server code, this information is referred to as the ‘control key'. A control key is only provided to a user if they provide valid login credentials, and no one else is logged in at that time.
+
+The control key used is the SHA-1 hash of some randomly generated data, in hexadecimal format. In essence, this is just a string of random numbers and letters that uniquely identifies the current user.
+
+Initially, users had to pass this information as another key-value pair of the module parameters. However, this was difficult to handle, both for the client and the server, which was what precipitated the change to use HTTP cookies.
+
+\subsection{Client - JavaScript and AJAX Requests}
+
+JavaScript forms the backbone of the web interface that the clients use. JavaScript drives the interactivity behind the GUI and enables the web interface to be updated in real-time. Without JavaScript, interactivity would be severely limited, which would be a large hindrance to the learning aspect of the system.
+
+To maintain interactivity and to keep information up-to-date with the server, the API needs to be polled at a regular interval. Polling is necessary due to the design of HTTP; a server cannot ``push'' data to a client, the client must request it first. To be able to achieve this, code was written in JavaScript to periodically perform what is termed AJAX requests.
+
+AJAX requests are essentially web requests made in JavaScript that occur ``behind the scenes'' of a web page. By making such requests in JavaScript, the web page can be updated without having the user refresh the web page, thus allowing for interactivity and a pleasant user experience.
+
+Whilst AJAX requests are possible with plain JavaScript, the use of the jQuery library (see Section \ref{jQuery}) greatly simplifies the way in which requests can be made and interpreted.
+
+\section{Alternative Communication Technologies}\label{Alternative Communication}
+
+This section attempts to explain the reasoning behind the communication method chosen. This choice was not trivial, as it had to allow for anyone to remotely control the experiment, while imposing as little requirements from the user as possible. These requirements can be summarised by:
+\begin{enumerate}
+ \item A widely available, highly accessible service should be used, to reach as many users as possible
+ \item Communication between client and server should be fairly reliable, to maintain responsiveness of the remote interface
+ \item Communication should be secured against access from unauthorised persons, to maintain the integrity of the system
+\end{enumerate}
+
+To satisfy the first criteria, remote control via some form of internet access was the natural choice. Internet access is widely established and highly accessible, both globally and locally, where it can be (and is) used for a multitude of remote applications. One only needs to look as far as the UWA Telelabs project for such an example, having been successfully run since 1994 \cite{telelabs}.
+
+Internet communications itself is complex, and there is more than one way to approach the issue of remote control. A number of internet protocols exist, where the protocol chosen is based on the needs of the application. Arguably most prevalent is the Hypertext Transfer Protocol (HTTP)\cite{rfc2616} used in conjunction with the Transmission Control Protocol (TCP) - to distribute web pages and related content across the internet. Other protocols exist, but are less widely used. Even custom protocols can be used, but that comes at the cost of having to build, test and maintain an extra component of software that likely has no benefit over pre-existing systems.
+
+As a result, being able to control the system via a web page and standard web browser seemed the most logical choice, which was why it was used in the final design. Firstly, by designing the system to be controlled from a web page, the system becomes highly accessible, given that where internet access is present, the presence of a web browser is almost guaranteed. Nothing else from the client is required.
+
+Secondly, setup and maintenance for the server is less involved, given that there is a wide range of pre-existing software made just for this purpose. Many features of the web browser can also be leveraged to the advantage of the system --- for example, communications between the client and server can be quite easily secured using Transport Layer Security (TLS, previously known as Secure Sockets Layer or SSL).
+
+Thirdly, reliability of the communications is better guaranteed by using such existing technology, which has been well tested and proven to work of its own accord. While internet access itself may not always be fully reliable, the use of such protocols and correct software design allows for a fair margin of robustness towards this issue. For example, TCP communications have error checking methods built-in to the protocol, to ensure the correct delivery of content. Similarly, HTTP has been designed with intermittent communications to the client in mind\cite{rfc2616}.
+
+\subsection{Server Interface} \label{Server Interface}
+Other options were explored apart from FastCGI to implement the server interface. Primarily, it had to allow for continuous sensor/actuator control independent of user requests, which may be intermittent.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/cgi.png}
+ \caption{Block Diagram of a request to a CGI Application}
+ \label{cgi.png}
+\end{figure}
+
+Initially, a system known as ``Common Gateway Interface'', or CGI was explored. However, CGI based software is only executed when a request is received (Figure \ref{cgi.png}, which makes continuous control and logging over the sensors and actuators unfeasible.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/custom_webserver.png}
+ \caption{Block Diagram of a request to a custom webserver}
+ \label{custom_webserver.png}
+\end{figure}
+
+Before FastCGI was found, the plan was to build a custom web server (Figure \ref{custom_webserver.png} that used threading. Both the sensor/actuator control and the web interface would reside in the same process. By having both in the same process, continuous control is possible whilst waiting for web requests to be received.
+
+This would have worked, and in fact operates similarly to the final solution, but it was not without drawbacks. By building a custom web server, more effort would have to be spent just to maintain low-level web functionalities, such as responding appropriately to a client request. Perhaps more importantly, features taken for granted from a standard web server would become increasingly difficult to support with a custom web server. For example, services like TLS encryption and PHP support would be near-impossible, or at least very difficult to add. In other words, it was deemed that this solution would be inflexible and not particularly maintainable into the future.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/fastcgi.png}
+ \caption{Block Diagram of a request to a FastCGI application}
+ \label{fastcgi.png}
+\end{figure}
+
+In comparison, FastCGI (Figure \ref{fastcgi.png}) can be seen as the ``best of both worlds''. As mentioned previously, it is a variant of CGI, in that it allows some software to respond to web requests. The key difference is that with FastCGI, the program is continuously run independent of any web requests. This overcomes the issues faced with either using CGI or a custom web server; continuous control can be achieved while also not having to worry about the low-level implementation details a web server.
+
+
+
+\subsection{Recommendations for Future Work}
+
+\begin{enumerate}
+ \item A self-signed TLS certificate has been used, as it is free. It is equally secure as any, but users will get a security warning when accessing the web site. A proper TLS certificate signed by a trusted certificate authority should be used instead.
+ \item Consider expanding the framework of JSON functions to simplify creating a response.
+ \item Consider using X-Accel-Redirect along with UserCake (Section \ref{Authentication}) to make a finer-grained access control system to information such as the system logs
+\end{enumerate}
-\section{Client Program}
+\section{Server Configuration}
+\subsection{Operating system}
+The Beaglebone has been configured to use the Ubuntu operating system. The original operating system was Angstrom, which was unsuitable because it lacked a number of software packages required. Detailed instructions on how to install this operating system exist on the project wiki\cite{mctx3420_wiki}.
+In particular, Ubuntu 13.04 running Linux kernel 3.8.13-bone28 was used, which is essentially the latest version available to date for this platform. Normally an older, more tested version is recommended, especially in a server environment. However, the BeagleBone Black is a relatively new device, and it was found that a lot of the drivers simply do not work well on older versions.
-\subsection{Human Computer Interaction}
+Specifically, there was much grief over getting the pins to function correctly, especially for PWM output. Lacking any great documentation, much trial and error was spent determining the best configuration. The BeagleBone Black uses what is termed a ``device tree'' \cite{beaglebone3.8, devicetreetutorial} and ``device tree overlays'' to dynamically determine what each pin does. This is because each pin can have more than one function, so a ``device tree overlay'' determines what it does at any one point. However, this also complicates matters, since what pins do essentially have to be loaded at runtime.
-\subsection{Interaction with API}
+PWM control in particular took many hours to achieve, which was not helped by a lot of conflicting information available online. As a result, the primary tool used to correctly determine proper PWM control was the use of a cathode ray oscilloscope. Quite briefly, it was found that certain actions had to be performed in a very specific order to make PWM control available. There were also specific limitations, such as pairs of pins being coupled to the same time base (period). The wiki goes into more detail on the issues found.
+Getting the cameras to work on the BeagleBone was another major issue faced. After much testing, it was simply found that the cameras could only work on the latest version of the operating system. On anything else, only low resolution captures of around 352x288 pixels could be achieved.
+Finally, it should be noted that USB hotplugging does not work on the BeagleBone. This means that the cameras have to be plugged in before booting the BeagleBone. Upgrading to a newer kernel (when it exists) should solve this issue.
+\subsection{Required software}
+A number of packages are required to compile the code:
+\texttt{nginx spawn-fcgi libfcgi-dev gcc libssl-dev make libopencv-dev valgrind libldap2-dev mysql-server libmysqlclient-dev php5 php5-gd php5-fpm php5-mysqlnd}
+These packages should be installed with the command \texttt{apt-get install}.
+
+\subsection{Required configurations}
+Many components need to be configured correctly for the server to work. In particular, these configurations relate to the web server, nginx, as well as logging software used, rsyslog. These configurations are automatically installed by a specific script on the git repository.
+
+There is a folder, labelled server-configs. Executing \gitref{server-configs}{install.sh} as root should install all the required configuration files to run the server correctly.
+
+% END Jeremy's section
+
+\subsection{Logging and Debugging}
+
+The function \funct{Log} located in \gitref{server}{log.c} is used extensively throughout the server program for debugging, warning and error reporting. This function uses syslog to simultaneously print messages to the \texttt{stderr} output stream of the program and log them to a file, providing a wealth of information about the (mal)functioning of the program. As discussed in Section \ref{API}, the logs may be also be viewed by a client using the server API.
+
+For more low level debugging, ie: detecting memory leaks, uninitialised values, bad memory accesses, etc, the program \texttt{valgrind}\cite{valgrind} was frequently used.
+
+
+
+\section{Image Processing}\label{Image Processing}
+
+
+% BEGIN Callum's section
+
+
+The system contains two USB cameras, the Logitech C170\cite{logitechC170} and the Kaiser Baas KBA03030 (microscope)\cite{kaiserbaasKBA03030}. The Logitech camera will be used to record and stream the can being pressurized to explode. The microscope will be used to measure the change in width in the can.
+
+\subsection{OpenCV}
+
+For everything related to image acquisition and processing we decided to use a library called OpenCV\cite{OpenCV}. OpenCV uses the capture structure to connect with cameras, and stores the data in \type{IplImage} structures and the newer \type{CvMat} structure. As in C we cannot transfer the data straight to \type{CvMat} we need to convert from \type{IplImage} to \type{CvMat}. There are two main functions required for use with the camera. We need to be able to stream images to the user interface and use the microscope as a dilatometer, returning the rate of expansion of the can.
+
+
+\subsection{Image Streaming}
+The image streaming is done through the function file \gitref{server}{image.c} and the header \gitref{server}{image.h}. There are only 2 functions in \gitref{server}{image.c}, both of which are externally accessible by the rest of the system.
+
+ The \funct{Image_Handler} function handles requests from the server. The parameters required for taking the image, such as the camera ID, width and height are determined by calling \funct{FCGI_ParseRequest} (see \gitref{server}{fastcgi.h} and \gitref{server}{fastcgi.c}) using the parameter string passed to the function.
+
+The function \funct{Camera_GetImage} in \gitref{server}{image.c} is used to capture a frame on the camera from the ID given by \var{num}. As we cannot have 2 camera structures open at once, we use a mutex to ensure the function execute concurrently. We check to see if \var{num} is equivalent to the previous camera ID, if so we do not need to close the capture in order to recreate the connection with the new camera, which takes time. These considerations are currently redundant as the decision was made to only have one camera connected at a time, which was mainly due to power and bandwidth issues. However the code was implemented to allow for further development. If more than 2 cameras are ever connected, then the allowable upper bound for \var{num} will need to be increased to $n-1$ (where $n$ is the number of cameras connected to the system).
+
+After capturing the image we encode the \type{IplImage}, which passes back an encoded \type{CvMat}. The image is then returned back to the web browser via \funct{FCGI_WriteBinary}, where it can be displayed.
+
+\subsection{Dilatometer}
+
+The dilatometer algorithm is used to determine the rate of expansion of the can. The relevant functions are declared in \gitref{server}{sensors/dilatometer.c} and \gitref{server}{sensors/dilatometer.h}. When an experiment is started, \funct{Dilatometer_Init} is executed. This creates all the necessary structures and sets the initial value of \var{lastPosition}, which is a static variable that stores the last edge found.
+
+As the \funct{Camera_GetImage} function in \gitref{server}{image.c} is external, it can be accessed from \gitref{server}{sensors/dilatometer.c}. This was done so that both the dilatometer and the image stream can gain access to the camera. The \type{IplImage} returned is converted to the \type{CvMat} structure \var{g_srcRGB}. This \type{CvMat} structure is then passed to a function, \funct{CannyThreshold}. In this function, a series of steps are taken to extract an image containing only the edges. First we use \funct{cvCvtColor} to convert the \type{CvMat} file to a grayscale image. The image is then blurred using the \funct{cvSmooth} function, which we pass the parameters \var{CV_GAUSSIAN} and \var{BLUR}, so we use a Gaussian blur with a kernel of size \var{BLUR} (defined in \gitref{server}{sensors/dilatometer.h}). The blurred file is then passed to the OpenCV Canny Edge detector.
+
+The Canny Edge algorithm\cite{OpenCV_Canny} determines which pixels are ``edge'' pixels through a series of steps. The algorithm applies the Sobel operator in the x and y directions using \var{KERNELSIZE} for the size of the kernel. The result of this gives the gradient strength and direction. The direction is rounded to 0, 45, 90 or 135 degrees. Non-maximum suppression is then used to remove any pixels not considered to be part of an edge. The pixels left are then put through the hysteresis step. If the gradient of the pixel is higher than the upper threshold (in our algorithm denoted by \var{LOWTHRESHOLD*RATIO}) then the pixel is accepted as an edge. If it is below the lower threshold (i.e. \var{LOWTHRESHOLD}) then the pixel is disregarded. The remaining pixels are removed unless that is connected to a pixel above the upper threshold (Canny Edge Detector). The defined values in the header file can be altered to improve accuracy.
+
+The \funct{CannyThreshold} function fills the \type{CvMat} \var{g_edges} structure with the current images edge (i.e. an image containing only pixels considering to be edges, see Appendix \ref{appendix_imageedge} ). The code then finds the location of the line. It does this by sampling a number of rows, determined by the number of samples and the height of the image, finding the pixel/s in the row considered to be an edge. The algorithm then takes the average position of these pixels. The average position over all rows sampled then determines the actual edge position. The rows sampled are evenly spaced over the height of the image. If a row does not contain an edge, then it will not be included in the average. If a blank image goes through, or the algorithm has a low number of samples and does not pick up an edge, then the function will return false and the data point will not be recorded.
+
+Once the edge is found, we will either return the position of the edge, if the \var{DIL_POS} ID is set. It needs to be noted that this will only show the change in position of one side of the can. If the \var{DIL_DIFF} ID is set then the value will be set to the difference between the current position and the last position, multiplied by \var{SCALE} and 2. We need to multiply by 2 as we are only measuring the change in width to one side of the can, however we must assume that the expansion is symmetrical. The scale will be used to convert from pixels to $\mu$m (or a more suitable scale). Currently the scale is set to 1, as the dilatometer has not been calibrated, thus we are only measuring the rate of change of pixels (which is arbitrary). The static variable, \var{lastPosition}, is then set to determine the next change in size. If the difference is negative, then the can is being compressed or is being depressurized.
+The rate of expansion can then be determined from the data set. As the system does not have a fixed refresh rate, however each data point is time-stamped. If the data is the edge position, then plotting the derivative of the time graph will show the rate of expansion over time.
+
+\subsection{Design Considerations}
+
+\subsubsection{OpenCV}
+
+OpenCV was chosen as the image processing library primarily due to it being open source and widely used in image processing tasks.
+One thing to note however is the documentation for OpenCV for the language C is quite difficult to follow. This is mainly due to the fact that the source (despite originally being written for C) is now written primarily for use in C++, thus the documentation and some of the newer functionality is tailored more for C++. This caused some difficulty in writing the code for C as not all C++ functionality was available for C, or was included in a different or outdated fashion.
+
+\subsubsection{Memory Management}
+
+An initial problem I faced when coding in OpenCV was memory leaks. My simple program to take an image and save it to file was causing us to lose approximately 18Mb, which is unacceptable and would cause issues in the long term. After researching the issue I found that I was not properly releasing the structure dealing with storing the image for the data, \type{IplImage}. For example I was using:
+\begin{lstlisting}
+ cvReleaseImage(&frame);
+\end{lstlisting}
+When the correct release function is actually:
+\begin{lstlisting}
+ cvReleaseImageHeader(&frame);
+\end{lstlisting}
+
+Another thing to note was that releasing one of the \type{CvMat} structures (\verb/g_srcRGB/) during the cleanup of the dilatometer module, a \verb/NULL/ pointer exception was returned and the program execution stopped. The reason for this is unknown, but the other \type{CvMat} structures appear to be released properly. For now I simply removed this release; however the cause should be looked into.
+
+\subsubsection{Dilatometer}
+The dilatometer code went through a few iterations. Originally we were informed by the Sensors Team that the camera would be watching the can, rather than object attached to the can. Thus my original algorithms were revolved around finding the actual width and change in width of the can.
+
+Originally I designed the algorithm to find the edge of the can via the pixel thresholds. By finding the average position of the pixels below a certain threshold (as ideally you would have a dark can on a light background to create a contrast for the edge). This would already give a fairly inaccurate result, as it assumes a relatively sharp intensity gradient. Even with little noise the system would have accuracy issues.
+
+To increase the accuracy in finding the edge, I considered the Canny Edge theorem. I wrote my algorithm to find all points above a certain threshold and take the average of these, considering this as an edge. I then scanned through the rest of the image until the next edge was found and do the same. The width of the can is found by taking the difference of the two locations. I also wrote an algorithm to generate these edges so I can test the algorithm. The function (\funct{Dilatometer_TestImage}/, which is still located within \gitref{server}{sensors/dilatometer.c}) generated two edges, with an amount of noise. The edges were created by taking an exponential decay around the edge and adding (and subtracting) a random noise from the expected decay. The edges where then moved outwards using a for loop. The results can be seen in Figure \ref{canny_edges.png}. From the graphs (Figure \ref{}) it can be seen how effective the algorithm was for a system with negligible noise, as it gave negligible percentage error. However with increasing levels of noise we notice a considerable increase in inaccuracy (Figure \ref{canny_edges_noise.png}).
+
+
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\textwidth]{figures/canny_edges.png}
+ \caption{Output of canny edge algorithm applied to generated edges}
+ \label{canny_edges.png}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.9\textwidth]{figures/canny_edges_noise.png}
+ \caption{Output of canny edge algorithm applied to generated edges with generated noise}
+ \label{canny_edges_noise.png}
+\end{figure}
+
+After the Sensors Team relayed that they were now attaching something to the can in order to measure the change position, I decided to simply stick with the Canny Edge algorithm and implement something similar to what I had in my previous testing. The figures in appendix A shows the progression of the image through the algorithm. Figure 2A shows the original image, whereas 2B shows the blurred (with a BLUR value of 5) gray scale image. Whereas figure 2C shows the image after going through the Canny Edge algorithm with a low threshold of 35. Figures 3A and 3B both have the same input image, however different input values. It can be seen how tweaking the values can remove outliers, as figure 3B is skewed to the right due to the outliers. From figure 4 it can be seen that despite there being no points in the edge in the top half of the image, the edge has still been accurately determined.
+
+The testing done shows that given a rough edge with few outliers an edge can be determined, however there is an obvious degree of inaccuracy the greater the variance of the edge. The best solution to this however does not lie in software. If an edge was used that was straight even at that magnification with a good contrast then the results would be much more accurate (i.e. the accuracy of the dilatometer is currently more dependent on the object used than the software).
+
+\subsubsection{Interferometer}
+Earlier in the semester we were informed by the Sensors Team that instead of a dilatometer we would be using an interferometer. The algorithm for this was written and tested; it is currently still located in the file \gitref{server}{interferometer.c} and header \gitref{server}{interferometer.h}. However development of the algorithm ceased after the sensors team informed us that the interferometer would no longer be implemented.
+
+\subsection{Further Design Considerations}
+
+\begin{itemize}
+ \item During testing we noted a considerable degree of lag between the image stream and reality. Further testing can be done to determine the causes and any possible solutions.
+ \item A function to help calibrate the dilatometer should be created
+ \item The algorithm should be tested over an extended period of time checking for memory leak issues caused by OpenCV.
+ \item Possibly modify the code to allow the parameters used in the Canny Edge algorithm to be modified in real time so the user can try and maximize the accuracy of the results. The image with the edge superimposed on it can also be streamed to the client in the same manner as the image, so the user can have feedback.
+
+ \item The algorithm can be improved to try and neglect outliers in the edge image; however this is not as necessary if the original object used gives a sufficiently smooth and straight edge.
+\end{itemize}
+
+% END Callum's section
+
+\subsection{Results}
+
+Figure \ref{image_in_api.png} shows an image obtained from one of two dilatometers used in the system setup with collaboration between all teams. The image is of a white lego tile attached to the can. This image was successfully streamed using the server software, and results of the dilatometer readings were monitored using the same software. Unfortunately we were unable to maintain a constant value for a stationary can, indicating that the algorithm needs further development. Due to a leak in the can seal we were unable to pressurize the can sufficiently to see a noticable change in the edge position.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.6\textwidth]{figures/image_in_api.png}
+ \caption{Microscope image of actual lego tile attached to can in experimental setup}
+ \label{image_in_api.png}
+\end{figure}
+
+
+\section{Human Computer Interaction and the Graphical User Interface}
+
+% BEGIN James' section
+\subsection{Design Considerations}
+
+There are many considerations that are required to be taken into account for the successful creation of a Graphical User Interface (GUI) that allows Human Computer Interaction. A poorly design GUI can make a system difficult and frustrating to use. A GUI made with no considerations to the underlying software can make a system inoperable or block key features. Without a well designed GUI the Human Computer Interaction becomes difficult and discourages any interaction with the system at all.
+
+ One of the key considerations made during the design of the GUI was the functionality it required. Originally this was limited to just allowing for simple control of the system including a start and stop and a display of system pressures however as the project progressed this was expanded to include a user login, limited admin functionality, graphing, image streaming and live server logs. The addition of these features came as a result of changing requirements from the initial brief as well as logical progression of the GUI's capabilities. This gradual progression represents a continual improvement in Human Computer interaction for the system.
+
+ Ease of Use is the most important consideration of all to ensure that a GUI is well designed. Accessibility and user friendliness is a key aspect in web development. Burying key functionality inside menus makes it difficult to find and discourages its use. Making things obvious and accessible encourages use and makes the software quicker to learn which in turn means that the user is able to start doing what they want faster. However there are limits and care has to be taken to make sure that the user isn't bombarded with so many options that it becomes overwhelming for a first time user. Eventually a system of widgets in a sidebar was designed in order to satisfy the ease of use requirements by allowing functionality to be grouped and easily accessible.
+
+ Due to the limits of the Beagle Bone such as available memory and processing power it was important that the code, images and all libraries used were both small in size and efficient. This meant that careful consideration had to be made every time a library was considered for use. It also meant that where possible processing should be offloaded onto the client hardware rather than running on the server which already runs the server side code. This meant large libraries were ruled out and actions such as graphing were performed by the GUI on the client machine.
+
+ The final consideration is extensibility. An extensible software base code allows easy addition of new features. A good extensible interface makes it a simple case of simply dropping the extra code in in order to add extra features whereas a GUI that doesn't take this into account can require deleting and recoding of large chunks of the previous code. This means that the interface code must be structured in a coherent way and all conform to a ``standard'' across the GUI. Code must be laid out in the same way from page to page and where possible sections of code facilitating specific goals should be removed from the main page code. The latter was achieved through the use of the \verb/.load()/ JavaScript function allowing whole widgets to be removed and placed in their own seperate files. This feature alone lets the developer add new widgets simply by creating a widget file conforming to the GUI's standard and then \verb/.load()/ it into the actual page.
+
+\subsection{Libraries used in GUI construction}
+
+These are libraries that we looked at and deemed to be sufficiently useful and as such were chosen to be used in the final GUI design.
+
+\subsubsection{jQuery} \label{jQuery}
+
+jQuery\cite{jQuery} is an open source library designed to make web coding easier and more effective. It has cross-platform and browser support all of the most common browsers. Features such as full CSS3 compatibility, overall versatility and extensibility combined with the light weight footprint made the decision to develop the GUI with this library included an easy one to make.
+
+\subsubsection{Flot}
+
+Flot\cite{flot} is a Javascript library designed for plotting and built for jQuery. This a lightweight easy to use library that allows easy production of attractive graphs. It also includes advanced support for interactive features and can support for $\text{IE} < 9$ . The Flot library provided an easy but powerful way to graph the data being sent by the server.
+
+
+\subsection{Libraries trialed but not used in GUI construction}
+
+These are libraries that were looked at and considered for use in the GUI software but were decided to not be used in the final product.
+
+\subsubsection{jQuery UI}
+
+jQueryUI\cite{jQueryUI} is a library that provides numerous widgets and user interface interactions utilising the jQuery JavaScript library. Targeted at both web design and web development the library allows easy and rapid construction of web application and interfaces with many pre-built interface elements. However this comes with the downside of being a larger library and provides many features that are unnecessary and is as such unfit for use in the GUI.
+
+\subsubsection{chart.js}
+chart.js\cite{chart.js} is an object orientated JavaScript library that provides graphing capabilities on the client side. The library uses some HTML5 elements to provide a variety of ways to present data including line graphs, bar charts, doughnut charts and more. It is a lightweight library that is dependency free however it is lacking on features compared to Flot and did not get used.
+
+\subsection{Design Process for the Graphical User Interface}
+
+As with any coding, following a somewhat strict design process improves efficiency and results in a better end product with more relevant code. Proper planning and testing prevents writing large amounts of code that is latter scrapped. It also provides a more focused direction than can be gleaned off of a project brief.
+
+
+Producing test GUI's with simple functionality allows the developer to experiment and test features without investing a large amount of time and code in something that may not work or solve the required problem. The test GUI's can both functional and aesthetic. Throughout the project a large amount of test GUI's of both types were produced. Aesthetic test GUI's are great for experimenting with the look and feel of the software and allow the developer to experience first hand how the page handles. Functional GUI's on the other hand allow the developer to test out new features and investigate whether the client server interaction is functioning properly.
+
+Whilst producing test GUI's a design document was drawn up. This document encompassed the design goals and specifications for the final Human Computer Interface and provided what was essentially a master plan. Include in the document were things such as what separate pages were to be included, the overall look of the system and what final functionality was desired.
+
+
+Once a design document was completed a Master Template was created. Firstly a draft was created in PowerPoint using Smart Art and can be seen in Figure \ref{draftGUI.png}. After reviewing the draft and accepting the design a HTML template with CSS elements was produced. This template mimics the draft with some added features and improvements as seen in Figure \ref{templateGUI.png}. This was also reviewed and accepted and formed the base code for the GUI.
+
+ With the template completed functionality was then added. By copying the template exactly for each individual page the look of the software is kept the same throughout. Adding functionality is a simple case of substituting in functional code in the demonstration panels as well as adding the necessary JavaScript for the pages to function. Effort was made to keep as much functional code separated from the template itself and to load the code into the page from an external file in order to facilitate cleaner code with better expandability.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/draftGUI.png}
+ \caption{Draft GUI designed in Microsoft Powerpoint}
+ \label{draftGUI.png}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/templateGUI.png}
+ \caption{Screenshot of a GUI using templates to form each panel}
+ \label{templateGUI.png}
+\end{figure}
+
+% END James' section
+
+% BEGIN Rowan's section
+
+\section{GUI Design Process}
+
+\subsection{Creation}
+
+The First iteration of the GUI was a relatively simple and almost purely text based. It held a graph, along with the basic image stream we had developed. It was formatted all down the Left hand side of the page.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_creation.png}
+ \caption{First Test GUI}
+
+\end{figure}
+
+\subsection{Testing}
+
+Secondly we decided to test the FastCGI protocol. Where FastCGI can be used to interface programs with a web server. This was the first test with the use of sensors and actuators theoretically collecting data from a server.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_creation.png}
+ \caption{Testing GUI}
+
+\end{figure}
+
+This gui was running over a free domain name which allowed us to play with control and command.
+
+\subsection{Iterations}
+
+After the basic testing of the initial GUIs we started playing with gui design ideas which would be aesthetic, easy to use and reflect on UWA in a positive way. To do this we looked into how professional websites were made by opening their source code and investigating techniques into layout, structure and style. Then we went away and completed some gui design trees, where there would be a clear flow between pages.
+
+\subsection{Parallel GUI Design}
+
+During the GUI development phase, several GUIs were created. Some used graphical development software, while others used hard codded HTML, JavaScript, and CSS. Due to no organization within the group and a lack in communication a “final gui” was made by several of the team members. Some of theses are shown below.
+
+\subsection{GUI Aesthetics}
+
+Once we had decided on our core GUI design, we decided that, although not yet complete we would get Adrain Keatings opinion on the GUI design. While the gui design was simple and functional Dr. Keating pointed out the design was bland. He encouraged us to release our artistic flair onto our GUI and make it more graphical and easy to use. Taking this into account we Began work on another final GUI designing almost from scratch. We kept our GUI design flow, and worked largely on the look and feel of the GUI rather the functionality the gui needed.
+
+\subsection{HTML Structure}
+
+The way our GUI works, in a nutshell, is that we use Basic HTML code to lay out what the page needs, then we have CSS(Styles) on top which lays out and formats the basic HTML code. We the put JavaScript files into the HTML code so that graphs and images and be streamed. In out GUI we have chosen to use JQuery to ask the server for information from the client and jFlot for javascripts graphing functionality.
+
+\subsection{Graphical Development VS Hard Coding}
+
+From the Multiple GUI we had accidently created during the GUI design phase we noticed a large Varity in the styles of GUIs that came out (Which shouldn’t of happened) GUIs were created using HTML CSS and JavaScript being hard codded, from development software like Dreamweaver, and various java based development platforms.
+
+\subsection{Final Design}
+
+The final concept consists of widgets and a navigation bar to the left. We decided for the maximum functionality we could get with the time remaining we would have pages for; Control, Graphs, Data, Data streaming, Pin debugging, and a help screen, shown below.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_final.png}
+ \caption{Final GUI}
+\end{figure}
+
+This is the ``home screen'' it shows the layout of the experiment, the subsystem and a welcome message.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_experiment.png}
+ \caption{The Experiment (While disconnected from the server in the pic above) displays the Warnings and the experiment state to allow device use by only 1 student and avoid nasty conflicting control}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_results.png}
+ \caption{The Experimental Results page (also currently disconnected)}
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_data.png}
+ \caption{The experimental data page shows the start the sensors and actuators are reading, useful for checking the condition and measuring the experiment. }
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_pintest.png}
+ \caption{The BBB Pin test page is for the software team only so that we can test and debug the experiment we errors are found in the gui or software. }
+\end{figure}
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/gui_help.png}
+ \caption{The help page, which links to the wiki information from all the teams and allows new users to look at all aspects of the project to be further developed and finished. }
+\end{figure}
+% END Rowan's section
-\chapter{Introduction}
+\chapter{Introduction and Approach}
-\section*{Abstract}
+% BEGIN Justin's section
-\section{Objectives}
+The following report describes the work of the software team on the MCTX3420 pressurised can project during Semester 2, 2013 at UWA. The report is intended to assist others in comprehending the decisions and processes involved, as well providing a tool for further development of the system. The report serves as a record of the planning, design, coding, testing and integration of the system, with specific reference to the development of the system software. Extensive documentation is also provided via a project wiki\cite{mctx3420_wiki}.
-\section{Constraints}
+The MCTX3420 project aimed to build an experimental apparatus for measuring the behaviour of a container with pressure --- in this case, testing how a drink can deformed as air pressure inside it increased. The desired result was a self-contained, safe, reliable, effective and easy-to-use system which could perform the desired experimental tasks, to be used by both students and wider industry professionals.
+
+Unfortunately, the system is (as of 1st November 2013) still not complete; the hardware components have not been fully tested and integrated with the software, despite extensive work by all students. However, the project is very close to completion. The software can interact in the desired manner with the hardware components, and fulfils the majority of the required functionality. With some further testing and development using the final hardware, the software could easily be implemented --- and the report has been written with this in mind, allowing another group in the future to build upon the project software.
+
+The report begins with an overview of the whole system and the design of the software component. Each subsection then focuses on a specific aspect of the software, going into detail about its design, development, functionality, testing, and integration. Following this, there are sections focusing on the administrative aspects of the project, including teamwork, the general development process, and costs. The report concludes with some documentation of the software and recommendations for future development.
\section{System Overview}
+To aid understanding of the context of the software project, a brief overview of the system as a whole is presented below. Essentially, the MCTX3420 project apparatus is designed to test the behaviour of a pressure vessel as air pressure inside it is gradually increased. A very basic system diagram showing the main components is shown in Figure \ref{system_overview.png}, with control components in \textcolor{red}{ red}, electronics in \textcolor{green}{ green}, sensors in \textcolor{Purple}{ purple}, pneumatics in \textcolor{blue}{ blue}, and experimental targets in \textcolor{Orange}{ orange}.
+
+\begin{figure}[H]
+ \centering
+ \includegraphics[width=0.8\textwidth]{figures/system_overview.png}
+ \caption{Block diagram of the physical system}
+ \label{system_overview.png}
+\end{figure}
+
+\subsection{Experimental Procedure}
+
+The general experimental procedure is to increase the pressure inside a pair of pressure vessels (in this case, drink cans), measuring one's deformation behaviour and measuring the other to failure point. The user does this by logging into a web browser interface, starting a new experiment, and increasing system pressure in the desired fashion.
+
+As pressure is increased, the web browser passes this instruction to the system controller, which manipulates the pneumatic pressure regulators to input correct pressure to the measured can. While doing this, the system controller also reads from a collection of sensors and returns this data to the web browser (strain, pressure, dilatometer deformation, visual images). The vessel's deformation with pressure can then be characterised.
+
+This continues until the desired final pressure is reached. Then, pressure in the failure can may be increased further until that can reaches its failure point. The experiment then ends and the system is returned to room pressure. The user can view and download the resulting data.
+
+\subsection{Components}
+
+The main areas of the system are as follows:
+
+\begin{itemize}
+ \item {\bf Control:} The experiment is controlled through web browser interface from a client PC. This web interface connects to a server running on what is effectively a small, integrated PC --- the ``BeagleBone Black'' --- and this server directly controls the experiment hardware and reads the sensor data, providing a low-level interface to the system's electronics. The BeagleBone itself is situated inside the experiment case, and the client PC connects to the BeagleBone server through the local network.
+ \item {\bf Electronics:} Because the system features a large array of electronic components, these must be run through a central filtering and amplification system to ensure that correct voltages and currents are provided. There is a circuit board inside the case which performs this task. The board connects the BeagleBone, pneumatics, sensors, and power supply to facilitate system operation. System power is provided by a PSU connected to the mains.
+ \item {\bf Pneumatics:} The system's pneumatics feed the desired air pressure into the two pressure vessels being tested. Air is fed through a series of pipes from the laboratory's pressurised air supply; solenoid valves control on/off air flow through the system, while pressure is controlled via regulators. Exhaust valves are provided for venting the system. Pneumatics are controlled by the BeagleBone, with signals fed through the electronics board.
+ \item {\bf Sensors:} A suite of sensors is used to collect system data and measure the deformation of the pressure vessel. The sensors include strain gauges, pressure sensors, a microphone, a dilatometer/microscope, and a camera --- these give a comprehensive set of data to match the can's deformation to the pressure level. Each sensor has a different output and must be conditioned by the central electronics board before its data is recorded by the BeagleBone.
+
+ \item {\bf Mounting and Case:} The mounting system for the cans uses a screw-in mechanism to achieve an airtight seal. This holds the can in place so that pressure can be fed into it through the base of the mount. The system case holds all of the components in a sealed protective compartment, which ensures that the system will be safe in the event of failure and physically separates the various systems. The case also features an interlock switch that prevents any operation of the system if the lid is not fastened.
+
+\end{itemize}
+
+The system software essentially is defined by the “control” component: allowing a user to control the experiment hardware. To do this, the software must successfully interface with all of the system areas above so that the desired experiment can be run.
+
+\section{Development Process}
+
+The development process is outlined below. Each part of the software followed the same general process, which is discussed in more detail for each section later in the report.
+
+\subsection{Planning and Design}
+First, the actual software task to be completed is identified; this is organised with group input. The software component is then designed according to the requirements. Parameters and features are chosen based on the project guidelines and how the component interacts with other software.
+
+\subsection{Coding}
+
+Each section is then actually written. Most of the initial work is done individually (for consistency) and completed in between meetings. At group meetings the code is presented, and may be edited by other team members to fix issues, increase efficiency, and integrate it with other code sections.
+
+
+Extremely important to development was the use of the Git system\cite{github,gitucc} and GitHub website\cite{github}. GitHub is specially designed for software use and is essentially a web-based hosting service for development projects, which uses the Git revision control system. It allows all team members to contribute to the same project by working on their own local ``forks'', and then ``merging'' their changes back into the main branch of software\cite{github_fork}.
+
+The Git system ensures that work by different team members is tracked\cite{github_contribs}, that work fits together consistently, and that other work is not accidentally overwritten or changed (important when dealing with large amounts of code). Git also features a notifications and issue tracking system with email alerts whenever a change is made. The basic GitHub process is as follows:
+
+\begin{enumerate}
+ \item Create an individual ``fork'' of the software, separate from the main branch.
+ \item Modify this fork on a local machine with proposed changes or additions. This fork is also updated regularly with any changes that were made in the main branch.
+ \item When work is complete, create a ``pull request'' to merge local changes back into the main codebase.
+ \item The pull request can be reviewed by other team members; if everything fits, the request is accepted and the local changes become part of the main code.
+\end{enumerate}
+In this way, GitHub automates the more tedious aspects of code management.
+
+Another important aspect of the coding process is coding style. Throughout the project, all code that was written adhered to the same style to make it consistent and easier to read. One aspect of styling, for example, is use of capitals when defining function names (for example, \funct{Actuator_Init}), variable names (\var{g_num_actuators}), or definitions of constants (\var{ACTUATORS_MAX}), to make it immediately clear whether something is a function, variable or constant. Other aspects include use of indentation, the ordering of functions, and frequent use of comments. Essentially, styling is used to ensure the code is consistent, easy to follow, and can therefore be worked on by multiple people.
+
+Coding style is also important when following general code standards. The C language features many standards and style guidelines which were also adhered to, to make the code readable by wider industry professionals. Some examples of this include beginning global variables with \texttt{g_} and correct use of brackets as separators\cite{mellon}. All efforts were made to follow common C and HTML code standards. The use of a common coding style and standards will hopefully make the project software easily expandable by others in the future.
+
+
+Code was also expected to adhere to safety standards. In the first weeks of the project, a document\cite{kruger_safety} was created that outlined all aspects of software safety - both for the software design itself, and ensuring that the system was still safe if the software failed. The results of this are explained further later in the report, with one example being the server's ``sanity check'' functions.
+
+\subsection{Testing}
+
+Once the software section is relatively complete, it can be tested with the larger codebase. This was generally done through writing specific test functions. Because the operating system on the BeagleBone (GNU/Linux) is widely available for commercial PCs and laptops, software development and testing could occur without needing to wait for a BeagleBone to become available. Code was also tested on the BeagleBone itself where possible to ensure correct operation. One example is for the sensors software - initially, functions were written that simulated sensors, so it could be tested if data was read correctly. These functions were rewritten for use with actual hardware as the specifics became known later in the project.
+
+\subsection{Collaboration}
+After the testing process is satisfied, the final code can be committed to the system. This requires input from the other project teams. If there is any feedback or the requirements change in the future, the code can be edited through the above process.
+
+\section{Team Collaboration}
+
+Collaboration between members of the software group was extremely important throughout the project. Members were often individually responsible for different areas of software --- or, alternately, were simultaneously rewriting different sections of the same code --- so it was essential to make sure that all parts were compatible, as well as completed on schedule. Communication between the software group and other project groups was similarly vital, to ensure that all work contributed to the project's end goals.
+
+\subsection{Communication} \label{Communication}
+The primary time for collaboration was during the team's weekly meetings. Meetings occurred at 2pm-4pm on the Monday of every week, and were generally attended by all group members. While most work was expected to be done outside this time, the meetings were valuable for planning and scheduling purposes, for tackling problems and making design decisions as a group. Team members were able to work together in the meetings to complete certain tasks much more effectively. Importantly, at the end of each meeting, a report of the work done during the prior week and a list of tasks to do the following week was produced, giving the project a continuous, clear direction.
+
+GitHub was used as the group's repository for software work. The usefulness of GitHub was explained previously in the “General Development Process” section, but essentially, it is a very effective tool for managing and synchronising a large, multi-person software project. GitHub also features a notifications and issue-tracking system, which was useful for keeping track of tasks and immediately notifying team members of any changes.
+
+
+Outside of meetings, email was the main form of communication. Email threads exist for all of the project's main areas, discussing any ideas, changes or explanations. Email was also used for announcements and to organise additional meetings. For less formal communication, the software group created their own IRC channel. This was essentially a chat channel that could be used to discuss any aspect of the project and for communication about current work.
+
+\subsection{Scheduling}
+
+At the beginning of the project, an overall software schedule was created, outlining the main tasks to be completed and their target dates. While this was useful for planning purposes and creating an overall impression of the task, it became less relevant as the semester continued. The nature of the software team's work meant that it was often changing from week to week; varying hardware requirements from other teams, unexpected issues and some nebulous project guidelines led to frequent schedule modifications. For instance: use of the BeagleBone turned out to be a significant time-sink, requiring a lot of troubleshooting due to lack of documentation; and a sophisticated login system was not mentioned until late in the project, so resources had to be diverted to implement this. Essentially, while the software group did attempt to keep an overall schedule, this was only useful in planning stages due to the changing priorities of tasks.
+
+
+Far more useful was the weekly scheduling system. As mentioned in the ``Communication'' section\ref{Communication}, a weekly task list was created on each Monday, giving the team a clear direction. This suited the flexibility of the software well; tasks could be shuffled and re-prioritised easily and split between team members. It was still very important to keep the project's overall deadline in mind, and the weekly task lists could be used to do this by looking separately at the main areas of software (such as GUI design, sensors, and so on) and summarising the remaining work appropriately. Brief weekly reports also covered what had been completed so far, providing a further measure of progress.
+
+
+The group also elected a ``meeting convener'' to assist with organisation (Samuel Moore). The meeting convener was responsible for organising group meetings week-to-week and coordinating group communication. A single elected convener made this process as efficient as possible.
+
+\subsection{Group Participation}
+
+The nature of software development means that it tends to be very specialised --- extensive knowledge of coding is required to be effective, which is difficult to learn in a short timeframe. The members of the software team all had varying levels of experience, and therefore could not contribute equally to all areas of the project. Some team members had done very little coding before (outside of introductory units at university) which made it difficult for them to contribute in some areas, while others had the extensive knowledge required.
+
+
+However, different team members had skills in other areas besides coding, and these skills were allocated to ensure that all members could contribute effectively. For instance, as some people worked on the server code, others worked on the visual GUI design; it made sense for the people who were most efficient with coding to work on those elements while others performed different tasks. Even though the software project was principally coding, there were many supplementary development tasks --- writing documentation, hardware testing, et cetera --- that were involved. Some areas of the software, such as the BeagleBone interfacing, were new to all team members and were worked on by everyone.
+
+
+On the whole, group participation was good. Team members regularly attended meetings, did the expected (often more-than-expected) work, and had a good understanding of the project. While all team members contributed significantly, some did stand out --- in this case Samuel Moore and Jeremy Tan, who performed a large portion of the vita development work. Without their input and prior experience, the project would not have been completed to such a high standard, and their extensive skills and dedication were vital to its success.
+
+\subsection{Inter-Team Communication}
+
+Communication between the various project teams was also essential: the software had to be able to interact with nearly all aspects of the hardware via the BeagleBone system controller. A weekly Tuesday meeting was therefore set up specifically for inter-team communication, so information could be exchanged between project groups. For the software team most communication was with the electronics, sensors and pneumatics teams, as these three hardware areas are all directly controlled by the software. The fact that the software can interact with these systems should be evidence that communication was relatively effective.
+Many other meetings also occurred between the software group and others. Extensive time was spent with the electronics team, testing and setting up the BeagleBone with the appropriate inputs and outputs. Other meetings also occurred with the sensors team to select sensors and cameras that were compatible with the software. Practical sessions with the pneumatics, sensors and electronics teams also occurred, in which the software was tested with the hardware to ensure that both systems were operating correctly.
+
+
+Email was used extensively for other communication. All members of the unit were involved in this, providing input on hardware designs or organising meeting times for testing, and though email was often less effective that face-to-face communication (other teams sometimes did not respond promptly) it was still useful tool. In addition, an MCTX3420 DropBox was set up as a common repository for any project-related files. This was updated often and proved to be a useful reference. The software team chose to keep their work on GitHub rather than DropBox, and the GitHub repository was made publicly accessible so that work could be shared.
+
+\subsection{Individual Contributions}
+
+Software project tasks were divided up between team members, and in this report, each team member has generally been the writer of the sections they actually worked upon. Throughout the project, team members had clear areas of responsibility, and their work can also be followed through the GitHub repository (which allows tracking of individual contributions to the codebase). Below is a rough summary of individual areas of interest:
+
+\begin{tabular}{l|l}
+ {\bf Team Member} & {\bf Development} \\
+ Samuel Moore & Server coding, BeagleBone interface, GUI implementation, hardware testing \\
+ Jeremy Tan & Server coding, BeagleBone interface, GUI implementation, hardware testing \\
+ Callum Schofield & Image processing, BeagleBone interface, hardware testing \\
+ James Rosher & Overall GUI design, GUI implementation \\
+ Justin Kruger & BeagleBone interface, GUI implementation, documentation \\
+ Rowan Heinrich & GUI implementation, hardware testing
+\end{tabular}
+
+It should also be noted that team members often helped each other with designing, problem solving and testing, so members did end up contributing in some way to most areas of the software.
+
+
+Server coding tasks included the threading system, data handling, sensors/actuators control, authentication, server/client communication, http/s use, FastCGI, AJAX and the server API, which were split mainly by Sam and Jeremy (with significant overlap). BeagleBone interfacing included hardware access, pin control, networking and testing, and involved most members of the team. Sam, Jeremy and Justin focused on pin control, Jeremy and Callum investigated webcam use, and Rowan performed additional testing. GUI design involved the visual design elements, HTML/CSS webpage coding and Javascript functionality. James was primarily in charge of the GUI design, functionality and implementation, with assistance and alternate designs provided by Jeremy. Other team members were responsible for individual GUI sections, including Sam (graphs), Justin (help and data) and Rowan (widgets). Other tasks included image processing with OpenCV (Callum) and project documentation and safety (Justin).
+
+\subsection{Cost Estimation}
+
+The vast majority of the cost of the software team's contribution is in man-hours rather than hardware. The only hardware specifically purchased by software was a BeagleBone Black; all other hardware was part of electronics. Some hardware used for testing was temporarily donated by team members, and has been included here only for completeness.
+
+\begin{tabular}{l|l}
+ {\bf Item} & {\bf Cost} \\
+ BeagleBone Black & \$45 \\
+ LinkSys Router (testing) & \$50 \\
+ Logitech Webcam (testing) & \$25 \\
+ Ethernet and other cabling (testing) & \$10 \\
+ \emph{Total} & \$130
+\end{tabular}
+
+In regards to the time spent, it is difficult to get an accurate record. At least three hours per week were spent in weekly meetings, and by consulting the team's technical diaries, it is estimated that team members spent an average of ten hours per week working on the project.
+
+\begin{tabular}{l|l}
+ Approximate time per week (individual) & 10 hours \\
+ Team size & 6 people \\
+ Approximate time per week (team) & 60 hours \\
+ Project Duration & 13 weeks \\
+ Total time spent & 780 hours \\
+ Hourly rate & \$150 / hour \\
+ Total cost & \$117,000 (+\$130 for hardware)
+\end{tabular}
+
+This is a large amount at first glance, though it must be remembered that this was a complex software development project with many interacting parts. There were some inefficiencies which did unfortunately add to cost (such as the BeagleBone's lack of documentation) and these could hopefully avoided in the future. Given the final result, however, the cost appears reasonable.
+
-\subsection{Pneumatics}
-\subsection{Electronics}
-\subsection{Sensors}
-\subsection{Mounting}
-\subsection{Case}
-\subsection{Software}
+The GitHub repository was also run through an online cost estimator\cite{ohloh}, which resulted in a similar number of ~\$100,000. The estimator takes into account the number of developers, time of development, and amount of code produced.
-The remainder of this report will focus on the software design.
+% END Justin's section
-\chapter{Results}
+\chapter{Conclusions and Recommendations}
+
+This report has described the work of the software team on the MCTX3420 pressurised can project during Semester 2, 2013 at UWA.
+In summary, we have succeeded in the following goals:
+
+\begin{enumerate}
+ \item Design and implementation of a multithreaded process for providing continuous control over real hardware in response to intermittent user actions (Section \ref{Server Program}, \ref{Hardware Interfacing})
+ \item Design and implementation of a configuration allowing this process to interface with the \emph{nginx} HTTP server (Sections \ref{Communications}, \ref{Server Configuration}
+ \item Design and implementation of a API using the HTTP protocol to allow a client process to supply user commands to the system (Section \ref{Communications})
+ \item Design and implementation of the client process using a web browser based GUI that requires no additional software to be installed on the client PC (Section \ref{Communications}, \ref{GUI})
+ \item Design and implementation of several alternative authentication mechanisms for the system which can be integrated with different user management solutions (Section \ref{Authentication})
+ \item Partial design and implementation of a system for managing the datafiles of different users (Section \ref{API})
+ \item Partial design and implementation of a user management system in PHP based upon UserCake (Sections \ref{Authentication}, \ref{Cookies})
+ \item Integration and partial testing of the software with the overall MCTX3420 2013 Exploding Cans project (All sections)
+\end{enumerate}
+
+We make the following general recommendations for further development of the system software (with more specific recomendations discussed in the relevant setions):
+\begin{enumerate}
+ \item That the current software is built upon, rather than redesigned from scratch. The software can be adapted to run on a Raspberry Pi, or even a GNU/Linux laptop if required.
+ \item That more detailed testing and debugging of several aspects of the software are required; in particular:
+ \begin{enumerate}
+ \item The software should be tested for memory leaks by running for an extended time period
+ \item Any alternative image processing algorithms should be tested independently of the main system and then integrated after it is certain that no memory errors remain
+ \end{enumerate}
+ \item That work is continued on documenting all aspects of the system.
+ \item That the GitHub Issues page\cite{github_issues} is used to identify and solve future issues and/or bugs
+ \item That members of the 2013 software team are contacted if further explanation of any aspect of the software is needed.
+\end{enumerate}
+
+We would also like to make the following recommendations with regard to system hardware:
+\begin{enumerate}
+ \item Care is given to protecting the BeagleBone from electrical faults (eg: overloading or underloading the ADC/GPIO pins, a power surge overloading the supply voltage)
+ \item A mechanism (possibly employing a high value capacator) is included to allow a loss of power to be detected and the BeagleBone shut down safely
+\end{enumerate}
-\section{Results}
-
-\subsection{Calibration}
-
-\subsection{Server Performance}
-
-\subsection{Customer Satisfaction}
-
-No matter what we did, no one was satisfied.
-
-\section{Conclusion}
-
-
-\section{Recommendations}
note = "UWA Reference guide"
}
+@misc{mctx3420_wiki,
+ author = "Justin Kruger and Sam Moore and Jeremy Tan",
+ year = 2013,
+ title = "MCTX3420 Project Wiki",
+ howpublished = "\url{https://github.com/szmoore/MCTX3420/wiki}"
+}
+
+@misc{github_fork,
+ author = "GitHub",
+ year = 2013,
+ title = "Fork a Repo"
+ howpublished = "\url{https://help.github.com/articles/fork-a-repo}"
+}
+
+@misc{mellon,
+ author = "Carnegie Mellon University",
+ title = "C Coding Standards",
+ howpublished = "\url{http://users.ece.cmu.edu/~eno/coding/CCodingStandard.html}"
+}
+
+@misc{ohloh,
+ author = "Ohloh",
+ year = 2013,
+ title = "MCTX3420 Project Summary",
+ howpublished = "\url{http://www.ohloh.net/p/MCTX3420}"
+}
+
+@misc{kruger_safety,
+ author = "Justin Kruger",
+ title = "Safety Systems - General Outline",
+ year = 2013,
+ month = "August"
+ howpublished = "\url{https://github.com/szmoore/MCTX3420/blob/master/notes/Safety\%20Systems\%20-\%20general\%20outline.docx}
+}
+
@misc{UserCake,
author = "Tyson et. al"
year = 2012
@misc{github,
author = "Sam Moore and Jeremy Tan and Justin Kruger and Callum Schofield and James Rosher and Rowan Heinrich",
year = 2013,
- title = "MCTX3420 2013 Git Repository on GitHub",
+ title = "MCTX3420 2013 Git Repository at GitHub",
howpublished = "\url{https://github.com/szmoore/MCTX3420}"
}
+@misc{gitucc,
+ author = "Sam Moore and Jeremy Tan and Justin Kruger and Callum Schofield and James Rosher and Rowan Heinrich",
+ year = 2013,
+ title = "MCTX3420 Git Repository at UCC",
+ howpublished = "\url{http://git.ucc.asn.au/?p=matches/MCTX3420.git}"
+}
\documentclass[a4paper,10pt,titlepage]{report}
-\linespread{0.9}
-\usepackage{setspace}
-%\onehalfspacing % 1.5 spacing is uuuglly
- \parskip 15pt % sets spacing between paragraphs
+%\linespread{1.3}
+%\usepackage{setspace}
+%\onehalfspacing
+ \parskip 10pt % sets spacing between paragraphs
%\renewcommand{\baselinestretch}{1.5} % Uncomment for 1.5 spacing between lines
- \parindent 8pt % sets leading space for paragraphs
+ %\parindent 0pt % sets leading space for paragraphs
%\usepackage{natbib}
\usepackage{caption}
%\usepackage{subfigure}
\usepackage{rotating}
-%\usepackage{lscape} % Needed for landscaping when printing
+%\usepackage{lscape}
\usepackage{pdflscape} % Needed for landscaping - in pdf viewer
\usepackage{verbatim}
\usepackage{amsmath, amsthm,amssymb}
\titleformat{\chapter}
{\normalfont\LARGE\bfseries}{\thechapter.}{1em}{}
-\usepackage{color}
-\usepackage{listings}
+\usepackage[usenames,dvipsnames]{color}
+\usepackage{listings} % For code snippets
\definecolor{darkgray}{rgb}{0.95,0.95,0.95}
\definecolor{darkred}{rgb}{0.75,0,0}
\lstset{showstringspaces=false}
\lstset{basicstyle=\small}
+
+
+\newtheorem{theorem}{Theorem}[section]
+\newtheorem{lemma}[theorem]{Lemma}
+\theoremstyle{definition}\newtheorem{definition}[theorem]{Definition}
+\newtheorem{proposition}[theorem]{Proposition}
+\newtheorem{corollary}[theorem]{Corollary}
+\newtheorem{example}{Example}
+\theoremstyle{remark}\newtheorem*{remark}{Remark}
+
+\newcommand{\Phid}[0]{\dot{\Phi}}
+\newcommand{\Phib}[0]{\bar{\Phi}}
+
+\newcommand{\de}[0]{\delta}
+\newcommand{\deb}[0]{\bar{\delta}}
+
+\newcommand{\that}[0]{\hat{\theta}}
+
+\newcommand{\vect}[1]{\boldsymbol{#1}} % Draw a vector
+\newcommand{\divg}[1]{\nabla \cdot #1} % divergence
+\newcommand{\curl}[1]{\nabla \times #1} % curl
+\newcommand{\grad}[1]{\nabla #1} %gradient
+\newcommand{\pd}[3][ ]{\frac{\partial^{#1} #2}{\partial #3^{#1}}} %partial derivative
+\newcommand{\der}[3][ ]{\frac{d^{#1} #2}{d #3^{#1}}} %full derivative
+\newcommand{\phasor}[1]{\tilde{#1}} % make a phasor
+\newcommand{\laplacian}[1]{\nabla^2 {#1}} % The laplacian operator
+
+
+
+% Reference things in GitHub
+\newcommand{\gitref}[2]{\href{https://github.com/szmoore/MCTX3420/blob/master/#1/#2}{ \textcolor{blue}{\emph{#2}}}}
+% Refer to API commands
+\newcommand{\api}[1]{ ``\textcolor{black}{\texttt{/api/#1}}''}
+
+% To make underscores printable without escaping them
+\usepackage[T1]{fontenc}
+\catcode`\_=12
+
+% Refer to code (can change each one as needed)
+\newcommand{\funct}[1]{ \texttt{#1}}
+\newcommand{\var}[1]{ \texttt{#1}}
+\newcommand{\type}[1]{ \texttt{#1}}
+\newcommand{\code}[1]{ \texttt{#1}}
+
+
%\usepackage{endfloat}
%\nomarkersintext
- \topmargin -1.5cm % read Lamport p.163
- \oddsidemargin -0.04cm % read Lamport p.163
- \evensidemargin -0.04cm % same as oddsidemargin but for left-hand pages
- \textwidth 16.59cm
- \textheight 23.94cm
- %\pagestyle{empty} % Uncomment if don't want page numbers
- \parskip 6.2pt % sets spacing between paragraphs
- \renewcommand{\baselinestretch}{1.5} % Uncomment for 1.5 spacing between lines
- \parindent 0pt % sets leading space for paragraphs
+\pagestyle{plain}
+\topmargin -0.6true in
+\textwidth 15true cm
+\textheight 9.5true in
+\oddsidemargin 0.25true in
+\evensidemargin 0.25true in
+\headsep 0.4true in
\usepackage{fancyheadings}
\pagestyle{fancy}
\include{titlepage/Titlepage} % This is who you are
+%\newpage
+
+%\include{acknowledgments/Acknowledgments} % This is who you thank
+
+%\newpage
+
+%\include{abstract/Abstract} % This is your thesis abstract
+
\pagenumbering{roman}
\newpage
%---------------------------------------------------------
% Do the table of Contents and lists of figures and tables
%---------------------------------------------------------
+\linespread{0.8}
\tableofcontents
\markboth{}{}
+\linespread{1.0}
\newpage
\pagenumbering{arabic}
%---------------------------------------------------------
%Include the chapters!
-%\include{chapters/Demonstration}
\include{chapters/Introduction}
-\include{chapters/Approach}
-\include{chapters/Design}
+
+\include{chapters/Design} % This is chapter 1
+
+%\include{chapters/Approach} % This is chapter 2
+
\include{chapters/Results}
%\newpage
%---------------------------------------------------------
\renewcommand{\bibname}{References}
\bibliography{references/refs}
-%\bibliographystyle{apalike}
+\bibliographystyle{ieeetr}
\addcontentsline{toc}{part}{References}
%---------------------------------------------------------
% Appendices
+\appendix
+\include{appendices/glossary}
+%\include{proposal/proposal.tex}
+%\renewcommand\chaptername{Appendix}
+%\chapter{Appendix}
+%\include{appendices/electron_optics}
+%\include{appendices/electron_gun_circuit}
+%\include{appendices/tcs_noise}
+%\include{appendices/data_aquisition}
+
%---------------------------------------------------------
{
// Find the rate of expansion and convert to mm. Will give a negative result for compression.
*value = (average - lastPosition) * SCALE *2;
- lastPosition = average; // Current position now becomes the last position
}
+ lastPosition = average; // Current position now becomes the last position
return result;
default:
return false; }
--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
+<html>
+ <head>
+ <title>MCTX3420 Web Interface</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
+ <!--[if lte IE 8]>
+ <script language="javascript" type="text/javascript" src="static/excanvas.min.js"></script>
+ <![endif]-->
+ <script type="text/javascript" src="static/jquery-1.10.1.min.js"></script>
+ <script type="text/javascript" src="static/jquery.flot.min.js"></script>
+ <script type="text/javascript" src="static/mctx.gui.js"></script>
+ <script type="text/javascript" src="static/mctx.control.js"></script>
+
+ <link rel="stylesheet" type="text/css" href="static/style.css">
+ <link rel="stylesheet" type="text/css" href="static/nav-menu.css">
+ <script type="text/javascript">
+ $("#camera").setCamera();
+ </script>
+ </head>
+
+ <body>
+ <div id="header-wrap">
+ <div id="header">
+ <div id="leftnav">
+ <a href="http://www.uwa.edu.au/" target="_blank">
+ <img alt = "The University of Western Australia"
+ src="static/uwacrest-text.png">
+ </a>
+ <span id="title">Exploding Cans</span>
+ </div>
+ <div id="rightnav">
+ <span id="welcome-container">
+ </span>
+ <span id="date">
+ <script type="text/javascript">getDate();</script>
+ </span>
+ <div id="logout-container">
+ <form action="#">
+ <div>
+ <input type="button" id="change-password" value="Change password">
+ <input type="button" id="logout" value="Logout">
+ </div>
+ </form>
+ </div>
+ </div>
+ <div class="clear"></div>
+ </div>
+ </div>
+ <!-- End header -->
+
+ <div id="content-wrap">
+ <noscript>
+ <div class="widget centre">
+ <div class="title">JavaScript required</div>
+ This website requires JavaScript to function correctly.
+ Please enable JavaScript to use this site.
+ </div>
+ </noscript>
+
+ <div id="content">
+ <div class="widget" id="sidebar-show">></div>
+ <div id="sidebar">
+ <div class="widget">
+ <div id="sidebar-hide"><</div>
+ <div class="title">Navigation menu</div>
+ <div id="sidebar-menu" class="nav-menu">
+ <ul>
+ <li><a href="index.html"><span>Home</span></a></li>
+ <li><a href="control.html"><span>Experiment control</span></a></li>
+ <li><a href="graph.html"><span>Experiment graphs</span></a></li>
+ <li><a href="values.html"><span>Experiment data (live)</span></a></li>
+ <li><a href="data.html"><span>Experiment data</span></a></li>
+ <li><a href="pintest.html"><span>Pin debugging</span></a></li>
+ <li class="last"><a href="help.html"><span>Help</span></a></li>
+ </ul>
+ </div>
+ </div>
+ </div>
+ <!-- End sidebar -->
+
+ <div id="main">
+ <div id="image-widget" class="widget">
+ <div class="title">Image</div>
+ <img id="camera" alt="camera">
+ </div>
+ </div>
+ <!-- End main content -->
+ </div>
+ </div>
+ </body>
+</html>
});
};
+/**
+* Sets the camera autoupdater
+* Obsolete?
+* @returns {$.fn}
+*/
+$.fn.setCamera = function () {
+ var url = mctx.api + "image"; //http://beaglebone/api/image
+ var update = true;
+
+ //Stop updating if we can't retrieve an image!
+ this.error(function() {
+ update = false;
+ });
+
+ var parent = this;
+
+ var updater = function() {
+ if (!update) {
+ parent.parent().text("Cam fail");
+ parent.attr("src", "");
+ return;
+ }
+
+ parent.attr("src", url + "#" + (new Date()).getTime());
+
+ setTimeout(updater, 2000);
+ };
+
+ updater();
+ return this;
+};
+
+
+
/**
* Sets the error log to continuously update.
* @returns itself */
git.ucc.asn.au / matches / MCTX3420.git / commitdiff
UCC git Repository :: git.ucc.asn.au
