**** BEGIN LOGGING AT Tue Aug 16 02:59:58 2016 Aug 16 10:25:08 hi.... Is there a way to package my debian from BBB. It has libraries required. I want to use whole stuff (with package and libarries) and move to new BBB,. I want to avoid all the steps performed during installation of libraries. Is it possible Aug 16 10:25:22 i read about buildroot Aug 16 10:25:28 will it be helpful Aug 16 10:25:29 ?? Aug 16 10:30:22 Lord_: yes, there is a way Aug 16 10:31:26 is it through build root?? Aug 16 10:35:28 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Aug 16 10:35:31 no Aug 16 10:35:51 if you are running a recent image, then this script should be in it Aug 16 10:36:03 and you should be able to just call it as init Aug 16 10:37:28 you should use the version that's in your image unless you have very very good reasons and are capable to troubleshoot the differences Aug 16 10:47:42 tbr any link or hint Aug 16 10:48:00 sorry i missed. My machine turned off unexpectedly Aug 16 10:48:01 10:35:28< tbr> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Aug 16 10:48:04 10:35:29< tbr> no Aug 16 10:48:07 10:35:51< tbr> if you are running a recent image, then this script should be in it Aug 16 10:48:10 10:36:02< tbr> and you should be able to just call it as init Aug 16 10:48:12 10:37:28< tbr> you should use the version that's in your image unless you have very very good reasons and are capable to troubleshoot the differences Aug 16 10:49:01 ok thanks Aug 16 16:01:29 hello i have just i think destroyed my beagle bone accidentally and need to find help Aug 16 16:02:25 im using windows 10 and i could not gte the drivers downloaded at the first stage of the process Aug 16 16:04:47 what makes you think you destroyed it? Aug 16 16:06:50 the thing is im new to it i had it running fine on a laptop with Ubuntu connected to internet over usb Aug 16 16:07:17 do any leds light up and blink? Aug 16 16:07:29 now ive tried setting it up on windows machine i think i accidentally deleted the drivers from the F DRIVE and they wont download Aug 16 16:07:57 all the leds except usr2 ligth and blink Aug 16 16:09:33 then you didn't damage the hardware. good news Aug 16 16:09:35 not accidentally i deleted them because i felt that i had to redo the whole thing so when i click on start then try to download drivers for windows it cannot locate the file because i deleted it. Aug 16 16:09:52 ooops! Aug 16 16:10:44 http://beagleboard.org/getting-started#step2 Aug 16 16:10:57 drivers should be there Aug 16 16:11:58 they are there but when i plug in the board and try to download somehos i think my pc thinks it has to look on the board to find them Aug 16 16:12:39 nope Aug 16 16:14:34 i dont know but somehow it is now browsing to the board i tried it several times again and this time it worked Aug 16 18:13:22 jkridner, is the Beaglebone Blue going to have any simultaneously sampling ADCs? Aug 16 18:13:50 no, it has a muxed SAR. Aug 16 18:14:06 800kHz. Aug 16 18:14:09 12-bit Aug 16 18:15:23 schematics available yet? Aug 16 18:15:43 yup, http://github.com/jadonk/beaglebone-blue Aug 16 18:15:48 currently building protos. Aug 16 18:16:09 schematics: https://github.com/jadonk/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf Aug 16 18:16:17 layout: https://github.com/jadonk/beaglebone-blue/blob/master/BeagleBone_Blue_brd.pdf Aug 16 18:17:09 the big thing is to see when we get through FCC. Aug 16 18:17:26 that's why it'll probably be January before it is actually on the market Aug 16 18:17:36 ewwww that schematic export is horrible.... it makes all text out of line segments (so you can't even copy/paste a part number) Aug 16 18:17:55 patches welcome. Aug 16 18:18:31 well when my coworkers inflicted PDFs like these on me I usually just hurt them until they send proper ones :P Aug 16 18:19:34 your co-workers might actually WANT you to look at the docs. ;-) Aug 16 18:19:54 looks readable to me. Aug 16 18:19:59 just printed with default settings. Aug 16 18:21:21 actually I think they just switched to better software (Altium) for other reasons, I don't think they ever managed to squeeze proper PDFs out of EAGLE Aug 16 18:24:42 yes I'm not even going to try to take a closer look at this, sorry. besides being barely legible it's also a "puzzle-game-adventure" schematic where almost everything is a named net and you're left to manually search where they go to (since search doesn't work in the PDF either of course) Aug 16 18:29:14 EAGLE was not cool. Would use KiCAD if we started over. Aug 16 18:29:54 jkridner, if Beaglebone Blue ever gets a 2.0, please consider simultaneously sampling ADCs; if you are sampling the position, velocity, and acceleration, and you sample those sequentially, then you have to guestimate (badly) a bunch of calculus to cross-check the values. Whereas, if you sample each one simultaneously, you avoid that messy guessing. Aug 16 18:30:30 Imagine doing that per servo... Aug 16 18:30:38 Tenacious-Techhu: understood. The IMU has a compensation engine within itself. Aug 16 18:30:50 we read it over I2C. Aug 16 18:31:50 That’s certainly good for the IMU, but if you want your robot’s arms to compensate for their load, you need to do that sort of thing. Aug 16 18:33:29 wouldn't you normally get a quadrature-encoded feedback signal and stick that into an eQEP ? (which can do position and velocity tracking, take derivative if you need to know acceleration) Aug 16 18:33:59 It depends on what you mean by “normally”. Aug 16 18:34:05 I guess Aug 16 18:34:08 If you’re talking COTS, then yes. Aug 16 18:34:18 But COTS servo technology sucks. Aug 16 18:34:29 The basic servo hasn’t significantly changed in AGES. Aug 16 18:35:37 Ideally, we’d have closed-loop control featuring samples of position, velocity, and acceleration, in addition to error messages about mechanical stall limits and such. Aug 16 18:35:55 acceleration??? Aug 16 18:36:00 So supporting more advanced encoder stuff is important. Aug 16 18:36:06 Yup; acceleration. Aug 16 18:36:20 what sensor do you have where you can actually make sense of acceleration? Aug 16 18:36:37 Gimme a sec, bathroom... >_<; Aug 16 18:39:23 Tenacious-Techhu: so you're talking about an intelligent controller which derives those values, then uses a DAC to convert them into analog signals forcing you to use an ADC again to convert them back to digital? am I allowed to think that's nuts? Aug 16 18:44:35 schematics where you cannot search for a net are horrible Aug 16 18:47:40 thinkfat: especially since it uses named nets heavily and gratuitously... e.g. just to connect to a header placed on a different page Aug 16 18:48:30 which is a practice I'd frown upon even if search worked and named nets were labeled with the page numbers of other occurrences of the net Aug 16 18:49:20 zmatt, you misunderstand. Aug 16 18:49:27 Tenacious-Techhu: I hoped so Aug 16 18:49:38 The "intelligent controllers" don’t exist. So we need simultaneously sampling ADCs until they do. Aug 16 18:50:33 but what kind of sensor are you using that produces those feedback signals in analog form? that's the part not making sense to me Aug 16 18:50:55 One way to get acceleration is with back-EMF; but you need to cross-check that against the velocity and the position reading. Aug 16 18:51:09 If you aren’t taking those simultaneously, that becomes... unreasonably challenging. Aug 16 18:51:51 Sorry, no, current. Aug 16 18:52:02 I was about to say, doesn't back-EMF measure velocity? Aug 16 18:52:03 The current through a motor is proportional to the torque being put on it. Aug 16 18:52:13 It’s hot... ^_^; Aug 16 18:52:13 torque != acceleration though Aug 16 18:52:33 It’s the only kind of acceleration a servo knows. Aug 16 18:53:18 well that and taking the derivative of velocity :P Aug 16 18:53:44 Through this sort of cross-checking, you can do things like figure out the load because the torque is high but the velocity isn’t changing much. Aug 16 18:54:01 So you need both. Aug 16 18:54:20 Rather, you need everything. Aug 16 18:54:23 assuming torque is proportional acceleration seems a bit optimistic (e.g. stick-slip friction issues) Aug 16 18:54:49 That’s why you cross-check it with velocity and position. Aug 16 18:55:07 If you’re cross-checking, you can usually tell what failure mode you’re in. Aug 16 18:56:15 iirc some C2000 microcontrollers do some clever stuff with motor control based on readback of such values Aug 16 18:56:29 If your wheels are slipping, you can tell because the IMU reports no movement, even though the position, velocity, and acceleration of your wheels are normal. Aug 16 18:57:04 unusually low torque would be a sign too Aug 16 18:57:16 Yes, yes it would. Aug 16 18:57:31 But, let’s take the stall current, as an example. Aug 16 18:57:41 Your robot tries to push a box that’s too heavy for it. Aug 16 18:57:55 but anyhow, I got my answer: current and back-EMF reading are indeed natively in the analog domain Aug 16 18:58:05 Without a current sensor on that motor, it doesn’t know the stall limit is reached. Aug 16 18:58:12 Yeah, pretty much. Aug 16 18:58:21 position would probably still be quadrature Aug 16 18:58:33 Absolute position encoders would be better. Aug 16 18:58:39 Provisions should be made for them. Aug 16 18:58:48 doesn't that require a painful amount of signals? Aug 16 18:58:57 Yeup. Aug 16 18:59:01 But it also means no calibration. Aug 16 18:59:02 eQEP does support an index signal to ensure lack of long-term drift Aug 16 18:59:18 That would be the calibration I just spoke of. Aug 16 19:00:22 really at this point however I wonder if you're not better off with a dedicated microcontroller to deal with the low-level chores and just present the pre-chewed values to the host controller via e.g. spi Aug 16 19:00:47 especially since some already have advanced motor-control stuff built in Aug 16 19:00:54 Relative positioning is only fine so long as the robot never encounters a phenomenon that causes the encoders to spin faster than can be read. Aug 16 19:01:12 zmatt, definitely true, but until they start making Arduinos with simultaneously sampling ADCs... Aug 16 19:01:41 arduino's -.- Aug 16 19:01:57 Yeah, I know, I know, but they’re cheap and well documented. Aug 16 19:01:59 zmatt: usually the arm C is just the cpu that pushes to an intel i7 Aug 16 19:02:18 Tenacious-Techhu: http://www.ti.com/lsds/ti/microcontrollers_16-bit_32-bit/c2000_performance/real-time_control/applications.page#motor Aug 16 19:03:47 I haven't looked at them in much detail, but I did notice that for example the modules in am335x PWMSS originally came from the c2000 series, but the versions in the am335x are the oldest least-featureful versions thereof Aug 16 19:03:49 Those do seem nice, but can you afford to have one in every servo on a robot? Aug 16 19:04:08 I have no idea Aug 16 19:04:17 Exactly. Aug 16 19:04:23 Arduinos are good because they are COTS. Aug 16 19:04:30 robots are expensive anyway Aug 16 19:04:53 Tell that to AFRON, that regularly holds a contest for $10 robots for STEM education for African kids. Aug 16 19:05:28 Their target was an all-in $10 per student price. Aug 16 19:05:50 sounds like a 100$ laptop per child clone for robotic Aug 16 19:05:57 Yup. Aug 16 19:06:00 Pretty much. Aug 16 19:06:16 the question is what this robot should do Aug 16 19:06:24 It wasn’t tremendously successful, but it had some interesting results. Aug 16 19:06:30 Go read the rules. Aug 16 19:06:43 It was pretty ambitious for the price, but not unreasonably so. Aug 16 19:06:56 Tenacious-Techhu: looks like they're not very cheap indeed, although you do seem to get a lot of features (open up the "InstaSPIN motor solutions" header on the link I just gave and read the features) Aug 16 19:07:32 and possibly one controller can handle multiple servos, I don't know Aug 16 19:08:29 That would require a simultaneously sampling ADC with multiple channels, and each channel would be sampled at a different time. Aug 16 19:08:38 Fine for some things, not fine for other things. Aug 16 19:08:41 Tenacious-Techhu: are you involved in that project? if so, you have a dead link in the footer Aug 16 19:08:53 No, it’s not mine. Aug 16 19:09:08 Just something I know about as the Boston R&AS Chair. Aug 16 19:09:21 Tenacious-Techhu: well actually you don't have to care what it requires since it already has the motor control loop in firmware handed to you on a silver plate Aug 16 19:10:32 My point about the multiple channels is that each channel is sampled at a different time, even though it samples the multiple signals on that channel simultaneously. Aug 16 19:11:04 If you have a 4-wheel drive robot, and you’re trying to do elaborate traction control, you need PVA sampled per wheel... Aug 16 19:11:17 So that’s 12 simultaneous signals. Aug 16 19:12:04 You would probably be able to get away with 3 signals per channel, and assigning each wheel its own channel, but for other applications, you can see how the problem multiplies. Aug 16 19:12:11 I wonder if platforms like husky really do that Aug 16 19:12:25 my point was that the firmware handles the state estimation and control loop, so you don't need to worry about it. all you need to check is which features are supported and how many motors :P Aug 16 19:12:38 Yup. Aug 16 19:12:41 simultaneous sampling is not strictly required Aug 16 19:12:51 It depends on the application, certainly. Aug 16 19:13:05 not doing it may increase the headache of the control loop, but if you don't have to write it yourself then ~care~ Aug 16 19:13:06 It’s not required in all cases, and there are circumstances where you can do without it. Aug 16 19:13:13 But there are cases where you definitely do need it. Aug 16 19:13:36 I have trouble believing that Aug 16 19:14:20 In the PVA circumstance, where you sample position, velocity, and acceleration on multiple channels, and not simultaneously, the calculus to cross-check becomes ridiculous. Aug 16 19:14:27 Because you have to guess at everything. Aug 16 19:15:22 The phase displacement becomes a nightmare when the robot’s movement gets interrupted by physical phenomenon. Aug 16 19:15:53 Whereas, with simultaneously sampling, all 3 signals change simultaneously, so it’s much clearer what’s going on. Aug 16 19:16:13 clearer != absolutely required Aug 16 19:16:22 It depends on the application. Aug 16 19:16:25 As many things do. Aug 16 19:16:37 you have to make do with a finite sample rate anyway Aug 16 19:16:40 and limited precision Aug 16 19:16:41 and noise Aug 16 19:16:48 Yes, yes you do. Aug 16 19:16:57 But at least your integrations aren’t hypothetical. Aug 16 19:17:03 thats why you usually another position source like slam.. Aug 16 19:17:36 Tenacious-Techhu: well, they are, since you unavoidably have to interpolate and extrapolate Aug 16 19:18:03 (and filter due to aforementioned limited precision and noise) Aug 16 19:18:28 in neither case are they "guesses" nor hard facts about reality Aug 16 19:18:33 zmatt, my point is, with the phase displacement introduced by sampling each signal at a separate instant, you have to do additional calculus to correct for the separate sampling instants. Aug 16 19:18:48 it's data that lets you update your model of reality Aug 16 19:18:56 Whereas, with simultaneously sampling ADC, you don’t need to do that. Aug 16 19:19:10 again I'm not disputing it may make the calculations easier Aug 16 19:19:21 Not just easier... Aug 16 19:19:46 Because you have to guess whether the robot is still accelerating, has stopped outright, is slipping... Aug 16 19:19:52 And all those things affect your calculus. Aug 16 19:19:56 They’re all guesses. Aug 16 19:20:16 If you sample simultaneously, you don’t guess anymore. Aug 16 19:20:29 And your estimations are never wrong because of your guesses. Aug 16 19:24:44 Ideally, we’d have something like a Sparkfun Redstick with a simultaneously sampling ADC on it that we can slide into a custom 3D-printed servo cover, so we can sample all the signals... Aug 16 19:25:07 But, until we have that, it probably has to be done on a Beaglebone. Aug 16 20:57:30 did I hear eagle issues? **** ENDING LOGGING AT Wed Aug 17 02:59:58 2016