08:59 -!- Callum_ [
[email protected]] has quit ["AndroIRC - Android IRC Client ( http://www.androirc.com )"]
+--- Day changed Sun Aug 11 2013
+14:09 < Callum__> actually so much work to do already.
+14:47 < sam_moore> Yep
+15:15 < Callum__> well iv spent some time thinking over this, finally get around to writing it down. so iv probably spent close to 4 hours or so thinking about it (while doing other things) but really only spent an hour and a half according to diary
+15:25 < sam_moore> We can always flesh out people's reports with graphs and stuff
+15:27 < Callum__> well we doing 1 per person or group?
+15:29 < sam_moore> 1 per person is the safest way to go I think
+15:29 < sam_moore> We can always summarise them
+15:30 < Callum__> well, tbh i think we should do 1 per person and summarise, but not necessarily go for a full page. thing is not sure how they expect us to do 1 page for 5 people AND be detailed
+15:30 < sam_moore> Yep
+15:31 < Callum__> so they might end up making it 1 per person anyway.
+15:31 < Callum__> not very well thought out either way
+15:31 < sam_moore> Let's just submit a multiple page report, with a bit from each person and a summary. If some people have less than a page that's fine.
+15:32 < Callum__> Yea, agreed thats the best way to go about it. Unless they complain about it being too long
+15:32 < sam_moore> That's why we include a summary :P
+15:33 < sam_moore> Although, it might be difficult to make the summary actually summarise things, since everyone's already using pretty concise summaries
+15:33 < sam_moore> Oh well, writing more stuff is safer to start with.
+15:34 < Callum__> hmm. its kind of a pain though, write it all down in your book...oh look now i need to rewrite most of it for a report..
+15:34 < sam_moore> Ah crap, I forgot about the book
+15:34 < Callum__> haha
+15:34 < sam_moore> Yeah... write it all down in the git commit messages, write it all down in the report, write it all down in the diary...
+15:35 < sam_moore> I suppose in the "Real World" you have to do stuff like this
+15:35 < Callum__> yea true
+18:16 < Callum__> Not sure when il get round to writing what i'v done but il do it tonight some time. We finalising it tomorrow and printing it off then?
+18:27 < sam_moore> Yes, I'd like to have it done before the meeting, or at least do it first thing in the meeting
+18:27 < sam_moore> Then there are some things I need to ask everyone about to progress with my part of the code
+18:27 < sam_moore> Since I'm sort of doing the bit in the middle that gets all the other bits to talk to each other
+18:28 < sam_moore> I think it would be good to keep all the raspberry pi code in a single process, running in seperate threads
+18:29 < sam_moore> But to do that we'd need everyone to use the same language
+18:30 < sam_moore> Also we need to start thinking about the structure of the system in a bit more detail
+18:31 < sam_moore> Like: We can't just transfer data straight to a GUI, because the user will want to use the GUI to start the experiment, then go away and come back later to view results (and possibly save them on their own machine)
+18:32 < sam_moore> Also if we do transfer everything straight to the GUI we'd be limited by the speed of the GUI, and JavaScript requests are slow
+18:34 < Callum__> yea
+18:34 < sam_moore> Pretty easy to just dump stuff to a data file, but we probably also want the ability to do it in realtime
+18:35 < sam_moore> Anyway, good luck, see you tomorrow
+18:36 < Callum__> Alright, cya tomorrow them
+--- Day changed Mon Aug 12 2013
+--- Log closed Tue Aug 13 07:49:14 2013
+--- Log opened Tue Aug 13 07:55:27 2013
+07:55 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+07:55 -!- Irssi: Join to #mctxuwa_softdev was synced in 9 secs
+10:01 < Callum> So apparently we have a new member..
+10:12 < sam_moor1> Yep, Jeremy Tan, apparently he's doing CS as well?
+10:13 < sam_moor1> So, with the two sources of confusion we have so far...
+10:13 < sam_moor1> 1. The Camera - Adrian thinks we need one, Sensors team doesn't, everyone needs to recheck calculations
+10:14 < sam_moor1> The "Can" team wanted to use some kind of tiny can with a relatively thick wall, Adrian recommended a Coke Can, Oliver used Rockstar Cans last year and recommended them
+10:14 < Callum> well, they may be right in saying we may not be able to do any proper processing on it
+10:14 < Callum> but we will need one to relay whats actually HAPPENING in the system
+10:14 < Callum> surely the sensors team see that..
+10:15 < sam_moor1> I guess, I told them in their meeting it would probably be useful
+10:15 < sam_moor1> Anyway...
+10:15 < sam_moor1> We all got in trouble for not communicating between teams well enough
+10:15 < sam_moor1> So now the 9am session is for teams to communicate (at least one member is meant to go)
+10:15 < Callum> how many people went to the lecture?
+10:15 < sam_moor1> About 6
+10:16 < Callum> haha
+10:16 < sam_moor1> I think only one team didn't have a representative, electronics?
+10:16 < Callum> hmm. thats not too bad then.
+10:16 < Callum> but still, not really our fault communication was poor. we attempted to set up meetings and to convene with others.
+10:17 < Callum> The only other thing we could have done is actually told people, right we're meeting at this time. come or dont (then you'd have like 1 or 2 people at most)
+10:17 < sam_moor1> Yeah, I really think this project needed some kind of direction at the start
+10:17 < sam_moor1> I think that's what we're going to have to do
+10:18 < sam_moor1> We're going to have to be more assertive; we think we need Arduinos, electronics team doesn't seem to know, we should just say "Right, we're using some Arduinos"
+10:18 < sam_moor1> At least that's the vibe I got from Adrian
+10:18 < sam_moor1> Also what happened to my name
+10:18 < Callum> hmm ok. it would help if we had the team convener meeting to do that
+10:18 -!- You're now known as sam_moore
+10:19 < Callum> and no idea
+10:19 -!- Irssi: #mctxuwa_softdev: Total of 2 nicks [0 ops, 0 halfops, 0 voices, 2 normal]
+10:20 < sam_moore> Also, so far we've neglected physical details a bit
+10:20 < sam_moore> Lastly, we need to start ordering things as soon as possible
+10:21 < sam_moore> Oh, and we (as in, all teams) are supposed to have a schedule of tasks agreed upon
+10:21 < sam_moore> Right, I need to have lunch
+10:21 < sam_moore> *breakfast
+10:22 < sam_moore> Then I guess I can panic some more
+10:23 < Callum> haha. we'v only had 2 weeks to work on this really. We can pull it back.
+10:24 < sam_moore> The scary part is where they do a very similar project every year and no one ever succeeds :S
+10:25 < sam_moore> They seem to think simply throwing the entire class at it (instead of one team of 6) will make it work this time
+10:25 < sam_moore> Oh well, they can't just fail the entire class
+10:25 < sam_moore> It would be nice to actually succeed though
+10:30 < Callum> Yea, well even if it doesnt work a lot of the marking will come from the shit like the diary
+10:30 < Callum> but yes, it would be nice to see a can go boom
+11:57 < Callum> alright so am i still doing the taking images thing and storing it? Coz we pretty much need the camera. what we do with the images though dno
+11:58 < sam_moore> Just take the images and save them to a file for a start I guess
+12:00 < Callum> alright.
+12:13 < Callum> I might reinstall linux on my laptop, stick with ubuntu or go debian?
+12:51 < sam_moore> I'd recommend debian
+12:51 < sam_moore> It's not that much harder to use, but it's closer to raspian
+13:06 < Callum> alright. any port better to use?
+13:15 < sam_moore> Oh, stick with "stable"
+13:15 < sam_moore> ie: Wheezy
+13:16 < sam_moore> No matter what you do, do NOT get "Sid"
+13:18 < Callum> nah i meant the architecture
+13:20 < jtanx> yallo
+13:20 < Callum> hey
+13:21 < sam_moore> Hi
+13:23 < jtanx> i should say that right now I cant access g19 because I haven't gone through the safety induction yet
+13:23 < sam_moore> Callum: The architecture shouldn't matter too much
+13:24 < Callum> we can let you in. As long as you don't do anything stupid it will be fine
+13:24 < Callum> alright
+13:25 < sam_moore> We can just compile code on the RPi itself, or if that's too slow (I doubt it) there will be cross compilers
+13:25 < Callum> true
+13:25 < sam_moore> It's just nice to be able to run test software in debian
+13:25 < jtanx> so do you have access to an/the RPi and the other microcontrollers, or is that tba
+13:26 < sam_moore> We have access to "an" (not "the") RPi
+13:26 < Callum> rowan has an arduino too
+13:26 < sam_moore> Ah, that's good
+13:26 < Callum> atleast i think he said he did
+13:27 < Callum> just dont know the exact hardware we're using and won't get access to it for a few weeks atleast (hopefully not too long. need to make sure other teams are doing everything on time)
+13:27 < Callum> speaking of which we should write up a time schedule for our team and make sure a project one gets written up
+13:27 < sam_moore> Adrian said to allow for 6 weeks ordering time
+13:28 < sam_moore> Yeah, the entire class needs to agree on a schedule
+13:28 < Callum> hmm. true i guess, by the time adrian gets the bill of materials, clears it and the stuff gets ordered in
+13:28 < Callum> but at the current rate shit wont be chosen in time
+13:29 < jtanx> i'm surprised that not much has been done in three weeks
+13:29 < sam_moore> The problem is there are too many people working on this
+13:29 < Callum> its been less than 3 weeks though
+13:30 < sam_moore> Right. Let's make a schedule then.
+13:30 < sam_moore> Just a second
+13:30 < Callum> we only got the teams on like wed first week
+13:30 < jtanx> ok
+13:31 < Callum> And having 5-6 people per team across 6 teams without a project manager...makes sense
+13:31 < sam_moore> Haha
+13:31 < sam_moore> Ok, so I have an excel document
+13:31 < sam_moore> Anyone here actually made a schedule for a project?
+13:32 < jtanx> nope
+13:32 < sam_moore> Welp
+13:32 < jtanx> ms project was suggested in cits3200
+13:32 < jtanx> nice gantt chart and everything
+13:32 < sam_moore> Does it allow collaborative editing?
+13:33 < sam_moore> Also, is there an open source version :P
+13:33 < sam_moore> Ok, I've shared a google spreadsheet
+13:34 < jtanx> not likely haha although there was something called ms project server which might allow collaboraitve stuff
+13:34 < jtanx> you can get this all off msdnaa
+13:34 < jtanx> but since noone's used it before it might be better to stick with excel
+13:34 < sam_moore> Ok, let's just try and think what we need to get other teams to do, and what we need to do for other teams
+13:35 < Callum> HAHAH
+13:35 < sam_moore> Well
+13:35 < Callum> Hello everyone,
+13:35 < Callum> It appears that the lab signup sheets for GENG4402, the MECH/MCTX/Oil and Gas students have dissapeared from the desk at the stairwell.
+13:35 < Callum> Can you please check if you have it and return it as soon as possible? Many students still need to sign up. I will then scan and put online once complete so that you can check when your lab is.
+13:35 < Callum> PLEASE RETURN THE SHEETS.
+13:35 < Callum> Thank you
+13:35 < Callum> thats hilarious
+13:35 < jtanx> ~~
+13:36 < sam_moore> Oh dear
+13:36 < sam_moore> It strikes me that something like a Makefile, except a bit more GUI, would be good for this
+13:37 < jtanx> wait
+13:37 < jtanx> you lost me there - what are you referring to
+13:37 < Callum> ^
+13:37 < sam_moore> To compile C projects that involve several files, you use something called "make"
+13:37 < sam_moore> You write a Makefile for it
+13:37 < jtanx> yah
+13:38 < sam_moore> The Makefile has a list of targets and what they depend on
+13:38 < sam_moore> And how to make them once their dependency exists
+13:38 < jtanx> ok
+13:38 < sam_moore> Then you run "make" and it reads the make file and magically compiles everything in the right order
+13:38 < Callum> yea we get what make is
+13:39 < sam_moore> Ok, I was referring to the list of tasks
+13:39 < sam_moore> That depend on each other
+13:39 < jtanx> ook
+13:39 < jtanx> well
+13:39 < sam_moore> It was a bad joke
+13:39 < sam_moore> I am not seriously suggesting we use make to plan the project
+13:40 < Callum> hahahah
+13:40 < Callum> now that i would like to see :p
+13:40 < jtanx> um just with git
+13:40 < jtanx> i've never done pull requests before
+13:40 < sam_moore> Neither had we until last week :P
+13:41 < sam_moore> Basically you make your own fork of the repositoy, and there is a pull request button that lets you ask to have the changes merged back into the upstream repository
+13:42 < jtanx> ahh
+13:42 < jtanx> ok
+13:51 < jtanx> well that was pretty straight forward - I understand it now
+15:06 < sam_moore> I made a #mctxuwa channel for group representatives
+15:06 < sam_moore> I don't know if people will use it, but at least it's an attempt at something
+15:47 < Callum> tbh it makes more sense for us all to use one
+15:47 < Callum> unless the one for everyone is actually used often enough to justify us having our own
+16:11 < sam_moore> Yeah, there's nothing stopping people that aren't group representatives from joining it
+16:11 < sam_moore> It will certainly make it easier if there are more people talking to other teams directly than just the representative
+16:11 < sam_moore> We might still want our own for discussing the details of code
+16:12 < sam_moore> Speaking of which, I'm currently tidying up the test webserver code I wrote
+16:17 < sam_moore> Does: FunctionName, variable_name, Structure, Extern_FunctionName, g_global_variable seem suitable
+16:19 < sam_moore> Well, unless anyone objects before I've satisfied my obsessive compulsive urges, that's what it will be
+16:19 < sam_moore> Until then, it'll probably take a while, and find-replace is fast
+16:20 < sam_moore> Other than that, the style of comments/documentation in the test webserver is what I'll keep using
+16:22 < sam_moore> If someone wants to actually write code... it would be good to have a watchdog program that uses exec to start the main program and detects SIGCHLD when it crashes
+16:22 < sam_moore> Then we can put some kind of emergency "Turn all the things off!" in that
+16:57 < jtanx> what about something like this? http://stackoverflow.com/questions/696839/how-do-i-write-a-bash-script-to-restart-a-process-if-it-dies
+16:58 < sam_moore> Oh cool, that looks good
+17:03 < sam_moore> I'll be back later tonight, bye
+17:21 < jtanx> umm
+17:21 < jtanx> wow okay you're actually writing a webserver from the ground up?
+17:22 < jtanx> what if you just had software that got the results and then wrote that to a html/php file
+17:22 < jtanx> then you can just run nginx and serve it up
+17:45 < jtanx> or what about if you ran an sql server, so you update the database from your program
+17:46 < jtanx> then you can either use php to interface with the database
+17:46 < jtanx> or you could make some sort of api and serve the data in json format
+17:50 < jtanx> sqlite
+19:12 < jtanx> you could do something like this: http://pastebin.com/mEdbu4jR
+19:13 < jtanx> where instead of outputting html, you could make it output json, which is then interpreted by your actual webpage
+20:49 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Wed Aug 14 2013
+09:13 < jtanx> I've done a version using fastcgi, which was surprisingly quite easy to set up
+09:13 < jtanx> see here: https://github.com/jtanx/MCTX3420/tree/master/testing/fastcgi-approach
+10:41 < sam_moore> That looks interesting, I'd prefer that to the PHP/database solution
+10:42 < sam_moore> My concern is: You have to query the web server to start the process, even though it keeps running
+10:42 < sam_moore> Also, I know "write a custom HTTP server" sounds scary, but it does actually work
+10:43 < jtanx> nah
+10:43 < jtanx> fastcgi
+10:43 < jtanx> the process is started once and always runs
+10:43 < jtanx> so you have a request loop
+10:44 < jtanx> wait
+10:44 < jtanx> how do you envision it working?
+10:45 < sam_moore> Oh, right, I see how the fastcgi approach would work, it's basically the same idea; you have something responding to HTTP queries in one thread, something dealing with sensors/actuators in seperate threads
+10:45 < jtanx> yeah
+10:46 < jtanx> except that you don't have to worry about maintaining your own webserver
+10:46 < sam_moore> Cool
+10:46 < sam_moore> I do think that the HTTP server isn't that hard, and it's mostly working
+10:46 < sam_moore> But we can probably switch to fastcgi
+10:48 < sam_moore> I mean, we still have to parse a query string right?
+10:48 < jtanx> well yes
+10:48 < jtanx> if your request was
+10:48 < jtanx> http://blah/cgi/?key=value&anotherkey=value2
+10:48 < jtanx> you'd get back key=value&anotherkey=value2
+10:48 < jtanx> as query string
+10:50 < jtanx> try it out here: http://124.169.120.181:8080/cgi
+10:51 < jtanx> (hopefully that forwards ok)
+10:51 < sam_moore> Yep, that's cool
+10:51 < sam_moore> The HTTP server I wrote basically does that
+10:51 < sam_moore> But if it really bothers you, I'm fine with switching to fastcgi :P
+10:52 < jtanx> well whatever works
+10:52 < jtanx> but I thought it might be more maintainable if you used something that already exists :P
+10:52 < sam_moore> Yeah, but thinking about it, what maintainence does the HTTP server require?
+10:53 < sam_moore> Oh well, it's a good idea
+10:53 < jtanx> for this situation not much
+10:57 < sam_moore> We can pretty easily start with a structure that would allow us to switch, but I'd lean towards keeping the custom HTTP server
+10:58 < sam_moore> Have you done multithreading in C before?
+10:58 < jtanx> in windows yes
+10:58 < jtanx> on linux not really
+10:58 < sam_moore> Ah, I've only done it on linux
+10:58 < jtanx> i did a bit in operating systems
+10:59 < jtanx> but kinda forgot
+10:59 < sam_moore> It shouldn't be too hard for our purposes
+11:00 < jtanx> that thing with running a custom webserver is that if anyone wants to reuse this in the future, i doubt they'd really like the idea of that
+11:01 < jtanx> say they had some new fangled thing that requires php
+11:01 < jtanx> which isn't going to work
+11:01 < jtanx> but with a standard webserver like apache or nginx, it's really easy to just install an extra addon
+11:02 < sam_moore> I suppose... what would they need the new fangled php thing for?
+11:03 < jtanx> well that's the thing - for now I don't know, but it could be required
+11:03 < sam_moore> Yeah, good point
+11:03 < sam_moore> Ok, another reason to use an existing web server, is we might require some advanced features if we want to be serious about the safety stuff
+11:04 < sam_moore> For example, it would be a fair amount of work to add SSL to make the custom thing do https
+11:04 < jtanx> oh yeah
+11:04 < jtanx> that too
+11:04 < sam_moore> Also we might want some authentication on it
+11:04 < jtanx> nginx/apache are highly customisable
+11:05 < sam_moore> I've never used nginx, what are it'
+11:05 < sam_moore> s advantages over apache2?
+11:05 < jtanx> nginx
+11:05 < jtanx> yup
+11:05 < jtanx> its really good
+11:05 < sam_moore> Haha
+11:05 < jtanx> a lot of sites use it because it's fast
+11:05 < sam_moore> Fast is good
+11:05 < jtanx> faster than apache
+11:05 < sam_moore> Sold
+11:05 < sam_moore> Well, we only need one user as well
+11:05 < sam_moore> In fact, we deliberately do not want to have multiple clients able to use the thing at the same time
+11:05 < jtanx> haha true
+11:07 < sam_moore> Ok, so I think you've convinced me to use fastcgi
+11:07 < sam_moore> Most of the custom HTTP server was reused code, so I didn't waste too much time on it
+11:07 < jtanx> haha ok
+11:07 < jtanx> have you written one before?
+11:09 < sam_moore> Not specifically a HTTP server, but I've written a project for posix systems with a fair bit of networking
+11:09 < sam_moore> git.ucc.asn.au/?p=matches/swarm.git
+11:10 < jtanx> nice
+11:10 < sam_moore> It allows you to run a shell, eg: bash accross multiple machines at once
+11:11 < sam_moore> Not as useful as I thought it might be, but it was fun
+11:12 < jtanx> heh
+11:12 < jtanx> what did you end up using it for?
+11:13 < sam_moore> I was setting up a programming competition where you have AIs play against each other
+11:13 < sam_moore> I wanted to make a round robin
+11:13 < sam_moore> So I had a bash script setup to do that, but then I got impatient, because it would have to run the games in order
+11:14 < jtanx> oO
+11:14 < sam_moore> Well it turned out no one entered the competition, so I probably didn't need to go overboard
+11:14 < sam_moore> But maybe I can use it for something else
+11:15 < sam_moore> For the threading I'm thinking of using pthreads
+11:16 < sam_moore> The alternative is OpenMP, but it's more suited to numerical computation, rather than having seperate things talking to each other
+11:16 < jtanx> okay
+11:17 < sam_moore> My goal for this week was to have the framework started, so we just have some really basic threads running and then we can start implementing them
+11:17 < jtanx> yeah that would be good
+11:18 < sam_moore> If you want to do some work with the fastcgi part so that we'll be able to parse the query strings, that would probably be a good start
+11:18 < sam_moore> We don't have the exact details of pretty much anything yet
+11:18 < sam_moore> Maybe talk to James/Rowan about how the GUI is going to query the server
+11:19 < sam_moore> Also, did you see my suggested naming convention?
+11:19 < jtanx> no
+11:20 < sam_moore> I don't really mind, although I'd prefer not to have hungarian notation
+11:20 < sam_moore> As long as it'
+11:20 < sam_moore> s consistent
+11:21 < sam_moore> But the suggestion was: FunctionName, variable_name (local or member), Structure, ENUMVALUE, Extern_FunctionName, g_global
+11:21 < jtanx> okay I'll try to keep to that
+11:22 < sam_moore> Cool, I should probably go do something else
+12:33 < jtanx> i gotta go
+12:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+16:56 < jtanx_> a beagleboard
+16:56 < jtanx_> hmm
+16:58 -!- jtanx_ is now known as jtanx
+17:03 < jtanx> is it the beaglebone black?
+17:03 < jtanx> sounds interesting
+17:04 < sam_moore> They didn't specify
+17:04 < sam_moore> Oh right, I accidentally cut out his message
+17:04 < sam_moore> tl;dr "Beagle Board"
+17:04 < jtanx> the beagle board is around $125 though
+17:04 < sam_moore> Probably the Beaglebone black
+17:04 < sam_moore> Oh really
+17:04 < sam_moore> Heh
+17:04 < jtanx> yeah
+17:05 < jtanx> the beaglebone black is $45
+17:05 < jtanx> but just looking the A/D converter on the black has a max voltage of 1.8v
+17:05 < sam_moore> That's probably what they meant, since they said it is "not much more expensive"
+17:05 < sam_moore> That should be fine; the sensors team says things are in mV
+17:05 < jtanx> okay
+17:05 < jtanx> that's good
+17:05 < sam_moore> Really though... electronics should be asking the sensors team stuff like this
+17:06 < jtanx> heh yeah
+17:06 < sam_moore> They should probably have asked us if it was feasable for software
+17:06 < sam_moore> Maybe they had someone who knew it would be, but still
+17:06 < sam_moore> It looks like it is anyway, so crisis averted
+17:07 < jtanx> just with the sensors, I think that the diferences need to be amplified so it covers the full range of the A/D converter
+17:07 < sam_moore> Yes, the sensors guy knows that
+17:07 < jtanx> yeah so if its only 1.8v there's less range than 0-5v
+17:08 < jtanx> is that compensated enough by having a 12 bit a/d converter vs a 10 bit (i think arduino is 10 bit) converter
+17:10 < sam_moore> I think so; you get ~4x more resolution from the 12 bit ADC and lose ~3x from the lower range
+17:10 < sam_moore> Also there's no set requirement yet on what the resolution should be
+17:11 < jtanx> true
+17:11 < jtanx> well in any case the bb black sounds quite nice
+17:11 < sam_moore> Yep, it'll probably be good to use
+17:14 < sam_moore> I'm much happier now that we actually have regular verbal communication with the other teams
+18:23 < sam_moore> I'm looking into getting doxygen working for this
+18:59 < jtanx> for the documentation?
+18:59 < jtanx> seems good, but never used it before myself
+19:01 < jtanx> looks a lot like javadoc
+21:26 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:54 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Thu Aug 15 2013
+08:21 < jtanx> hey
+08:22 < jtanx> just a suggestion for the logging functions, but you can use macros
+08:22 < jtanx> to get the function name (and even file name)
+08:22 < jtanx> v
+08:22 < jtanx> http://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html
+08:23 < jtanx> so you can do stuff like #define Log(level, fmt, ...) LogReal(level, __func__, fmt, __VA_ARGS__)
+08:25 < jtanx> it should be c99 conformant
+09:15 < jtanx> I created a pull request anyway
+09:33 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+13:39 < sam_moore> Yeah, I probably should have looked at that
+13:46 < jtanx> back to the rpi+arduino
+13:47 < jtanx> didn't they know about the beagle board black, or can that not be used for some reason?
+13:48 < jtanx> beagle bone* black
+14:20 < sam_moore> I don't know what model they were looking at exactly
+14:20 < sam_moore> I told them the Beagle Bone was about $50, I haven't had much time to research it myself
+14:20 < sam_moore> I didn't know about the Beagle Board/Bone, which was why I suggeste the RPi + Arduino
+14:20 < sam_moore> They originally were just considering an Arduino
+14:21 < sam_moore> Which would not have been fun for the remote interfacing stuff
+14:21 < sam_moore> Well we could do it, but we wouldn't be able to have a nice web browser controlled GUI, probably some dedicated networked server/client with a GUI program installed on the client machine
+14:22 < sam_moore> Also image processing would have been interesting
+14:23 < sam_moore> Next time there's a combined groups meeting, hopefully we can talk to them more
+14:24 < jtanx> yeah
+14:24 < jtanx> there's quite a few
+14:24 < jtanx> there's a beagleboard which is ~150
+14:24 < jtanx> beaglebone which is ~90
+14:24 < jtanx> beaglebone black which is ~50
+14:24 < sam_moore> Right
+14:24 < sam_moore> So they were probably looking at the beaglebone for $90
+14:24 < jtanx> yeah probably
+14:24 < jtanx> it's weird because the black version has better specs, from what i can see
+14:25 < sam_moore> But still, even for $150, if it saves us 10 hours of writing code to interface the RPi with Arduinos, it will be worth it
+14:25 < jtanx> yeah exactly
+14:25 < sam_moore> Arduinos themselves cost a bit
+14:25 < jtanx> well
+14:25 < jtanx> you can get equivalents off ebay
+14:25 < jtanx> like an uno is $10
+14:26 < sam_moore> The only issue with the beaglebone to avoid having to use arduinos as well, is whether it has enough ADC by itself
+14:26 < jtanx> yeah
+14:26 < jtanx> well how many sensors are needed
+14:26 < sam_moore> If it doesn't, you might have to add an Arduino or two anyway
+14:26 < jtanx> you could just add on an adc chip
+14:26 < sam_moore> Yes, or something like that
+14:27 < jtanx> the beaglebone has like a bazillion gpio ports
+14:31 < sam_moore> Well without getting into the specific details, it sounds like we should recommend they use that
+14:32 < sam_moore> Apparently the sensors team will have a list ready by monday, which will be good
+14:33 < jtanx> that'd be good
+14:35 < jtanx> when are combined group meetings? just the 9am slot?
+14:36 < sam_moore> 9am Tuesday is the "official" time picked by Adrian, 2pm Wednesday is the time that we agreed between the teams
+14:36 < sam_moore> I'm going to go to both, if more people want to come from the team that's also good
+14:37 < sam_moore> Realistically not everyone is going to come, so I'll have to send emails a lot
+14:38 < jtanx> ok
+14:39 < sam_moore> What account do you need to be invited to the dropbox?
+14:39 < sam_moore> I think Alex invited everyone using their student email
+14:40 < sam_moore> Oh right, you wouldn't have been in the list that he used if you enrolled late
+14:40 < jtanx> yeah, through student email would be good
+14:41 < jtanx> last year's experiment ran with an arduino diecimila which only had 5 analogue inputs
+14:41 < jtanx> any reason why we need more?
+14:41 < jtanx> sorry that's 6
+14:42 < sam_moore> I think the estimate was: 4-6 strain gauges, 1 temperature sensor, 1 microphone, 2 pressure gauges, 1 (maybe 2) USB webcam
+14:43 < jtanx> ok
+14:44 < jtanx> At that rate you would definitely need something with more analogue inputs
+14:45 < sam_moore> We also might need a DAC for one of the pneumatics team's devices
+14:46 < sam_moore> But you can't get that on a microcontroller, there'd have to be a seperate module
+14:46 < jtanx> yep
+14:48 < jtanx> it'd be no point interfacing an arduino to the rpi/beaglebone if all you want is more analog inputs
+14:49 < sam_moore> If you can get modules for ADC that can talk to a rpi/beaglebone, then yes
+14:49 < jtanx> yeah
+14:49 < jtanx> I don't think they're too hard to wire up
+14:50 < sam_moore> I think the electronics team should be considering all this, but I don't know since we haven't verbally spoken
+14:50 < sam_moore> Well not at length anyway
+14:51 < sam_moore> Just when I happen to bump into Omid
+14:51 < jtanx> hmm
+14:54 < sam_moore> This project is probably going to be a good lesson in "Why you need a project manager"
+14:55 < jtanx> so true
+14:59 < jtanx> with the web interface, what sort of update times are we looking at?
+15:00 < sam_moore> My tests with apache2 and the custom HTTP server showed it took about 50us for jQuery to get an AJAX request
+15:01 < sam_moore> There was only one data point returned each time though, we can probably optimise it a bit by returning multiple data points with a request
+15:01 < jtanx> yeah
+15:07 < jtanx> I wonder what sort of performance impact running one (or two) cameras would have on the rpi/beaglebone
+15:44 < jtanx> urgh
+15:45 < jtanx> I was wondering why my nginx config wasn't working
+15:45 < jtanx> until I realised that gedit was creating a backup copy of the config file
+15:45 < jtanx> so nginx was reading both the original and backup
+17:28 < sam_moore> That's wierd, you'd think it would only read one config file
+17:34 < jtanx> well it was in a config directory
+17:36 < sam_moore> Oh, ok
+18:49 < jtanx> so the current idea i have with the web thing is
+18:49 < jtanx> you can query it like http://domain/api/module?key=value&key=value2
+18:50 < jtanx> and then you could return something in json format or whatever is most suitable for the ajax query
+19:46 < jtanx> you can test it at http://mctx.us.to:8080/apoi
+19:46 < jtanx> woops, http://mctx.us.to:8080/api
+19:46 < jtanx> the only 'module' which will give a response of '200 OK' is sensors
+19:47 < jtanx> which currently spits back any arguments you pass to it
+19:47 < jtanx> eg http://mctx.us.to:8080/api/sensors?k=v
+19:50 < jtanx> hopefully it doesn't break
+20:44 < sam_moore> I'll take a look
+20:45 < sam_moore> Looks good
+20:45 < sam_moore> I'm writing a dummy thread for a sensor now
+21:04 < jtanx> the code behind it (in the cgi module) is a bit clunky right now though
+21:04 < jtanx> is there a meeting tomorrow?
+21:05 < sam_moore> I don't think so, sorry
+21:06 < jtanx> ok that's alright
+21:06 < sam_moore> Things aren't urgent (yet)
+21:07 < jtanx> heh
+21:12 < sam_moore> For the progress report: I'd like everyone to write a page individually, then we can summarize those in the group report
+21:12 < sam_moore> Well you don't have to write a whole page, and if you miss a week or so it's not a big problem
+21:16 < jtanx> ok
+21:17 < jtanx> i'll try to remember that
+21:18 < jtanx> do you think we need to keep track of how long we spend on this project
+21:18 < jtanx> for that 'cost estimate'
+21:28 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+22:23 < sam_moore> For the cost estimate: Yes, we are supposed to have a technical diary (hand written)
+22:23 < sam_moore> Including all notes and times worked on the project
+22:40 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Fri Aug 16 2013
+09:48 < jtanx> I was wondering what sort of model you have for reading/storing sensor values and controlling actuators
+10:02 < sam_moore> At the moment each sensor has a thread that continuously polls the sensor and dumps data to a binary file
+10:03 < sam_moore> For reading there is a thread that fills a buffer from the file when it gets a request
+10:04 < sam_moore> It might be better to change to a single thread for sensors/actuators though
+10:04 < jtanx> yeah, I was about to say if it was necessary to have one for each
+10:05 < sam_moore> Probably not, if you had varying polling speeds it would be useful, because you could poll the fast sensors seperately from the slow ones
+10:05 < jtanx> how do you wish to pass the data to the fcgi module?
+10:06 < jtanx> right now
+10:06 < jtanx> i've kinda set it so
+10:06 < jtanx> there's this thing called a ModuleHandler
+10:07 < jtanx> so you can pass it some data (tba what this is), and it also receives the query string from the use
+10:09 < sam_moore> Well, the ModuleHandler gets called whenever the right HTTP request is made right?
+10:10 < sam_moore> So, that function retrieves the data it needs to respond to the request
+10:10 < jtanx> well rightnow the typedef is
+10:10 < jtanx> typedef void (*ModuleHandler) (Data *data, char *params);
+10:10 < jtanx> so it's up to you to write a module handler (eg SensorsHandler)
+10:11 < sam_moore> Ok, data's a bit of an ambigous name, so is that something passed to the ModuleHandler when the FastCGI gets a request?
+10:11 < jtanx> well the data thing was a placeholder for whatever sensors/actuators data there was
+10:11 < sam_moore> Is it meant to be sensor data, or is it a value that the user has passed through HTTP
+10:11 < jtanx> the query string is part of params
+10:11 < sam_moore> Ok, right, that makes more sense
+10:12 < sam_moore> My view had the ModuleHandler getting the appropriate data itself
+10:12 < jtanx> Ok
+10:12 < sam_moore> Given the params
+10:13 < jtanx> I'm just not really used to using global variables
+10:13 < sam_moore> The global sensors array?
+10:13 < jtanx> yeah
+10:13 < jtanx> i take it that's where you access data from?
+10:14 < sam_moore> Yes
+10:14 < jtanx> oh yeah one more thing, when you get a request, should it only return the latest data?
+10:20 < sam_moore> We should probably think some more about this as a whole group
+10:20 < sam_moore> So, you have a sensor that can (probably) poll a lot faster than you get requests via jQuery
+10:21 < sam_moore> You can write it so that you only actually query the sensor when you get a request, but then you're wasting the chance to get data that could be useful
+10:22 < sam_moore> Or you can have it so that the sensor is continuously polling (What my code is simulating at the moment)
+10:22 < sam_moore> With the continuosuly polling sensor; when you get a request, you can either return the most recent block of data you got
+10:23 < sam_moore> Or you can have it so that the data will be sent in sequential order (which is what my code currently does)
+10:23 < jtanx> hmm
+10:23 < sam_moore> I'm pretty sure continously polling is better than querying each time you get a request, since after all this is an experiment and you want the data
+10:23 < jtanx> yeah
+10:24 < jtanx> I agree with you there
+10:24 < jtanx> so you're saying, continuously poll and log the results
+10:24 < jtanx> and when a request comes in, send back all the data up to the point when the last request came in
+10:25 < sam_moore> Well that's what the server program I wrote simulates at the moment.
+10:25 < sam_moore> However it might be more sensible for the request to just get the most recent data.
+10:25 < jtanx> hmm
+10:25 < sam_moore> Ah, yeah that's probably better actually
+10:25 < jtanx> then you're logging more points than youdisplay
+10:26 < sam_moore> Yes, but you can always add a function to pull all the data points and save to a csv or something like that.
+10:26 < sam_moore> In fact I think we'd want to do that.
+10:27 < jtanx> yeah ok
+10:27 < jtanx> that sounds not too bad
+10:27 < jtanx> but if that's the case
+10:27 < sam_moore> If you actually use this for an experiment, you're not going to want to have to do all your analysis in a JavaScript GUI
+10:27 < jtanx> true
+10:27 < sam_moore> The GUI is for getting live information on the state of the system more than for data analysis
+10:27 < jtanx> but if that's the case you might want to allow direct access to the latest dataset
+10:28 < jtanx> instead of having to read from the file
+10:28 < jtanx> if that's possible
+10:28 < jtanx> then you can directly record the results in csv format
+10:28 < sam_moore> Yes, I thought about that; you can have a buffer of points accessed by the request thread easily enough
+10:29 < sam_moore> There are some difficulties though with managing the buffer
+10:30 < sam_moore> Wait, maybe it's easier than I though
+10:30 < sam_moore> Yeah, the reason I started saving stuff to a binary file was because I was thinking of the requests having to get the data in sequence
+10:32 < sam_moore> I have some other stuff to do today unfortunately
+10:33 < sam_moore> I have a feeling it won't be trivial to just access the most recent dataset, I'll have to think about it
+10:34 < sam_moore> However, currently it should be easy to change so that the request gets data from the end of the binary file, rather than keeping track of its position
+10:34 < sam_moore> The function QuerySensor is what I was thinking the SensorHandler would do to get data; it just fills a buffer and prints it at the moment
+10:35 < sam_moore> Binary file access is pretty fast, we could even just keep the binary file and change the data to csv when it goes to the client
+10:36 < jtanx> ok, I'll keep that in mind
+11:11 < sam_moore> Oh, you can replace the Data* pointer with a Sensor* pointer and then not have to use the global variable directly, that's probably best
+11:13 < jtanx> well it might not only be sensor data
+11:13 < jtanx> it could be actuator stuff or anything else
+11:13 < sam_moore> I suppose
+11:14 < jtanx> maybe I should change the typedef to void*
+11:14 < jtanx> then you can cast it to whatever
+11:14 < sam_moore> Yeah, that will work
+11:15 < sam_moore> Actuator stuff is going to be a bit of a seperate (hopefully easier) problem
+11:15 < sam_moore> In that case you can just wait for a query before doing anything
+11:15 < sam_moore> Anyway, I've distracted myself again, this is just too interesting :S
+11:15 < jtanx> hahaha
+11:16 < jtanx> anycase for the actuator you would have a separate handler function
+11:16 < sam_moore> Yes
+11:16 < jtanx> eg ActuatorHandler
+11:20 < jtanx> fcgi is pretty whack
+11:20 < jtanx> it replaces printf
+11:21 < jtanx> so when you printf (or fwrite for binary?), that gets sent to the client
+12:03 < jtanx> hey
+12:04 < jtanx> what if we stored stuff in an sqlite library
+12:04 < jtanx> sorry database
+12:04 < jtanx> on second thoughts nah
+15:02 -!- jtanx_ is now known as jtanx
+18:59 -!- jtanx_ is now known as jtanx
+21:28 < sam_moore> So, I did a bit of testing with sqlite vs a binary file
+21:28 < sam_moore> sqlite takes about 1000x as long for saving data
+21:28 < sam_moore> I haven't tested reading it back yet
+21:28 < sam_moore> But more worrying
+21:28 < sam_moore> I get a segmentation fault using sqlite
+21:29 < sam_moore> And it's in the sqlite library somewhere; not my test code
+21:29 < sam_moore> Running sqlite in valgrind shows a bunch of complaints about uninitialised values
+21:29 < sam_moore> So... I'd recommend we just use a binary file
+21:30 < sam_moore> A database is good for storing more complex data, but when you just need to store data recorded in a sequence, it's probably unnecessary
+21:36 < jtanx> yeah sqlite not so good for file performance
+21:36 < jtanx> because every insert it has to confirm the write to disk
+21:36 < jtanx> the segfault
+21:36 < jtanx> may actually be because you didn't initialse the mutex
+21:36 < jtanx> es
+21:36 < jtanx> i tried compiling it on mingw and it segfaults on the mutex unlock
+21:37 < sam_moore> Re: fcgi replacing printf - It probably calls dup2 to change stdout from the terminal to a domain socket or fifo that nginx listens to
+21:37 < jtanx> nah
+21:38 < jtanx> fcgi_stdio just has a bunch of defines
+21:38 < sam_moore> Oh really, that's wierd
+21:38 < jtanx> so printf becomes FCGI_printf
+21:38 < jtanx> so fcgi_stdio must be the first include in the fcgi module
+21:38 < sam_moore> I would have thought it was simpler to just change stdout than replace the whole printf function
+21:38 < sam_moore> But whatever, we're not implementing fcgi :P
+21:38 < jtanx> haha
+21:39 < sam_moore> Oh, the mutex needs initialising, yeah
+21:39 < sam_moore> But the test I did was just a serial program, no mutex
+21:39 < jtanx> ah
+21:39 < jtanx> well
+21:39 < sam_moore> We'll be using gcc to compile on the beaglebone/rpi
+21:40 < sam_moore> I think some implementations of pthreads need an initialiser but others don't, I'll have to check
+21:40 < sam_moore> But pthread_mutex_init doesn't show up in man pages on debian
+21:40 < jtanx> yeah it's not on ubuntu either
+21:41 < jtanx> have you ever worked with clang
+21:42 < sam_moore> No
+21:42 < jtanx> neither but it seems pretty cool
+21:45 < jtanx> when you compile it gives better diagnostic output when something goes wrong
+21:46 < jtanx> it's a drop in replacement for gcc
+21:47 < sam_moore> Interesting
+21:57 < jtanx> if you kept the file handles for the sensor data always open
+21:58 < jtanx> and immediately wrote to them when a data point is polled
+21:58 < jtanx> is there much performance difference to buffering first?
+22:05 < sam_moore> Yeah, it's probably better to keep the file handles always open
+22:05 < sam_moore> The operating system will use some kind of buffer for the file anyway
+22:06 < sam_moore> I've got some basic programs, maybe I'll make some performance graphs tomorrow
+22:07 < sam_moore> On the other hand, I need to do some of the meta stuff (list of tasks that need to be completed, etc) before Monday
+22:08 < sam_moore> I should look into a #define or something to initialise the mutexes if they need to be
+22:09 < sam_moore> Anyway, I need to sleep
+22:11 < sam_moore> I wonder how James and Callum are going, they haven't been in the channel for a while
+22:12 < jtanx> yeah, it's pretty quiet
+22:17 < sam_moore> If we can get a second meeting in the week, preferably a longer one that would be good
+22:18 < sam_moore> Particularly if we can start working on code at the same time
+22:18 < sam_moore> But we'll see
+22:18 < sam_moore> Everyone has other stuff to do after all
+22:18 < sam_moore> I'm spending way too much time on this unit compared to my others
+22:18 < sam_moore> Then again this unit will probably require the most work
+22:19 < sam_moore> Anyway, bye
+22:23 < jtanx> bye
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sat Aug 17 2013
+22:25 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 22.0/20130618035212]"]
+--- Day changed Sun Aug 18 2013
+21:53 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:37 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]"]
+--- Day changed Mon Aug 19 2013
+11:43 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+13:34 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+20:07 < jtanx> just so you know, I'm changing the JSON functions
+21:04 < sam_moore> Ok, I already pushed some stuff to github
+21:05 < sam_moore> But we can get it to merge
+21:05 < sam_moore> I ended up just using printf to make part of the JSON in the SensorHandler anyway
+21:06 < jtanx> depending on where SensorHandler is
+21:06 < jtanx> that may or may not work
+21:06 < jtanx> inside of fastcgi.c it willwork
+21:06 < jtanx> outside it won't
+21:07 < jtanx> oh ok
+21:07 < jtanx> I see
+21:07 < jtanx> so that's fine
+21:08 < jtanx> it might be best not to use a do while loop
+21:08 < jtanx> because if no arguments are passed
+21:08 < sam_moore> Ah, right
+21:08 < jtanx> then the keypair function will return null
+21:09 < jtanx> while ((params = FCGI_KeyPair(params, &key, &value)))
+21:09 < jtanx> will work fine
+21:10 < sam_moore> The KeyPair function looks like it can return an empty string though, in which case I was getting the sensor_id parsed twice when I was testing it
+21:10 < jtanx> what was your input string?
+21:11 < sam_moore> "http://localhost/api/sensors?id=0"
+21:11 < jtanx> looks fine from this end
+21:11 < jtanx> http://mctx.us.to:8080/api/sensors?id=0
+21:11 < jtanx> it might be because of your do while loop
+21:12 < jtanx> yeah it will be because of that
+21:12 < sam_moore> The do while loop causes problems when there is an empty string
+21:13 < sam_moore> ie: No parameters are passed
+21:13 < jtanx> ok let's just put it this way; FCGI_KeyPair was designed to use a while loop
+21:13 < sam_moore> Ok, sure
+21:13 < sam_moore> I had some problems with just a while loop, but I'll try again
+21:13 < jtanx> yeah about that JSON stuff
+21:13 < jtanx> I'm still trying to think of a good way to do that
+21:13 < jtanx> especially with the array stuff
+21:19 < sam_moore> I'm not sure what I did before, but a while loop seems ok now
+21:19 < jtanx> heh
+21:21 < sam_moore> Ok, I have to go now
+21:21 < sam_moore> I might not be able to do much tomorrow, we'll see
+21:22 < jtanx> ok yep
+21:35 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+22:46 -!- jtanx [
[email protected]] has quit ["ChatZilla 0.9.89 [Firefox 23.0.1/20130814063812]"]
+23:14 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
+23:35 -!- Callum [
[email protected]] has quit ["ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]"]
git.ucc.asn.au / matches / MCTX3420.git / blobdiff
UCC git Repository :: git.ucc.asn.au