**** BEGIN LOGGING AT Wed Feb 24 02:59:58 2016 Feb 24 16:41:17 hey jkridner, I don't suppose the beaglebone blue will be ready in time for gsoc, will it? Feb 24 16:48:54 I think so, at least prototypes to give to students. Feb 24 16:49:15 I can commit to getting a couple together. Feb 24 16:49:45 porting code to BeagleBone Blue would be a great exercise. Bringing up Ardupilot+ROS on BeagleBone Blue would be great. Feb 24 16:50:09 We'll have the Strawson stuff up and working. Feb 24 16:50:25 I'd be into doing a something like that Feb 24 16:51:35 is there much in the way of docs/examples yet? Feb 24 16:52:27 is the plan to have a separate image for it with things like ROS already installed? Feb 24 17:00:19 the BBB-MINI has nice Ardupilot support. Feb 24 17:00:36 Ardupilot has ROS support, per my understanding. Feb 24 17:00:42 I've not been able to use it for much. Feb 24 17:02:39 it would be awesome to have an ardupilot image for the blue Feb 24 17:04:05 I guess someone would need to maintain that Feb 24 17:08:11 though it seems like it has to be compiled for the specific sensors being used, so it might not be as straight-forward as having a single image if the user brings their own GPS, radio, etc. Feb 24 20:34:04 it's either ros or linux/mavlink Feb 24 20:34:21 * nerdboy would prefer to see mavlink/ardupilot working Feb 24 20:34:51 well, mavlink/mavconn works on ros too, but ros isn't needed Feb 24 20:35:18 exactly Feb 24 20:35:44 there should be list of supported sensors for bbmini cape Feb 24 20:36:05 others could be made to work, depending Feb 24 20:36:21 ros would be good to have on the beaglebone blue to support things simple like line following bots Feb 24 20:36:40 absolutely. Feb 24 20:37:09 note that the Strawson software provides an "API" that uses a C library that does some mmap() stuff with peripherals. Feb 24 20:37:18 i just meant not required for autopilot/vision processing Feb 24 20:37:56 the potential problem I see with ardupilot on the blue is if the user plugs in their own gps (because there's not one on-board) it seems like ardupilot would need to be completely recompiled(?) Feb 24 20:38:21 don't think so Feb 24 20:38:32 pixhawk has no gps, just a port Feb 24 20:38:54 gps is optional but will get used if there's a lock Feb 24 20:39:00 jkridner: it would be great to have the requisite kernel drivers together so there could be a non-mmap api ready to go Feb 24 20:39:05 http://www.strawsondesign.com/#!manual-install Feb 24 20:39:19 wtf is strawson? Feb 24 20:39:21 alexhiam: absolutely. Feb 24 20:39:27 Strawson is James Strawson. Feb 24 20:40:00 he's the guy that designed the robotics cape we are using as the basis for the BeagleBone Blue and wrote the software for the MIP, Rover and Hexcopter Feb 24 20:40:23 He's supported it for several hundred units, mostly for students at UCSD. Feb 24 20:40:33 Not it is time to scale up. Feb 24 20:40:41 s/Not/Now/ Feb 24 20:42:13 and there could be bonescript/pybbio apis as well Feb 24 20:43:00 ros/ardupilot/mavlink all go together Feb 24 20:43:28 at least they are somewhat interconnected and work with each other Feb 24 20:44:26 mavlink being part of autopilot firmware but also part of ros/linux host runtime Feb 24 20:44:56 there's a lot of drone crap out there... Feb 24 20:45:38 so ardupilot could be already installed with a service that the user could use to enable/disable it, then there could be sysfs/C/node/python APIs as well Feb 24 20:46:55 except for smaller boards like coptercontol that use librepilot, mavlink is at the center of everything Feb 24 20:47:52 so how does ros fit in with ardupilot? Feb 24 20:48:22 ardupilot on bb is essentially running on the host instead of a dedicated autopilot/microcoontoller Feb 24 20:48:47 unless the cape has one (don't think so) Feb 24 20:49:17 that limits the host-side processing of stuff like stereo images and what not Feb 24 20:49:29 so there's usually separate host and controller components? Feb 24 20:50:00 typically, but that doesn't stop people from doing it on rpi/bbb etc Feb 24 20:50:33 autopilots you can buy/make are separate physical devices/controllers Feb 24 20:50:33 so what are the roles of the two components? Feb 24 20:51:00 https://github.com/VCTLabs/elc2016-presentations/blob/master/drones/open_source_drones.rst <= some of this is done Feb 24 20:51:06 look at the mavlink slkides Feb 24 20:51:12 *slides even Feb 24 20:54:04 for BeagleBone Blue, we'll want a way to implement the Strawson APIs such that the interface code is in the kernel and the performance (latency) is no worse than it is currently. Feb 24 20:54:28 that against the 4.1-ti-rt kernel from rcn-ee and mainline. Feb 24 20:54:44 performance measured on 4.1-ti-rt. Feb 24 20:54:46 right Feb 24 20:55:07 wait, what's it using mmap for? GPIO to drive the motors? Feb 24 20:55:27 there's a meta-uav layer with the autopilot stuff in it Feb 24 20:55:33 if the time critical stuff moves to the kernel and there is a ROS interface, agreed that Python and JavaScript bindings are pretty much already there. Feb 24 20:55:47 i can add it to the manifest Feb 24 20:56:08 you should check the code, but I believe he's doing I2C IMU reads using mmap() because the I2C-DEV driver latency was too long. Feb 24 20:56:26 builds ti-staging 4.1 and 4.1-rt Feb 24 20:56:28 also, the strawson 'balance' program is the main program that I see in use.... Feb 24 20:56:38 looks like gpio, pwm and adc as well: https://github.com/StrawsonDesign/BeagleBone_MMAP_IO Feb 24 20:57:03 his PWM code to update the motors after reading the IMU... Feb 24 20:57:05 yup.. Feb 24 20:57:11 guess reading the docs is a good approach. :-) Feb 24 20:57:31 hmmm... I don't see the I2C driver there. Feb 24 20:58:03 I really thought he was accessing the IMU using mmap() too as much as he complained about the i2c-dev driver.... not sure if the actual IMU driver was better, but I think he didn't like it either. Feb 24 20:58:18 so it seems like proper kernel drivers for that stuff with the logic in userspace would work fine then Feb 24 20:58:33 https://github.com/StrawsonDesign/Robotics_Cape_Installer installs the software. Feb 24 20:59:14 there are a lot of native kernel drivers for that stuff... Feb 24 20:59:14 I'm not sure if all the logic can stay userspace. His inner loop is said to be 2ms. Feb 24 20:59:33 not using supported hardware? Feb 24 20:59:35 the drivers exist. he says they don't perform well enough. Feb 24 20:59:56 not i2c-dev but device-specific ones Feb 24 21:00:04 that seems like the place to start then Feb 24 21:00:24 consider https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/balance/balance.c as the outer loop. Feb 24 21:00:30 they are scattered all over the damd kernel config tho Feb 24 21:01:10 so ros is just a runtime with no kernel? Feb 24 21:01:22 * nerdboy has ignored that so far Feb 24 21:01:36 isn't it just an interpreter? Feb 24 21:01:40 inner loop: https://github.com/StrawsonDesign/Robotics_Cape_Installer/blob/master/examples/balance/balance.c#L420 Feb 24 21:02:38 #define SAMPLE_RATE_HZ 200 Feb 24 21:02:51 looks like 5ms. Feb 24 21:03:05 I think he's saying his code spends 2ms. Feb 24 21:03:30 that gives 3ms of slack, which is probably significant since he's typically running on a non-RT kernel. Feb 24 21:03:37 seems like a long time, I wonder how much that could be optimized Feb 24 21:03:39 I'm moving him to 4.1 from 3.8. Feb 24 21:03:51 I think he was saying that the IMU read took 1ms. Feb 24 21:03:57 ah Feb 24 21:04:00 which is obnoxious and unreasonable. Feb 24 21:04:06 for sure Feb 24 21:04:56 anyway, I would focus for a GSoC project on reimplementing the API against kernel drivers and fixing the kernel drivers to provide the same or better performance. Feb 24 21:05:37 yeah, that sounds good Feb 24 21:05:40 and then the Ardupilot port is interesting from a ROS standpoint. I'm not sure how that would differ from a straight ROS port. Feb 24 21:06:17 * alexhiam needs to read up more on ardupilot Feb 24 21:06:21 as in Ardupilot already provides a ROS interface, but it might be at a higher level, not individual motor drive, etc. I'm just not sure. Feb 24 21:06:37 oh, that would make sense Feb 24 21:07:33 seems to me that ardupilot is pretty self contained, couldn't there also be a standalone ROS interpreter on there? Feb 24 21:07:42 autopilot controls the esc/motor stuff Feb 24 21:07:55 ros is the next layer up i think Feb 24 21:08:23 you could look at the repo/build stuff Feb 24 21:08:40 bunch of links on the last couple of slides Feb 24 21:09:57 oooh, so the Strawson cape uses the PRU for motor control. So I imagine that would need a kernel driver to interface with it for ardupilot to use Feb 24 21:10:02 before it could be ported Feb 24 21:10:03 did you guys see the bbb build manifest? Feb 24 21:10:39 branch/bsp/core layer options included... Feb 24 21:11:24 where's that? Feb 24 21:13:33 https://github.com/VCTLabs/vct-beagleboard-bsp-platform Feb 24 21:14:33 basically an easy way to clone/build different branches of poky/oe-core with the existing bbb bsps Feb 24 21:15:27 * nerdboy still not sure where, but will adding rcn kernel recipes/custom configs Feb 24 21:15:34 I'm so far out of the yocto loop... Feb 24 21:15:57 the readme on master should hopefully make sense... Feb 24 21:18:02 stupid typos... Feb 24 21:18:19 * nerdboy probably shouldn't update the readme after midnight Feb 24 21:20:47 fatal: Couldn't find remote ref refs/heads/fido Feb 24 21:20:47 error: Cannot fetch meta-small-arm-extra :( Feb 24 21:21:27 there's a fido branch Feb 24 21:22:23 except maybe i didn't push it Feb 24 21:22:37 * nerdboy building mostly jethro or master Feb 24 21:27:36 hmm, maybe i deleted that build tree Feb 24 21:29:28 oops Feb 24 21:31:02 you probably want jethro anyway Feb 24 21:35:31 okay, do the init and sync again Feb 24 21:37:51 jethro is building... Feb 24 21:38:20 this is not the right computer to do this on Feb 24 21:39:07 fido should work too Feb 24 21:56:19 beaglebone blue project idea added: http://elinux.org/BeagleBoard/GSoC/Ideas#BeagleBone_Blue_APIs Feb 24 21:56:29 alexhiam: thanks! Feb 24 21:56:45 hope there is enough idea critical mass to get accepted this year. Feb 24 21:56:55 we seem to be on a nice roll. just hope it keeps going. Feb 24 21:57:31 seems to be less noise from prospective students this year.. Feb 24 22:00:12 jkridner: do you have any insight into how they choose orgs? Is it just critical mass, or do they actually judge the ideas? Feb 24 22:05:36 they discuss internally and then consolidate their feedback. they will engage you on IRC if you are rejected and let you know why. The one year we were rejected, they said it was a combination of wanting to let in some new orgs as well as us looking too much like a hardware project. Feb 24 22:05:49 You can read the feedback on the beagleboard-gsoc logs from back in 2011 or so. Feb 24 22:06:13 that's why we always make a focus of asking for software projects... Google Summer of CODE. Feb 24 22:06:26 though they've grown their view a bit... Feb 24 22:06:56 I've heard of a project that said they actually did hardware for their project and were approved. HDL for some software defined radio thing, I believe. Feb 24 22:07:13 anyway, we have enough software work to do to improve the state of embedded Linux. Feb 24 22:08:30 interesting. Well it's pretty software-y this year **** ENDING LOGGING AT Thu Feb 25 02:59:59 2016