**** BEGIN LOGGING AT Tue Mar 11 02:59:59 2014
Mar 11 06:09:22 <panto> morning
Mar 11 14:12:09 <vmayoral> anujdeshpande, sidbh: please check your e-mail
Mar 11 14:14:10 * sidbh is checking
Mar 11 14:27:21 <sidbh> vmayoral: is there a need to give three weeks on the userland sensor driver development ? i guess most of it is achieved in AP_HAL_LINUX.
Mar 11 14:36:24 <sidbh> vmayoral, anujdeshpande: in the project name part shouldn't there be a title definition of our individual work
Mar 11 14:37:09 <anujdeshpande> sidbh: didn't follow you..
Mar 11 14:37:16 <anujdeshpande> sidbh: where exactly ?
Mar 11 14:37:53 <sidbh> in the proposal, have you checked vmayoral's proposal
Mar 11 14:37:55 <sidbh> ?
Mar 11 14:38:09 <anujdeshpande> sidbh: ahh ..
Mar 11 14:38:12 <anujdeshpande> just did.
Mar 11 14:38:40 <anujdeshpande> sidbh: should be ok as is I think
Mar 11 14:39:02 <sidbh> let's consult jkridner on this
Mar 11 14:39:44 <anujdeshpande> sidbh: cool
Mar 11 14:39:51 <jkridner> hi
Mar 11 14:40:45 <jkridner> discussing drawing clearer lines between the chunks of work?
Mar 11 14:40:50 <anujdeshpande> jkridner: are you cool with us submitting an application with interdependent objectives ??
Mar 11 14:40:54 <anujdeshpande> jkridner: yes :)
Mar 11 14:41:01 <jkridner> btw, I suggest sending in separate proposals for the final proposal submission.
Mar 11 14:41:15 <jkridner> interdependencies I think are fine...
Mar 11 14:41:19 <jkridner> as long as the boundaries are clear.
Mar 11 14:41:34 <anujdeshpande> jkridner: yes. no overlap in objectives at all.
Mar 11 14:41:54 <jkridner> you should be able to complete your individual work independently, even if it isn't really useful to an end-user without all the components.
Mar 11 14:41:55 <anujdeshpande> jkridner: no qualification test this year ?
Mar 11 14:42:05 <jkridner> the same test is there...
Mar 11 14:42:15 <jkridner> cross-compilation test.
Mar 11 14:42:39 <jkridner> but, I already know you know how to cross compile anujdeshpande. :-)
Mar 11 14:42:54 <anujdeshpande> jkridner: will give the same link then :D
Mar 11 14:43:07 <jkridner> as long as it has your name. :-)
Mar 11 14:43:31 <anujdeshpande> jkridner: yepp :)
**** ENDING LOGGING AT Tue Mar 11 14:47:08 2014

**** BEGIN LOGGING AT Tue Mar 11 14:48:16 2014
Mar 11 14:50:47 <sidbh> anujdeshpande: i guess our tasks will clash at PRU code upload and data handling part, we should clarify that part and define boundaries
Mar 11 14:51:02 <anujdeshpande> sidbh: agree
Mar 11 14:52:38 <anujdeshpande> sidbh: if you are working on communication interfaces
Mar 11 14:52:50 <sidbh> anujdeshpande: so what if we divide these two tasks into two parts as is and then merge our results to continue work on our library dev
Mar 11 14:53:48 <sidbh> ??
Mar 11 14:54:27 <anujdeshpande> i am still how we can divide ...
Mar 11 14:54:45 <anujdeshpande> sidbh: can we have this conv in a bit.. tied up here and can't focus :-P
Mar 11 14:54:53 <sidbh> ok
Mar 11 15:06:27 <vmayoral> sidbh, anujdeshpande: apologies guys, i was taking care of an issue i'm back
Mar 11 15:06:49 <vmayoral> sidbh: i understand your concern about the userland sensors but take into account that as tridge pointed out
Mar 11 15:07:08 <vmayoral> there's no drivers for the new sensors (coming in the PixHawk Fire Cape)
Mar 11 15:07:13 <vmayoral> there're*
Mar 11 15:07:30 <vmayoral> that would should be done by us, thereby i pointed it out in my proposal
Mar 11 15:08:00 <sidbh> vmayoral: okay!! that justifies the duration :)
Mar 11 15:08:12 <vmayoral> furthermore, the last week (of those three) will be dedicated to code the automatic tests and make sure everything works out
Mar 11 15:08:40 <vmayoral> i honestly believe it's an important part to get a "Minimum Viable AutoPilot" (just came up with this term ;))
Mar 11 15:09:13 <vmayoral> then week after week we will improve it with the PRU Library and so on
Mar 11 15:10:52 <sidbh> vmayoral: seems like a nice plan and nice term :)
Mar 11 15:12:23 <vmayoral> regarding cross-references that jkridner mentioned, I pointed out our work over the last months (quite surprising that we started bringing this up last December)
Mar 11 15:13:42 <vmayoral> should be fine guys! I'm actually quite glad of our collaboration so far. We can expect big things if we keep it this way ;)
Mar 11 15:13:43 <sidbh> which cross refernces?
Mar 11 15:13:53 <sidbh> *references
Mar 11 15:14:03 <vmayoral> sidbh: mentioning you and anujdeshpande
Mar 11 15:14:14 <vmayoral> and also mentioning the GSOC proposal google doc
Mar 11 15:14:42 <sidbh> ohk
Mar 11 15:16:12 <sidbh> vmayoral: sure we will achieve great things, it is a pleasure working with you guys :)
Mar 11 15:16:32 <vmayoral> sidbh: feeling the same here!
Mar 11 15:16:44 <vmayoral> a couple of comments regarding BeaglePilot in github guys
Mar 11 15:17:11 <vmayoral> PPM-PRU and PWM-PRU should eventually merge with PRUSS-C, do you agree?
Mar 11 15:17:48 <vmayoral> Also, i'd like that we merge our code with the "ardupilot" fork of BeaglePilot
Mar 11 15:17:52 <vmayoral> this way we have it organized
Mar 11 15:18:37 <vmayoral> and later, if the ardupilot guys wish, they can merge our commits in the main repository
Mar 11 15:19:09 <vmayoral> tridge: do you agree with this or would you prefer us to make pull requests directly on the ardupilot repository (the one of diydrones)?
Mar 11 15:19:42 <sidbh> yeah, i guess that's the future prospect of the beaglepilot
Mar 11 15:20:35 <sidbh> i think tridge is sleeping zzzzz... its mid night in australia
Mar 11 15:20:57 <sidbh> brb
Mar 11 15:40:32 <sidbh> anujdeshpande: so i guess we should work on the overlapping stuffs individually for our separated repos but try to maintain standardized way of doing things by discussing with mentors and between ourselves
Mar 11 15:52:19 <anujdeshpande> vmayoral: agree. we could work on our own fork, and then think about merging it later. also, let's just focus on pruss-c. don't really need so many repos. branches will do.
Mar 11 15:52:34 <anujdeshpande> sidbh: what all do you think will overlap ?
Mar 11 15:53:17 <sidbh> as we discussed the PRU upload and data handling
Mar 11 15:53:54 <anujdeshpande> sidbh: i see .. what we could probably do is work on 2 different pru's
Mar 11 15:55:00 <anujdeshpande> logically divide the tasks in 2. panto has a good setup i think. 1 pru for hard real time stuff, the other for communication interfaces etc.
Mar 11 15:56:25 <sidbh> so you are suggesting communication part only supporting 1 PRU and another PRU just supporting real time stuff
Mar 11 15:56:39 <sidbh> if so i guess it will hinder reusability
Mar 11 15:56:55 <anujdeshpande> sidbh: how so ?
Mar 11 15:57:49 <sidbh> what if someone want to use a part of comms lib and a part of realtime lib on single PRU
Mar 11 15:58:34 <panto> err, that's all possible
Mar 11 15:58:47 <panto> even the comms PRU is pretty good at realtime stuff
Mar 11 15:58:55 <panto> it's much much better than the arm
Mar 11 15:59:18 <panto> the difference is comms PRU (about 1ms worst latency)
Mar 11 15:59:33 <panto> hard real time PRU (as good as you can get it - typically down to ns)
Mar 11 15:59:47 <anujdeshpande> panto: have you taken a look the proposals that we are working on ?https://docs.google.com/document/d/1oL0NU4d5ZiujAuXJmI40pziRQlXCEmAf5TgK6NVDap8/edit?usp=drive_web
Mar 11 16:00:16 <anujdeshpande> ppm and pwm generation/input on one pru and the rest on the other one . seem feasible ?
Mar 11 16:00:34 <panto> yes
Mar 11 16:01:16 <anujdeshpande> nice . thanks !
Mar 11 16:01:19 <panto> anujdeshpande, I did read the doc
Mar 11 16:01:29 <panto> I'm just awfully busy right now though
Mar 11 16:01:48 <anujdeshpande> panto: np. do comment when you get time though
Mar 11 16:02:07 <sidbh> anujdeshpande: i guess our work should not only support beaglepilot, but also independent users who want to use just the PRU part
Mar 11 16:02:25 <anujdeshpande> sidbh: true ..
Mar 11 16:03:39 <sidbh> so we should maintain interchangeability, reusability and compatibility of our works as part of our discussion
Mar 11 16:04:43 <anujdeshpande> so you want to be able to switch things on the pru basically ??
Mar 11 16:05:48 <panto> I hope you guys monitor beagle-gsoc
Mar 11 16:05:51 <sidbh> yep and be able to use functions from your lib and you from mine
Mar 11 16:05:55 <panto> a couple of other PRU projects are going on
Mar 11 16:06:10 <anujdeshpande> panto: yepp. followed your discussions with karki
Mar 11 16:06:27 <panto> don't duplicate work
Mar 11 16:06:41 <panto> your first steps are very similar
Mar 11 16:07:08 <anujdeshpande> panto: i did feel there is an overlap ..but i didn't find mention of pwm or ppm, so hopeful .
Mar 11 16:07:24 <sidbh> yeah, i guess all three of us will have first similar steps
Mar 11 16:07:47 <sidbh> but totally different output
Mar 11 16:07:59 <sidbh> panto: what do you suggest?
Mar 11 16:08:59 <panto> you both want to run S/W on the PRU
Mar 11 16:09:05 <panto> the initial steps are common to all
Mar 11 16:09:25 <panto> compile PRU code, load it, execute it
Mar 11 16:09:35 <sidbh> yepp
Mar 11 16:09:41 <panto> according to your functions, setup your pinmuxes and your peripherals
Mar 11 16:09:51 <panto> and write your ARM interface code
Mar 11 16:10:24 <panto> you are also duplicating the requirement of interfacing an ARM user-space process to PRU code
Mar 11 16:10:33 <panto> which is a different use-case from what's I've done
Mar 11 16:21:57 <sidbh> panto: so i guess there's no resolving this duplication or is there?
Mar 11 16:25:07 <panto> it's no duplication
Mar 11 16:25:16 <panto> you start the same and then split ways
Mar 11 16:42:22 <supun> Hello all,I'm new to this thread. I'm currently developing a quad copter using STM,ARM Cortex microcontroller. Could some one me what is the current situation of this project. Please ignore if I have a wrong question here
Mar 11 16:43:01 <anujdeshpande> supun: np. there are quite a few projects that are getting quad support on a bbb
Mar 11 16:43:11 <anujdeshpande> none are fully functional as per my knowledge
Mar 11 16:44:00 <anujdeshpande> look at erle drone. ardupilot, linux drone are the 2 projects that are quite on their way down this road.
Mar 11 16:45:40 <supun> thank you anujdeshpande for your quick reply. I'm not familiar with BBB. but I'm really familiar with sensors needed by a quadcopter.Their algorithms, fusing mechanisms. Can you suggest me a point to learn on BBB
Mar 11 16:47:19 <anujdeshpande> supun: do you have one ?
Mar 11 16:49:25 <supun> At this time I dont have.but I can get one tommorow. I searched google about "PRU". Can you simply explain what is PRU. As I saw from internet it is really like what currently I'm programming my microcontroller.
Mar 11 16:51:17 <sidbh> anujdeshpande: which version of PRU comp are you using
Mar 11 16:51:36 <anujdeshpande> sidbh: the one you have. native.
Mar 11 16:51:53 <sidbh> 1.1.0B1
Mar 11 16:52:54 <anujdeshpande> yepp
Mar 11 16:53:16 <sidbh> get the latest one 2.0.0B1 from jkridner, he has shared the links with me and panto
Mar 11 16:53:34 <anujdeshpande> sidbh: could you forward it ??
Mar 11 16:53:47 <anujdeshpande> he doesn't seem to be online atm
Mar 11 16:54:11 <sidbh> ok! i guess jkridner won't mind :)
Mar 11 16:55:15 <anujdeshpande> i guess :-)
Mar 11 16:55:30 <sidbh> check your mail
Mar 11 17:37:59 <sidbh> panto: have you found a way to use Cn registers for the new compilers?
Mar 11 17:39:59 <panto> sidbh, I haven't even tried
Mar 11 17:40:13 <panto> it looks awfully complicated
Mar 11 17:40:31 <panto> and the near/far thing is not making me feel better
Mar 11 17:40:36 <panto> use the old version of the compiler for now
Mar 11 17:41:09 <sidbh> ok, do tell me when you achieve this feat :)
Mar 11 17:43:21 <panto> it looks like it is very complicated :)
Mar 11 17:43:45 <panto> for not discernible reason
Mar 11 17:45:54 <sidbh> it does, it went right over my head when i tried to understand!
Mar 11 17:47:37 <sidbh> what i don't understand is why they are trying to make us give us the range of memories when there location is predefined ?
Mar 11 17:47:49 <sidbh> the Cn's
Mar 11 17:48:04 <panto> 4 registers are programmable
Mar 11 17:48:26 <panto> or is it 8?
Mar 11 17:48:33 <panto> I don't remember the exact number right now
Mar 11 17:49:32 * sidbh checks the reference guide
Mar 11 17:50:18 <sidbh> its 8
Mar 11 17:50:52 <sidbh> C24-C31
Mar 11 17:53:45 <panto> note the limitations
Mar 11 17:53:57 <panto> you can't point to an arbitrary point in memory
Mar 11 17:57:38 <sidbh> but the addresses of those are to be set by the values in registers CTPPR and CTBIR , so again why the memory range declaration of Cn registers ?
Mar 11 18:00:34 <panto> I have no idea
Mar 11 18:00:44 <panto> maybe its easier to generate code
Mar 11 18:01:39 <sidbh> i guess so, there seems to be no other reason
Mar 11 18:42:00 <sidbh> vmayoral, anujdeshpande: LorenzMeier has joined us, i guess we should discuss our plans with him
Mar 11 18:43:26 <sidbh> LorenzMeier: have you checked out our doc @ https://docs.google.com/document/d/1oL0NU4d5ZiujAuXJmI40pziRQlXCEmAf5TgK6NVDap8/edit, we have laid out a plan of what we will be doing in the coming months
**** BEGIN LOGGING AT Tue Mar 11 21:08:05 2014
**** ENDING LOGGING AT Wed Mar 12 02:59:58 2014