**** BEGIN LOGGING AT Thu Apr 14 02:59:58 2016 Apr 14 15:47:19 jkridner: do you hold regular meetings here, or in hangout ? Apr 14 16:53:04 jkridner, alexhiam: Have any queries/doubts regarding the blue project? Apr 14 16:54:14 kiran4399: some.... Apr 14 16:54:36 yeah.. Apr 14 16:55:12 jkridner: Oh.. Apr 14 16:55:35 I hope my proposal is not bad.. :-( Apr 14 16:55:49 jkridner:^^ Apr 14 17:00:29 jkridner: and btw did you see the pull request for mpu 9250? Apr 14 17:00:38 rcnee merged it. Apr 14 17:00:48 kiran4399: I didn't think it was bad, but I did have some queries. Apr 14 17:01:40 jkridner: actually on the day when you commented on docs.. I was in train.. I answered them.. but could not reach them out to you.. Apr 14 17:02:01 jkridner: anyway... can you ask now? Apr 14 17:02:33 having several distractions right now.... working on wireless connectivity stuff for BeagleBone. Apr 14 17:04:25 jkridner: beaglebone blue? Apr 14 17:04:33 yeah Apr 14 17:04:43 cool!!! are the overlays done? Apr 14 17:04:47 no. Apr 14 17:05:17 alexhiam: ping. Apr 14 17:05:31 jkridner: will you be free today? Apr 14 17:05:41 there is a "BealgeBone Black Wireless" dtb... Blue uses the same wifi/bt connections. Apr 14 17:05:54 jkridner: yeah.. seen that.. Apr 14 17:06:11 jkridner: will there be a main dtb for the blue? Apr 14 17:06:23 or will there be a set of dtb's for the blue? Apr 14 17:07:24 kiran4399: I'm trying to multitask... bringing up the summerofcode site. Apr 14 17:07:52 * jkridner appreciates potential students continuing to reach out and refine ahead of the final selection. Apr 14 17:10:30 kiran4399: ah, now I remember... I wanted to know how you were going to profile.... I am very concerned that the kernel drivers performance needs to be as fast or faster than the userspace drivers. Apr 14 17:11:04 they will definitely be faster.. Apr 14 17:11:11 jkridner: are you asking me how to test that? Apr 14 17:11:15 kiran4399: there needs to be a low-latency way to operate on IMU data. I think the userspace API registers callback functions. Apr 14 17:11:23 kiran4399: which will be faster? Apr 14 17:11:38 jkridner: kernel space.. Apr 14 17:11:49 kiran4399: I don't think there's a SUSTAINABLE reason why the kernel drivers shouldn't be faster. Apr 14 17:11:50 ok. Apr 14 17:12:04 kiran4399: but, are you still providing the right userspace hooks/api? Apr 14 17:12:15 kiran4399: because we want the balance.c to be a userspace app. Apr 14 17:12:43 what data rates is needed? Apr 14 17:12:45 jkridner: balance.c is for the balance charging right? Apr 14 17:12:51 kiran4399: anyway, I'm asking how you'll measure the performance.... how will you compare the latency between IMU/timer events for the MMAP implementation vs. the kernel implementation. Apr 14 17:13:04 kiran4399: no, it is to balance a 2-wheel robot. Apr 14 17:13:10 kiran4399: did you see the videos? Apr 14 17:13:13 Oh.. Apr 14 17:13:14 yeah.. Apr 14 17:13:22 I remember.. that uc davis video right? Apr 14 17:13:25 balance.c is the app that keeps the robot standing up. Apr 14 17:13:29 uc san diego. Apr 14 17:13:33 yeah.. Apr 14 17:16:20 so, do you know how you will measure the performance? Apr 14 17:16:53 * jkridner happens to love oscilloscopes for profiling Apr 14 17:17:43 for profiling.. we can use oscilloscopes.. Apr 14 17:18:04 kiran4399: but there are even programs to measure the latency right? Apr 14 17:18:12 k. do you know what the hardware event is that starts the latency measure? is there an interrupt? Apr 14 17:18:19 jkridner: ^^ Apr 14 17:19:49 kiran4399: yeah, but software has a somewhat larger lag and overhead. Apr 14 17:19:59 jkridner: it depends on the device which we are using.. yeah.. but there is generally an interrupt.. Apr 14 17:21:15 jkridner: but don't you think it is trivial that the one clear advantage kernel drivers takes over the userspace ones is low latency.. Apr 14 17:21:21 I think the inner loop of the lag-lead compensator takes a 200Hz (5ms) interrupt from the (IMU?) collects the value over I2C, performs a calculation and updates PWM values for motor drive strength. Apr 14 17:21:29 jkridner: because they are directly communicating with the kernel? Apr 14 17:21:57 kiran4399: sure, but only if you can do *everything* in kernel space. balance.c is still a userspace app. Apr 14 17:22:48 kiran4399: so, the kernel/userspace boundary is still in question. can the callback be executed in the context of the kernel? does the API still work? Apr 14 17:23:14 balance.c is an example program which will be using the userspace app that directly communicates with the kernel driver.. Apr 14 17:23:20 if the callback must be implemented in userspace, can the transition be done only once in the right place and save the multiple-transition overhead. Apr 14 17:23:44 kiran4399: yes, but it is the latency to the end of .... Apr 14 17:23:48 let me dig up the specifics for you. Apr 14 17:23:53 jkridner: OK.. Apr 14 17:24:41 I believe the callback is registered here: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/balance/balance.c#L300 Apr 14 17:25:42 this read is probably doing a userspace/kernel context switch: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/balance/balance.c#L431 Apr 14 17:25:43 hmm.. Apr 14 17:27:04 that's probably bad. if the callback was somehow called with the value, that might be a reasonable modification to the API that could be implemented efficiently in the MMAP userspace version as well (and performance improved in the kernel version). Apr 14 17:27:46 jkridner: you mean to say the kernel implementation is probably bad here? Apr 14 17:28:04 update of the PWMs happens here: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/balance/balance.c#L609 Apr 14 17:28:39 kiran4399: I'm saying that you have to think about the approach. Apr 14 17:29:43 the bad part is that there is a call to read the IMU within balance_core()... today, that does not involve a userspace/kernel transition because it is done with mmap(). Apr 14 17:30:22 jkridner: but callbacks can be eliminated with a kernel driver implementation right? Apr 14 17:30:32 a kernel implementation of the IMU read will require the userspace balance_core() to make a transition into kernel space and back again... losing all performance benefits. Apr 14 17:31:05 you want to minimize the transitions... the interrupt is going to cause a transition into kernel space (if not already idle there)... Apr 14 17:31:37 you'd want to have that interrupt trigger the IMU read without transitioning to userspace like the current API seems to require. Apr 14 17:32:37 it seems reasonable to me that the API could be modified to provide the IMU value as an argument to the callback and that that approach wouldn't hurt the MMAP implementation, but would move the IMU read into the library code. Apr 14 17:32:50 kiran4399: anyway, that's the sort of stuff I didn't see thought out. Apr 14 17:34:01 bradfa, alexhiam, ds2, mdp, karki_: any thoughts on my statements above to make sure kiran4399 gets my point and I'm on track? Apr 14 17:34:11 hi arianepaola, ebadawy! Apr 14 17:34:22 arianepaola: did you see resin.io's etcher.io? Apr 14 17:34:50 arianepaola: seems they used a new nw.js-like solution. Apr 14 17:34:58 i think you are jumping the ahead - what is the datarate/latency requirements? Apr 14 17:35:08 IIO offers a mmap interface too Apr 14 17:35:09 arianepaola: looks pretty slick. definitely something to integrate with beaglebone-getting-started. Apr 14 17:35:33 w/o knowing, you're just turning knobs Apr 14 17:35:52 ds2: 200Hz with a roughly 1.6ms worst-case latency (to match the userspace mmap implementation performance) Apr 14 17:37:00 ds2: oh? so the value could be stuck in a shared memory location and the IMU read data (if not the read itself) could still be done in the userspace API without generating a kernel-space transition? Apr 14 17:37:45 ds2: I believe 1ms of that roughly 1.6ms is spent in performing the I2C IMU read. Apr 14 17:38:29 jkridner: which sensor is running at 200Hz? Apr 14 17:39:00 MPU-9250 Apr 14 17:39:05 the IMU. Apr 14 17:39:47 no, which sensor in the MPU9xxx Apr 14 17:39:53 both. Apr 14 17:40:03 the MPU9xxx is a MPU6xxx + Mag; MPU6xxx is a gyro/accel Apr 14 17:40:08 gyro/accel/compass Apr 14 17:40:22 yeah, my understanding is both. Apr 14 17:40:38 I suspect you will have a hard time, if not impossible time reading all 3 at 200Hz w/o drops Apr 14 17:41:03 AFAIK, the Mag doesn't have a FIFO; for 200Hz, you most likely want to start using the FIFO for the acc/gyr Apr 14 17:41:19 is this over i2c or spi? (chip supports both) Apr 14 17:41:50 https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/libraries/imu/mpu9150.c#L262 Apr 14 17:41:52 I2C Apr 14 17:42:07 and w/o the DMP - I would question how well correlated are the 3 readings Apr 14 17:43:05 why do you say "w/o the DMP"? Apr 14 17:43:22 read_dmp? didn't think they provide firmware for opensource uses like this Apr 14 17:43:54 the MPU6xxx has an internal processor, the DMP. It can preprocess stuff locally or you can disable the DMP and read the sensors directly via I2C/SPI Apr 14 17:44:09 code came from Linux. Apr 14 17:44:28 he's using the DMP to timestamp the data. Apr 14 17:45:45 what is the license of the code? Apr 14 17:46:01 I see firmware and stuff in there Apr 14 17:46:14 headers say see License.txt but I don't see that checked in Apr 14 17:47:09 interesting, I don't see any license info Apr 14 17:47:25 think I'll take a few steps away from this... Apr 14 17:47:30 ds2: :( --- I'm sure we just need to educate James and he'll update. Apr 14 17:48:00 jkridner: someone should confirm that this is allowed Apr 14 17:48:12 The copyright headers are there and we can confirm with James where this comes from. Apr 14 17:48:15 on android the dmp (AFAIK) is handled by closed source libraries Apr 14 17:48:39 Copyright (C) 2011-2012 InvenSense Corporation, All Rights Reserved. Apr 14 17:48:40 See included License.txt for License information. Apr 14 17:48:50 but Licenses.txt is not there Apr 14 17:51:22 hmmm... http://www.pansenti.com/ :( Apr 14 17:53:32 frightening: https://pansenti.wordpress.com/ Apr 14 17:54:23 https://github.com/vmayoral/bb_mpu9150/blob/master/src/linux-mpu9150/mpu9150/mpu9150.c Apr 14 17:55:01 looks like it was part of our GSoC 2 years ago. Apr 14 17:55:15 or 3 or whatever it was. Apr 14 17:55:19 3 Apr 14 17:55:21 :-) Apr 14 17:57:38 same problem Apr 14 17:58:02 stuff is in eMPL Apr 14 17:58:13 it too refers to a License.txt Apr 14 17:58:42 jkrdiner: can I take a device say mpu6050, connect it to bb black.. use the kernel drivers in one case and the userspace driver in another case, take the observations and let you know the results?? Apr 14 17:58:49 jkridner: ^^ Apr 14 17:59:25 ds2: where are you seeing eMPL? Apr 14 17:59:38 jkridner: I'll probably use a small example application to work this out Apr 14 17:59:43 https://github.com/vmayoral/bb_mpu9150/blob/master/src/linux-mpu9150/LICENSE Apr 14 18:00:02 jkridner: same repo Apr 14 18:00:05 look at the eMPL directory Apr 14 18:00:27 kiran4399: ok... but the pass/fail condition in my mind is balance_core() taking less than 1.6ms (including interrupt latency to start the callback). Apr 14 18:01:19 ah, this part: https://github.com/vmayoral/bb_mpu9150/tree/master/src/linux-mpu9150/eMPL Apr 14 18:01:35 jkridner: but I don't have an mpu 9150 to do that.. Apr 14 18:01:53 does the mpu9150.c reference that eMPL code? Apr 14 18:02:04 kiran4399: I'll make sure you get an MPU-9250. Apr 14 18:02:35 jkridner: I mean to say now... :-P Apr 14 18:03:21 yes Apr 14 18:03:34 eMPL is what does the magic to enable the DMP on the MPU6xxx Apr 14 18:03:48 eMPL is the invense SDK Apr 14 18:04:14 a download now requires an account on the invensense website Apr 14 18:06:16 <_av500_> ds2: invensense? Apr 14 18:07:21 _av500_: MPU9xxx Apr 14 18:07:36 jkridner: it may be okay - http://diydrones.com/profiles/blogs/invensense-releases-licence-to-allow-use-of-the-mpu-6000-dmp-proc Apr 14 18:07:40 <_av500_> ds2: I have a contact there if you need something Apr 14 18:07:48 but w/o the Licenses.txt, we donno Apr 14 18:08:39 _av500_: GSoC projects are using their code and it pulled in parts of the SDK (for the DMP support); but there is no clear license on it. it just says refer to license.txt in the header Apr 14 18:08:39 _av500_: yes, please. Apr 14 18:08:40 jkridner: BTW.. how is the making of bb blue going on?? will one or two be ready for the project this summer? Apr 14 18:09:15 better if I can leave this chat ;-) Apr 14 18:09:22 kiran4399: I'll get you something. Apr 14 18:09:36 _av500_: so I am concerned there may be limitations on how we can approach the project; moving things into the kernel forces stuff to be GPL'ed. the 2 examples jkridner pointed to are BSD or BSD like and userspace Apr 14 18:09:37 if you are approved. Apr 14 18:10:27 ds2: could mean a write from scratch. :( Apr 14 18:10:30 _av500_: the part that came from invense is their SDK which now requires a login Apr 14 18:10:40 jkridner: OK.. meanwhile that mpu6050 thing I asked before... shall I try it now and let you know the results? Apr 14 18:10:55 jkridner: can't... the DMP is not documented so unless you want to dump it... (apparently there is an older code base w/o the DMP) Apr 14 18:11:06 <_av500_> ds2: jkridner: I know nothing, so I need a "good" question to ask Apr 14 18:12:03 _av500_: Question for starters is - "What is the license for the Emotion SDK for the MPU6xxx line?" and does that (from their point of view) apply to the MPU9xxx Apr 14 18:12:16 kiran4399: you are going to do something and report w/o something else clear to do? sure! Apr 14 18:12:30 <_av500_> ds2: pls email Apr 14 18:12:32 <_av500_> me Apr 14 18:12:34 'k Apr 14 18:12:37 <_av500_> thx Apr 14 18:12:55 jkridner: w/o something else clear to do? I did'nt get that.. Apr 14 18:16:26 kiran4399: I don't know how important it is for you to do what you are mentioning. Doing something is good. Apr 14 18:17:26 jkridner: anyway.. I am little free now.. so thought of trying it. Apr 14 18:19:56 _av500_, jkridner: email sent Apr 14 18:20:32 <_av500_> ds2: yes, thx Apr 14 18:20:42 included a little background Apr 14 18:20:58 <_av500_> ya Apr 14 18:52:46 hi jkridner Apr 14 18:52:51 sorry I wasn't there Apr 14 18:53:54 no worries. how are things? Apr 14 18:54:16 great, thanks for asking. Apr 14 18:54:57 I had some talk with amragaey to day, he toke my BBB to make some tests with it Apr 14 18:55:43 are you in the same place? Apr 14 18:55:52 are you in contact with DiegoTc at all? Apr 14 18:56:52 yeah, we are in the same university ! Apr 14 18:57:13 no, haven't talked with DiegoTc science the last gsoc Apr 14 19:01:17 since* Apr 14 19:07:05 nice. would you consult with amragaey if his project was approved? Apr 14 19:07:09 ebadawy: ^^ Apr 14 19:08:05 yeah sure, I'll try to help him as much as I can Apr 14 19:09:46 but have to say that I won't be available for a full time. Apr 14 19:10:35 thanks ebadawy I appreciate your help. Apr 14 19:11:54 I found a usb cable that works with ur BBB, and it works now :D Apr 14 19:13:45 cool, now you have all what you need, looking forward to see ur hacks with it :) **** ENDING LOGGING AT Fri Apr 15 02:59:58 2016