**** BEGIN LOGGING AT Thu Apr 01 02:59:56 2021
Apr 01 04:16:25 <DhruvaGole[m]> <jkridner "Dhruva Gole: have you spoken to "> Yes I have been in touch with lorforlinux since yesterday
Apr 01 04:57:17 <DhruvaGole[m]> lorforlinux:  Really looking forward to hearing your opinions on what jkridner has  suggested so far since yesterday. In summary:  has suggested "BeagleBone Blue is also nice with it's integrated IMU and ability to control motors." , also suggested to work on understanding how platforms like R-Pi are integrated today and give direct examples in my proposal for what integration steps I'll make for beagle support.
Apr 01 04:57:17 <DhruvaGole[m]> jkridner highly recommended integrating https://beagleboard.org/librobotcontrol and with Linux IIO as blynk as such lacks sensor support.
Apr 01 07:37:26 <DhruvaGole[m]> jkridner: I would like to shift my focus to librobotcontrol support for BeagleBone AI and Robotics Cape.
Apr 01 07:37:26 <DhruvaGole[m]> I have Software Skills: C, Linux, have past experience in embedded IOT Applications as well, so I think I am well suited for Complete implementation of librobotcontrol on BeagleBone AI.
Apr 01 08:07:47 <jduchniewicz1> ds2: Okay, see you at 9:30 PDT :)
Apr 01 08:15:30 <jduchniewicz1> The idea of accelerations on various BBs is quite compelling
Apr 01 08:16:23 <jduchniewicz1> I am wondering how the riscv will allow for various accelerations (given its NN module)
Apr 01 08:29:55 <jduchniewicz1> btw is PRU capable of doing some acceleration (I am looking at having some way to accelerate various DL models across platforms)
Apr 01 08:59:13 <pratimu[m]> jduchniewicz: PRUs are for low latency control of IO pins, so not useful for accelerating DL models
Apr 01 08:59:26 <jduchniewicz1> ah so nevermind then
Apr 01 08:59:42 <jduchniewicz1> it seems like regular BBB lacks the HW for doing any acceleration
Apr 01 08:59:46 <jduchniewicz1> beyond very trivial one
Apr 01 09:00:01 <jduchniewicz1> however, riscv seems promising
Apr 01 09:00:43 <jduchniewicz1> I know acceleration is a very device-specific thing but having a unified API would be imo very beneficial
Apr 01 09:08:30 <DhruvaGole[m]> jkridner: In librobotcontrol support for BeagleBone AI, why exactly do you believe librobotcontrol packages wont work on it? I mean it's just plain C afterall and it will work on any linux system... Then what exactly does librobotcontrol support for AI mean? What kind of support are we talking about here?
Apr 01 09:10:51 <DhruvaGole[m]> basically does it mean that I have to cross compile all [these](https://github.com/jadonk/librobotcontrol/tree/bbai) on the AI?
Apr 01 09:35:46 * DhruvaGole[m] uploaded an image: (45KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/TgKWTPQtdbmZWFAukCFEkfbT/image.png >
Apr 01 09:36:04 <DhruvaGole[m]> there are the things I have to do right? https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#87-spi
Apr 01 09:36:31 <DhruvaGole[m]> using the librobotcontrol packages
Apr 01 09:37:04 <satacker[m]> lorforlinux: are you available rn ?
Apr 01 09:53:07 <lorforlinux[m]> Hey satacker yeah go ahead, I'll try to answer your queries.
Apr 01 09:54:07 <lorforlinux[m]> Out for some work rn so no quick replies.
Apr 01 09:54:39 <satacker[m]> Can you tell me a convenient time ?
Apr 01 09:56:45 <lorforlinux[m]> Things are not predictable rn. Also, Don't let my schedule hinder your proposal completion. Please share your queries, I'll try to answer things as much as I can.
Apr 01 09:56:48 <satacker[m]> Well the first doubt i should have asked is can you explain the statement once, that would clear a lot of things
Apr 01 09:58:44 <lorforlinux[m]> Ummm, although I am not really familiar with the configfs thing.
Apr 01 09:59:43 <satacker[m]> I am too unfamiliar with configfs,  I digged up a lot and i don't think there's anything to do with device tree
Apr 01 10:00:25 <satacker[m]> I meant regarding the correlation
Apr 01 10:00:50 <satacker[m]> However there was a past proposal
Apr 01 10:00:58 <lorforlinux[m]> I researched a bit and there were some chats related to the configfs and Device Tree.
Apr 01 10:01:04 <satacker[m]> https://elinux.org/BeagleBoard/GSoC/2019Proposal/usbDeviceTreeIntegration
Apr 01 10:03:02 <satacker[m]> There's also https://lwn.net/Articles/435904/
Apr 01 10:04:08 <satacker[m]> which explains  the configfs modification to get mac address from eeprom of the peripheral
Apr 01 10:06:29 <satacker[m]>  * which explains  the drivers modification to get mac address from eeprom of the peripheral
Apr 01 10:52:52 * satacker[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/WimtReHzXuUpzesMBgqCTIEY/message.txt >
Apr 01 10:53:55 <satacker[m]> But it does in https://github.com/beagleboard/linux/blob/4.14/drivers/of/configfs.c
Apr 01 11:52:43 <jkridner> DhruvaGole[m]: librobotcontrol uses specific GPIO, I2C, SPI ports and the indexes all need to be updated to use the Cape Compatibility layer in a way that causes old BeagleBone Black + RC and BeagleBone Blue without the Cape Compatibility layer not to break.
Apr 01 11:53:40 <DhruvaGole[m]> jkridner: If you have time please go through https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Dhruva_librobot_AI
Apr 01 11:53:42 <jkridner> DhruvaGole[m]: you shouldn't need to cross-compile anything. The native compiler should be fast enough for testing.
Apr 01 11:55:07 <jkridner> I'd prefer the term implement/debug than port.
Apr 01 11:55:57 <jkridner> hmmm.... I guess porting matches this definition: https://en.wikipedia.org/wiki/Porting
Apr 01 11:56:14 <DhruvaGole[m]> yesss
Apr 01 11:56:34 <jkridner> In the past, I got some push-back on the term that it gave the connotation of more fundamental architecture differences.
Apr 01 11:58:32 <DhruvaGole[m]> okay, will keep in mind
Apr 01 12:01:19 <jkridner> DhruvaGole[m]: I suggest going into a bit more detail of all the examples and look at the interfaces on the Robotics Cape to get you a feel where the differences could be.
Apr 01 12:02:25 <DhruvaGole[m]> okay, will do that. But in all, this is somewhat similar to what you were expecting right?
Apr 01 12:02:48 <DhruvaGole[m]> Have I understood the project requirement somewhat?
Apr 01 12:04:00 <jkridner> it is a start.
Apr 01 12:04:55 <jkridner> The upstream repo is https://github.com/beagleboard/librobotcontrol
Apr 01 12:05:07 <DhruvaGole[m]> yes, I am aware
Apr 01 12:05:24 <DhruvaGole[m]> but the README isn't much in depth
Apr 01 12:05:43 <DhruvaGole[m]> Should I go through all the header and C files to get a better idea?
Apr 01 12:05:54 <jkridner> I'd like to make sure pre-work is done so you can hit the ground running on the first week of coding.
Apr 01 12:06:20 <jkridner> Perhaps we should start iterating on what needs to be put into README and https://beagleboard.org/librobotcontrol?
Apr 01 12:06:21 <DhruvaGole[m]> <jkridner "I'd like to make sure pre-work i"> okay, please can you let me know exactly what you expect as pre-work?
Apr 01 12:06:43 <DhruvaGole[m]> <jkridner "Perhaps we should start iteratin"> okay sure.. I will fork this then?
Apr 01 12:08:34 <jkridner> Things like bare_minimum shouldn't be a weekly milestone. If you've looked at the code to any degree, you should know that already works. Come week #1, you wouldn't have to have actually written a single line.
Apr 01 12:09:12 <DhruvaGole[m]> <jkridner "Things like bare_minimum shouldn"> aha okay, so then blink LED for Week 1 it is
Apr 01 12:09:21 <DhruvaGole[m]> and push button as well
Apr 01 12:10:09 <jkridner> For the buttons and LEDs, it should be thought through now how to update the GPIO abstraction. Have you seen how the Cape Compatibility layer tries to abstract the pin header locations?
Apr 01 12:11:29 <DhruvaGole[m]> <jkridner "For the buttons and LEDs, it sho"> yes just skimmed through their [wiki](https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#detailed-hardware-design)
Apr 01 12:11:48 <jkridner> Have you gotten familiar with device tree?
Apr 01 12:12:02 <DhruvaGole[m]> am in the process..
Apr 01 12:12:22 <DhruvaGole[m]> But most things seem to be marked as TODO
Apr 01 12:12:29 <jkridner> did you go through https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec ?
Apr 01 12:13:04 <DhruvaGole[m]> <jkridner "did you go through https://elinu"> no, is this different from their github wiki page?
Apr 01 12:13:27 <DhruvaGole[m]> <jkridner "did you go through https://elinu"> no...
Apr 01 12:13:30 <jkridner> you mean the SRM wiki page?
Apr 01 12:13:56 <jkridner> The SRM doesn't really go into the software interface details, though I suppose it should.
Apr 01 12:14:04 <jkridner> SRM = system reference manual
Apr 01 12:14:31 <DhruvaGole[m]> Yeah I meant this https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#beaglebone-black-cape-compatibility
Apr 01 12:14:36 <jkridner> lorforlinux[m] wrote the Cape Compatibility layer in last year's GSoC.
Apr 01 12:14:56 <DhruvaGole[m]> <jkridner "The SRM doesn't really go into t"> yes true
Apr 01 12:15:09 <jkridner> Yeah, that section needs to be written.
Apr 01 12:15:25 <DhruvaGole[m]> <jkridner "Yeah, that section needs to be w"> which section?
Apr 01 12:15:44 <DhruvaGole[m]> u mean cape board support?
Apr 01 12:16:41 <DhruvaGole[m]> yes many things are under todo there
Apr 01 12:16:50 <jkridner> I added a link to the cape interface spec to https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#beaglebone-black-cape-compatibility
Apr 01 12:17:39 <DhruvaGole[m]> aha great.. will check
Apr 01 12:18:03 <jkridner> understanding some things about device tree will be unfortunately rather necessary.
Apr 01 12:18:29 <DhruvaGole[m]> so anyways, I have to refer this and make changes in the librobotcontrol right?
Apr 01 12:18:54 <DhruvaGole[m]> <jkridner "understanding some things about "> yes without that I won't be able to understand which pins do what and how
Apr 01 12:19:15 <jkridner> The Robotics Cape is a bit odd when it comes to BeagleBone Capes in that the current revision doesn't include an identifier EEPROM.
Apr 01 12:19:38 <jkridner> When performing setup, there is a process of manually asserting a DT overlay to load.
Apr 01 12:20:27 <jkridner> The DT overlay seems to also be missing from here: https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.19.x-ti-overlays/src/arm/overlays
Apr 01 12:20:47 <DhruvaGole[m]> yes..
Apr 01 12:21:25 <jkridner> there are fully integrated DT's with roboticscape applied at https://github.com/beagleboard/BeagleBoard-DeviceTrees/tree/v4.19.x-ti-overlays/src/arm
Apr 01 12:21:37 * jkridner wishes rcn-ee would idle here.
Apr 01 12:22:15 <Abhishek[m]_> rcn-ee is so busy
Apr 01 12:23:30 <Abhishek[m]_> Yet his scripts, integration pipelines and hosting keeps the software support going for all of us
Apr 01 12:23:31 <jkridner> A good project could simply be pushing overlays upstream, now that overlays are accepted upstream. With the new u-boot 'extension', we could finally move all our cape overlay support into upstream u-boot and kernel!!
Apr 01 12:24:22 <DhruvaGole[m]> wait, but isn't that another project altogether?
Apr 01 12:24:30 <jkridner> DhruvaGole[m]: I appreciate you iterating on your proposals. Keep checking back.
Apr 01 12:24:43 <DhruvaGole[m]> That would be sort of diverting from my current objective right?
Apr 01 12:24:44 <jkridner> DhruvaGole[m]: it could be. remember the ideas are just ideas.....
Apr 01 12:25:05 <jkridner> I think you want to make sure you can come up with a proposal that you have a clear line of execution on that shows clear benefit to the community.
Apr 01 12:25:28 <Abhishek[m]_> Dhruva Gole: You’re going for librobotcontrol right?
Apr 01 12:25:32 <jkridner> the ideas are just things where mentors took the time to write down something they think can be done and might appeal to a student.
Apr 01 12:25:43 <Abhishek[m]_> +1
Apr 01 12:26:24 <jkridner> DhruvaGole[m] also did a proposal on Blynk support: https://elinux.org/BeagleBoard/GSoC/2021_Proposal/blynk_support_DhruvaG
Apr 01 12:26:41 <Abhishek[m]_> For example, U-Boot overlays is something that will benefit the whole Beagle family of boards
Apr 01 12:29:08 <DhruvaGole[m]> <Abhishek[m]_ "Dhruva Gole: You’re going for li"> Yes only today i shifted my objective to librobot control support
Apr 01 12:30:05 <DhruvaGole[m]> <Abhishek[m]_ "For example, U-Boot overlays is "> I see so u recommend i do that instead?
Apr 01 12:39:52 <Abhishek[m]_> Dhruva Gole: you might have mentioned this already - but what’s your current skillset and is there something specific skill or area you want to develop? Each of these proposals touches a different part of the system stack and has different community impact
Apr 01 12:41:00 <DhruvaGole[m]> for details you can check under [https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Dhruva_librobot_AI Experience and approach]
Apr 01 12:42:17 <DhruvaGole[m]> I have used C/c++ in more than 3-4 projects now, I also like to explore different MCUs and also have been playing with ESP32, ESP8266, raspi pico, and also have been using linux distros for quite a while now
Apr 01 12:42:57 <DhruvaGole[m]>  * I have used C/c++ in more than 3-4 projects now, I also like to explore different MCUs and also have been playing with ESP32, ESP8266, raspi pico, arduino UNO, NANO, etc and also have been using linux distros for quite a while now
Apr 01 12:43:00 <Abhishek[m]_> I see a blank page?
Apr 01 12:43:11 <Abhishek[m]_> Is it draft?
Apr 01 12:43:23 <DhruvaGole[m]> it is a draft, but should be visible
Apr 01 12:43:31 <Abhishek[m]_> I can’t see it
Apr 01 12:43:36 <DhruvaGole[m]> I checked incognito as well
Apr 01 12:43:42 <DhruvaGole[m]> can you try a diff browser maybe?
Apr 01 12:43:45 <DhruvaGole[m]> https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Dhruva_librobot_AI
Apr 01 12:44:03 <Abhishek[m]_> Yup, seeing now
Apr 01 12:44:05 <DhruvaGole[m]> <DhruvaGole[m] "I have used C/c++ in more than 3"> anyways I have mentioned the gist here
Apr 01 12:44:53 <Abhishek[m]_> If you copy paste some text, please attribute source and quote it
Apr 01 12:45:00 <DhruvaGole[m]> okayy
Apr 01 12:50:25 <ArchismanDey[m]> Abhishek:  I am working on the project idea about adding features to simpPRU, vedant16 informed me yesterday that you are going to be the primary mentor for this project. What time are you usually free to discuss progress made on the project? I also had some ideas that I would like to discuss.
Apr 01 12:51:21 <ArchismanDey[m]>  * Abhishek:  I am working on the project idea about adding features to simpPRU, vedant16  informed me yesterday that you are going to be the primary mentor for this project. What time are you usually free to discuss progress made on the project? I also had some ideas that I would like to discuss.
Apr 01 12:51:39 <Abhishek[m]_> Archisman: Hi! I am mostly free tomorrow
Apr 01 12:52:18 <ArchismanDey[m]> <ArchismanDey[m] "Abhishek:  I am working on the p"> Here is the (unfinished) draft proposal I have written till now: https://elinux.org/BeagleBoard/GSoC/2021_Proposal/simpPRU_Improvements
Apr 01 12:53:25 <ArchismanDey[m]> <Abhishek[m]_ "Archisman: Hi! I am mostly free "> Unfortunately, I have an exam and an assignment to do tomorrow, but I am free from tomorrow night and the whole weekend. Will this time work for you?
Apr 01 12:53:46 <Abhishek[m]_> Oh okay, all the best for your exam!
Apr 01 12:53:55 <Abhishek[m]_> Come back in the weekend
Apr 01 12:54:20 <DhruvaGole[m]> hey Abhishek  from my profile what do you suggest I persue?
Apr 01 12:54:23 <vedant16[m]> Archisman Dey: you have got a wrong idea of unit tests in the proposal
Apr 01 12:54:59 <ArchismanDey[m]> <vedant16[m] "Archisman Dey: you have got a wr"> What's wrong, can you elaborate?
Apr 01 12:55:38 <DhruvaGole[m]> My personal interest suggests me that I will work on implementing the current libraries of librobotcontrol to support the robot cape with the beagle AI.... so what do you suggest?
Apr 01 12:56:02 <vedant16[m]> have you seen how a unit test looks ? You run a command and then compare it's result. since it needs to be loaded on PRU
Apr 01 12:56:05 <DhruvaGole[m]>  * My personal interest is that I will work on implementing the current libraries of librobotcontrol to support the robot cape with the beagle AI.... so what do you suggest?
Apr 01 12:57:11 <Abhishek[m]_> vedant16: I suppose his idea is to test code generation, not execution
Apr 01 12:57:34 <ArchismanDey[m]> <vedant16[m] "have you seen how a unit test lo"> I thought it would be enough to test that the simpPRU to C compilation is working correctly, since pru-gcc can be assumed to be correct
Apr 01 12:58:31 <Abhishek[m]_> It’ll help prevent regressions in code gen
Apr 01 12:58:49 <Abhishek[m]_> When we start adding new features
Apr 01 12:58:55 <ArchismanDey[m]> so if the generated C code works on the host (with stub functions for the PRU specific functions), we can be reasonably sure it will also work on the PRU right?
Apr 01 12:59:29 <Abhishek[m]_> Yup, sounds like a good idea
Apr 01 12:59:31 <ArchismanDey[m]> <Abhishek[m]_ "It’ll help prevent regressions i"> Yes, that's the idea, that is why I made writing unit tests the first task in the timeline and adding features later
Apr 01 12:59:51 <vedant16[m]> <ArchismanDey[m] "I thought it would be enough to "> idt you'd need to check that
Apr 01 12:59:58 <Abhishek[m]_> Just curious, are you a CS major?
Apr 01 13:00:15 <ArchismanDey[m]> <ArchismanDey[m] "so if the generated C code works"> Plus, it would be hard to test everything on the PRU everytime it is built I think
Apr 01 13:00:27 <vedant16[m]> what I had in mind was, run a test program on pru, and then send back result through rpmsg (something like OK_ADDITION_WORKED)
Apr 01 13:00:31 <ArchismanDey[m]> <Abhishek[m]_ "Just curious, are you a CS major"> I am majoring in Electronics and Electrical with minor in CS
Apr 01 13:00:49 <Abhishek[m]_> Okay
Apr 01 13:00:49 <vedant16[m]> <ArchismanDey[m] "Plus, it would be hard to test e"> yes than can be done ✅
Apr 01 13:01:22 <Abhishek[m]_> Do you happen to have a course on compilers or have read theory on it!
Apr 01 13:01:25 <Abhishek[m]_> *?
Apr 01 13:01:43 <ArchismanDey[m]> <vedant16[m] "what I had in mind was, run a te"> It would be hard to test like this everytime I am making a change right?
Apr 01 13:02:09 <Abhishek[m]_> I don’t think so, if you can make a CI pipeline for it
Apr 01 13:02:52 <ArchismanDey[m]> <Abhishek[m]_ "Do you happen to have a course o"> I had a course on context free grammars etc, and learnt about how lexers and parsers work while working on a personal project for symbolic differentiation
Apr 01 13:03:21 <Abhishek[m]_> So what vedant is saying is referred to in industry as end-to-end testing. And you’re proposing unit tests with stubs and mocks
Apr 01 13:04:04 <ArchismanDey[m]> <Abhishek[m]_ "I don’t think so, if you can mak"> Okay, I will look into this. Maybe we can test the PRU specific functions like this, and the language features like I imagined 🤔
Apr 01 13:04:27 <ArchismanDey[m]> <Abhishek[m]_ "So what vedant is saying is refe"> Yes, I understood
Apr 01 13:05:04 <Abhishek[m]_> Your theory background should be helpful and allow faster ramp up should the proposal be chosen
Apr 01 13:05:53 <ArchismanDey[m]> Btw, another thing I had in mind was to implement a (maybe Python) library based on the functions in simpPRU, which is currently a console app and cannot really be automated
Apr 01 13:06:32 <Abhishek[m]_> Stuff all your thoughts up in your proposal and then prioritize with our inputs
Apr 01 13:06:58 <ArchismanDey[m]> <ArchismanDey[m] "Btw, another thing I had in mind"> so someone could write a program in simpPRU sending stuff through rpmsg in real time, then get the results in Python and do whatever they wanted with the data in the host
Apr 01 13:07:18 <Abhishek[m]_> Yup, sounds cool
Apr 01 13:08:29 <vedant16[m]> <Abhishek[m]_ "I don’t think so, if you can mak"> Cl pipeline on hardware?
Apr 01 13:08:42 <Abhishek[m]_> No, software
Apr 01 13:08:52 <Abhishek[m]_> You build and run scripts
Apr 01 13:09:20 <Abhishek[m]_> Everytime new commit, load code in PRU and run test suite
Apr 01 13:09:31 <ArchismanDey[m]> <ArchismanDey[m] "so someone could write a program"> I was going through the rpmsg, remoteproc docs and the simppru-console code, and how to write Python libraries today, I have not gathered enough details yet, but should be done by the weekend.
Apr 01 13:09:56 <vedant16[m]> <Abhishek[m]_ "Everytime new commit, load code "> You'd need a bb farm for that right?
Apr 01 13:10:12 <Abhishek[m]_> Not necessarily
Apr 01 13:10:26 <vedant16[m]> <ArchismanDey[m] "I was going through the rpmsg, r"> there's a library already I think
Apr 01 13:10:50 <vedant16[m]> Abhishek do you remember, mvudin has made a pru python library
Apr 01 13:11:02 <Abhishek[m]_> I think so
Apr 01 13:11:15 <vedant16[m]> <Abhishek[m]_ "Not necessarily"> then pre commit hooks ig
Apr 01 13:11:23 <vedant16[m]> check these Archisman
Apr 01 13:13:00 <ArchismanDey[m]> <vedant16[m] "check these Archisman"> What exactly? Can you provide a link?
Apr 01 13:13:46 <vedant16[m]> https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
Apr 01 13:14:13 <ArchismanDey[m]> Sorry, I replied to the wrong message
Apr 01 13:14:27 <ArchismanDey[m]> <vedant16[m] "Abhishek do you remember, mvudin"> I meant to ask about this one
Apr 01 13:14:56 <vedant16[m]> let me lookup
Apr 01 13:15:13 <ArchismanDey[m]> There was a link to a project about using Python for the PRU, but that was similar to PRUspeaks rather than like simpPRU as far as I know
Apr 01 13:15:17 <ArchismanDey[m]> in the ideas list
Apr 01 13:15:59 <ArchismanDey[m]> <vedant16[m] "let me lookup"> Sure
Apr 01 13:18:12 <vedant16[m]> <ArchismanDey[m] "There was a link to a project ab"> it runs a VM on PRU
Apr 01 13:18:13 <vedant16[m]> simppru compiles directly
Apr 01 13:18:17 <vedant16[m]> to C
Apr 01 13:18:22 <ArchismanDey[m]> Yes
Apr 01 13:18:35 <ArchismanDey[m]> <vedant16[m] "simppru compiles directly"> which I think is a massive improvement
Apr 01 13:18:57 <ArchismanDey[m]> since PRU is meant for fast realtime functions anyway
Apr 01 13:20:49 <ArchismanDey[m]> so what I was suggesting is, native code runs on PRU and sends rpmsg data to host, which is now received using simppru-console, which cannot really be automated, so a python library exposing the functions in simppru-console could be pretty useful right?
Apr 01 13:21:39 <Abhishek[m]_> Agreed
Apr 01 13:22:19 <vedant16[m]> <ArchismanDey[m] "so what I was suggesting is, nat"> yeah, but it doesn't do much other than using sysfs interface
Apr 01 13:22:45 <vedant16[m]> Abhishek: do you remember the github account of zmatt ? it was mvudin something
Apr 01 13:23:03 <ArchismanDey[m]> <vedant16[m] "yeah, but it doesn't do much oth"> It would be a very small library, true
Apr 01 13:24:27 <ArchismanDey[m]> <ArchismanDey[m] "It would be a very small library"> only 4 functions, start, stop, send, receive I think
Apr 01 13:26:07 <Abhishek[m]_> Vedant matthijs van duin
Apr 01 13:26:14 <ArchismanDey[m]> It's not the Python library by itself though, it's simpPRU working with the library that would be useful I think
Apr 01 13:26:16 <vedant16[m]> yeah
Apr 01 13:26:23 <Abhishek[m]_> Not sure if I got his full name correct
Apr 01 13:26:41 <vedant16[m]> yes, right name
Apr 01 13:27:28 <vedant16[m]> https://github.com/mvduin/py-uio
Apr 01 13:27:31 <vedant16[m]> Archisman Dey:
Apr 01 13:28:30 <vedant16[m]> <ArchismanDey[m] "only 4 functions, start, stop, s"> Also, if time is there, can you add arrays in simppru.
Apr 01 13:29:06 <ArchismanDey[m]> <vedant16[m] "https://github.com/mvduin/py-uio"> will look into this
Apr 01 13:30:32 <ArchismanDey[m]> <vedant16[m] "Also, if time is there, can you "> Yes, I was thinking about this too, and also the ability to send more than just one integer through rpmsg
Apr 01 13:30:59 <vedant16[m]> yes, if you need to add strings, array will be a precursor to it.
Apr 01 13:31:21 <vedant16[m]> but before that I think double/float support will be useful
Apr 01 13:31:32 <vedant16[m]> 1) float/double
Apr 01 13:31:32 <vedant16[m]> 2) array support
Apr 01 13:31:32 <vedant16[m]> 3) strings
Apr 01 13:31:40 <vedant16[m]> what do you think ?
Apr 01 13:32:00 <Abhishek[m]_> No float/double first. It’ll complicate stuff
Apr 01 13:32:19 <Abhishek[m]_> Fixed point arithmetic should fit better
Apr 01 13:32:59 <ArchismanDey[m]> <ArchismanDey[m] "Yes, I was thinking about this t"> Imagine you wan't to send some input every 1ms to the host, if we can only send one integer at a time, we would need to send 1000 messages per second, which might be hard for the host to do if it's also running other things, sending one array of 100 ints 10 times a second would be helpful
Apr 01 13:33:03 <vedant16[m]> <Abhishek[m]_ "Fixed point arithmetic should fi"> but, pru supports floats right ?
Apr 01 13:33:21 <Abhishek[m]_> I don’t remember if it does
Apr 01 13:33:31 <ArchismanDey[m]> > <@archismandey:matrix.org> Yes, I was thinking about this too, and also the ability to send more than just one integer through rpmsg
Apr 01 13:33:31 <ArchismanDey[m]>  * Imagine you wan't to send some input every 1ms to the host, if we can only send one integer at a time, we would need to send 1000 messages per second, which might be hard for the host to process if it's also running other things, sending one array of 100 ints 10 times a second would be helpful ig
Apr 01 13:33:42 <Abhishek[m]_> The compiler supports, but it’ll pull software floating point libs
Apr 01 13:33:45 <vedant16[m]> ** pulls up pru-gcc wiki
Apr 01 13:33:55 <Abhishek[m]_> Which will bloat code
Apr 01 13:34:42 * ArchismanDey[m]  < https://matrix.org/_matrix/media/r0/download/matrix.org/mbviibghXIPKrDmwOWdqiRBU/message.txt >
Apr 01 13:34:51 <Abhishek[m]_> Yup
Apr 01 13:35:25 <Abhishek[m]_> Note that we are transpiling code and gcc will compile; so we might attempt some kind of pass through maybe?
Apr 01 13:35:40 <DhruvaGole[m]> <jkridner "Things like bare_minimum shouldn"> actually, that isnt the week 1 milestone, there are several other things like setting up board, flashing the correct image, etc. after which one of the steps to make sure things are working is the bare min code... after that if you see I have also mentioned that I will make the blink and led libraries compatible with AI... hence that is the actual milestone of week 1
Apr 01 13:36:21 <ArchismanDey[m]> <Abhishek[m]_ "Note that we are transpiling cod"> as in?
Apr 01 13:36:29 <Abhishek[m]_> Dhruva Gole: setup should happen during community bonding period if that hasn’t changed this year
Apr 01 13:36:34 <vedant16[m]> <ArchismanDey[m] "> <@vedant16:matrix.org> 1) floa"> yup, right
Apr 01 13:36:52 <Abhishek[m]_> Archisman Dey: transpiling means compiling one source code to anothet
Apr 01 13:37:12 <Abhishek[m]_> So simpPRU converts what you express to C
Apr 01 13:37:15 <ArchismanDey[m]> <Abhishek[m]_ "Archisman Dey: transpiling means"> got this part, what does pass through mean here?
Apr 01 13:37:25 <vedant16[m]> I had some brain storming for char array last time, but it seemed a big task
Apr 01 13:37:43 <vedant16[m]> ask handling string arithmetic, is diff than numeric ones
Apr 01 13:37:48 <vedant16[m]> https://github.com/dinuxbg/gnupru/wiki
Apr 01 13:38:06 <Abhishek[m]_> Archisman Dey: if the syntax for arrays is simple enough, you can just transform it to C directly
Apr 01 13:38:12 <DhruvaGole[m]> <Abhishek[m]_ "Dhruva Gole: setup should happen"> but I dont even have the beaglebone AI neither the Robotic cape..
Apr 01 13:38:16 <vedant16[m]> dmitri has added a lot of docs, * excited
Apr 01 13:38:40 <DhruvaGole[m]> <DhruvaGole[m] "but I dont even have the beagleb"> am I expected to buy this prior to the acceptance itself?
Apr 01 13:38:49 <vedant16[m]>  * as handling string arithmetic, is diff than numeric ones
Apr 01 13:38:51 <ArchismanDey[m]> <Abhishek[m]_ "Archisman Dey: if the syntax for"> Oh, okay
Apr 01 13:38:51 <Abhishek[m]_> Dhruva Gole: getting hardware to you, should you be selected is org’s responsibility
Apr 01 13:39:03 <DhruvaGole[m]> <Abhishek[m]_ "Dhruva Gole: getting hardware to"> right okay..
Apr 01 13:39:41 <Abhishek[m]_> Archisman Dey: string operations will need a bit of care to handle to transform to appropriate C code or function like strcat
Apr 01 13:40:40 <ArchismanDey[m]> <Abhishek[m]_ "Archisman Dey: string operations"> we can write the strcat function in simpPRU and compile it along with the code right?
Apr 01 13:41:03 <Abhishek[m]_> Think of suitable approaches
Apr 01 13:41:21 <vedant16[m]> no strcat in simppru, remember it has to be like python
Apr 01 13:41:58 <vedant16[m]> I think he meant while code translation, convert `"ab" + "bc"` to `strcat("ab", "bc")`
Apr 01 13:42:05 <Abhishek[m]_> vedant16: that’s pushing complexity into simpPRU. It’s a design choice we have to make
Apr 01 13:42:27 <vedant16[m]> yes
Apr 01 13:42:31 <vedant16[m]> agreed
Apr 01 13:42:32 <ArchismanDey[m]> <vedant16[m] "I think he meant while code tran"> Oh, okay
Apr 01 13:42:53 <Abhishek[m]_> Considering that we are compiling code to C
Apr 01 13:43:05 <Abhishek[m]_> And not have a runtime to do stuff for us
Apr 01 13:43:30 <ArchismanDey[m]> <ArchismanDey[m] "Oh, okay"> is this even possible with static arrays
Apr 01 13:44:39 <ArchismanDey[m]> I will think about possible approaches that can be reasonably completed within time period of GSoC
Apr 01 13:44:49 <vedant16[m]> cool
Apr 01 13:59:59 <satacker[m]> Abhishek did you take a look at beagle config?
Apr 01 14:13:31 <Abhishek[m]_> Just opened
Apr 01 14:19:03 <Abhishek[m]_> Why do I feel like you’ve copied rpi-config features?
Apr 01 14:20:36 <satacker[m]> Yes i have
Apr 01 14:21:13 <satacker[m]> But i don't think i can copy raspi-config
Apr 01 14:22:29 <Abhishek[m]_> There’s also armbian-config that you can check out
Apr 01 14:25:40 <Abhishek[m]_> Prioritize your features
Apr 01 14:26:03 <Abhishek[m]_> In order of most important first to good to have later
Apr 01 14:30:17 <satacker[m]> I will make the changes and verify the board features for the functionality, if something i missed
Apr 01 16:55:21 <DhruvaGole[m]> hey jkridner  are you available now?
Apr 01 16:56:16 <DhruvaGole[m]> I have made a few changes as you'd told earlier, to add some info about the pins, and add ref to the SRM..  visit https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Dhruva_librobot_AI
Apr 01 16:57:02 <jkridner[m]1> I’m running errands.
Apr 01 16:57:45 <DhruvaGole[m]> when will you be available?
Apr 01 17:30:36 <ds2> hmmmm
Apr 01 17:37:58 <jduchniewicz1> did you have time to look at my proposal ds2 ?
Apr 01 17:39:14 <ds2> I didn't see hte URL
Apr 01 17:39:22 <ds2> can you paste it again?
Apr 01 17:40:00 <jduchniewicz1> https://elinux.org/BeagleBoard/GSoC/2021_Proposal/YOLO_models_on_the_X15/AI
Apr 01 17:41:40 <DhruvaGole[m]> <ds2 "hmmmm"> Pardon? Is that a reaction to my proposal? 😅
Apr 01 17:46:37 <ds2> DhruvalGole[m]: what proposal?
Apr 01 17:46:50 <DhruvaGole[m]> <DhruvaGole[m] "I have made a few changes as you"> this
Apr 01 17:47:05 <ds2> jduchniewicz1: Are you going for a YOLOv3 or bust strategy?
Apr 01 17:47:15 <ds2> DhruvaGole[m]: link please
Apr 01 17:47:27 <DhruvaGole[m]> <ds2 "Dhruva Gole: link please"> https://elinux.org/BeagleBoard/GSoC/2021_Proposal/Dhruva_librobot_AI
Apr 01 17:48:47 <jduchniewicz1> ds2:  honestly, I am open to changes :) however it would be nice to support it. Maybe I should introduce a contingency for adding YOLOv2 if v3 is impossible due to something
Apr 01 17:50:34 <ds2> jduchniewicz1: well... I am sure which to suggest - On one hand, it would nice to suggest a fall back to v3-tiny, v2, v2-tiny... on the other hand, since this is a shorten (compared to last year) GSoC, will there be time to fall back
Apr 01 17:52:05 <jduchniewicz1> ideally I would do some pre-work and just check if the model will compile with TIDL before
Apr 01 17:52:20 <jduchniewicz1> maybe I can run it and check
Apr 01 17:52:36 <jduchniewicz1> because this would quickly alleviate one of the doubts
Apr 01 17:53:38 <ds2> DhruvaGole[m]: IIRC - there was a project before for compat btwn the different bones... might want tp reference/build on that
Apr 01 17:54:21 <ds2> jduchniewicz1: that would help or maybe mention the tiny version as an option for even higher framerates with some trade offs
Apr 01 17:54:36 <jduchniewicz1> right
Apr 01 17:55:08 <DhruvaGole[m]> <ds2 "Dhruva Gole: IIRC - there was a "> Name of project/ any link?
Apr 01 17:56:14 <ds2> DhruvaGole[m]: don't recall the name... it is within the last 2-3 years for sure
Apr 01 17:56:52 <ds2> jduchniewicz1: any estimated timings goals? <1sec/frame, <0.1/frame, <10sec/frame?
Apr 01 17:57:45 <ds2> jduchniewicz1: also, what's the expected deliverable at the end? a GH repo or a fork of darknet or ?
Apr 01 17:58:07 <jduchniewicz1> no idea atm, looking at Jetson Nano they could achieve 1-2 FPS so I would aim for something similar
Apr 01 17:58:44 <jduchniewicz1> I would like to have a repository and probably develop it further into something more extensible
Apr 01 17:59:02 <jduchniewicz1> assuming there is a need for such things in the community
Apr 01 17:59:57 <satacker[m]> Do you mean a repo where implementations for beaglebone AI are showcased with benchmarks?
Apr 01 18:00:47 <jduchniewicz1> yes, with API for easy usage of them in applications
Apr 01 18:00:57 <ds2> jduchniewicz1: I wonder if it is also useful to capture the used and unused/free computing resources
Apr 01 18:01:22 <ds2> so if you are doing something else, how much CPU is available after this is running in the background
Apr 01 18:01:31 <DhruvaGole[m]> I just came across lorforlinux 's intro vdo
Apr 01 18:01:31 <DhruvaGole[m]> [Heree](https://www.element14.com/community/thread/76738/l/cape-compatibility-bb-ai-and-bbb)
Apr 01 18:01:45 <jduchniewicz1> the ultimate goal is to have the user have the option to choose between utilizing various resources (types of acceleration)
Apr 01 18:01:52 <ds2> DhruvaGole[m]: think that's the one
Apr 01 18:01:59 <jduchniewicz1> And maybe deploy custom models (though that is more difficult)
Apr 01 18:02:17 <jduchniewicz1> ds2:  noted
Apr 01 18:02:45 <DhruvaGole[m]> If this does what it says it does, then all BBB codes/lobs should seemlessly run on the BBAI as well right?  Then my entire project proposal has been rendered useless/already done or what?
Apr 01 18:02:49 <ds2> jduchniewicz1: another point - might want to point out - this should work w/o retraining so one can take a pre-trained weight and redeployed
Apr 01 18:03:13 <ds2> think their may be a PnP related project doing that (PnP = Pick And Place)
Apr 01 18:03:22 <jduchniewicz1> yes, this is the assumption
Apr 01 18:03:29 <jduchniewicz1> we only accelerate the architercture
Apr 01 18:03:45 <ds2> DhruvaGole[m]: talk with the author... I think lorforlinux is here
Apr 01 18:04:02 <jduchniewicz1> havining custom transfer learning models would be something for future
Apr 01 18:04:26 <ds2> jduchniewicz1: I think it'd help to make it explicit... the proposal will be read by all the mentors and each of us has different skills and backgrounds
Apr 01 18:04:29 <jduchniewicz1> however, no idea how people use this architecture for TL
Apr 01 18:04:59 <jduchniewicz1> ds2:  yes, this is not clear enough in the proposal, thank you for noticing that
Apr 01 18:05:46 <ds2> neither do I but other then using the weak GPU, there isn't much of a choice
Apr 01 18:07:02 <ds2> jduchniewicz1: another intro point - this is for inference only... it'd cut down on questions like 'how can it help with training'
Apr 01 18:16:32 * DhruvaGole[m] uploaded an image: (135KiB) < https://matrix.org/_matrix/media/r0/download/matrix.org/RJOhkAoPyBLebrpkemSnHQyI/20210401_224607_8912452572773773201.jpg >
Apr 01 18:16:57 <DhruvaGole[m]> Is there any reason for librobotcontrol to now work even inspite of having this DT overlay??
Apr 01 20:19:52 * DevendraKharolia  < https://matrix.org/_matrix/media/r0/download/matrix.org/cgVHqflwbDMcUyqCDaNzgLAO/message.txt >
Apr 01 20:21:04 <satacker[m]> Hi, I am a student too. Did you complete cross compilation task given in requirements on the ideas page?
Apr 01 20:22:58 <DevendraKharolia> Yeah, I am on it
Apr 01 22:06:42 <DevendraKharolia> Completed cross compilation task and sent a PR
**** ENDING LOGGING AT Fri Apr 02 02:59:57 2021