**** BEGIN LOGGING AT Mon Jan 02 03:00:00 2017 Jan 02 03:20:58 hi Jan 02 03:21:10 Anyone know of a free book for absolute beginners ? Jan 02 04:45:02 Anyone know the status of the Beaglebone Blue? Jan 02 09:35:59 ************************************************ Jan 02 09:35:59 **** Your system is too SLOW to play this! **** Jan 02 09:35:59 ************************************************ Jan 02 09:36:14 ^ MPlayer knows whats up Jan 02 09:36:41 But on the contrary, it played the video file just fine. Jan 02 10:14:46 ericxdu: mplayer shows this when its "i would need to drop a frame" counter exceeds a certain limit Jan 02 14:43:26 how do i determine which pwm chip is for what subsystem using the 4.4 kernel **** BEGIN LOGGING AT Mon Jan 02 17:27:43 2017 Jan 02 18:07:26 Hello! My BBB will not boot from the internal eMMC. I have run fsck on both partitions (boot/root) and no errors are returned. I can also mount the partitions and access the files. I cannot see anything wrong. Jan 02 18:07:54 do you have a serial cable? Jan 02 18:08:01 will tell you whats happening during boot Jan 02 18:08:02 unfortunately not Jan 02 18:08:59 it does boot from the microSD so I know there is nothing wrong with the hardware Jan 02 18:09:18 have you tried flashing the emmc with a flasher image Jan 02 18:11:17 well, i don't want to overwrite the eMMC with a new flasher image. ideally I want to fix whatever is wrong without having to start from stratch with a new image Jan 02 18:12:01 is there anything on there you dont want to remove? if that is the case you can probably boot from sd pull it off or image the emmc Jan 02 18:15:22 Ok. so you're saying i should try to extract the contents of the eMMC and reflash? will that get me anywhere or will I just recreate whatever problem it is that I have now? Jan 02 18:26:23 did you change something in the boot? That would make sure you have a sanitary emmc image flashed known to boot properly Jan 02 18:30:31 I did not change anything in the boot partition. the only thing I can think of is the other day I inserted a blank microSD for additional storage. It automounted to /boot/uboot and I changed ownership (chown ubuntu:ubuntu) of the uboot folder. Jan 02 18:30:46 that didn't seem like such a good idea. so i quickly changed it back to root:root Jan 02 18:31:37 ls -la in /boot indeed confirms the root ownership Jan 02 18:35:53 is that boot from the microsd card? Jan 02 18:36:39 if you booted from a microsd card then the emmc boot partition isnt mounted. Jan 02 18:40:35 correct. the emmc boot partition is not mounted when I boot from microsd. however, the emmc is flashed with ubuntu and has been working for years. it only stopped working yesterday. Jan 02 18:41:14 so if no microsd is inserted BBB will select emmc partition to boot. i've tried this, but nothing happens (only power light is on) Jan 02 18:53:08 ok i have located a suitable reflash image. will give it a go Jan 02 19:25:34 hello, i have a question (or rather several) about the role of the cape_manager and dt-overlays on my bbb. i have generated a rootfs+kernel via buildroot. It has the cape_mgr. i am using the web-based "TI pinmux tool" to generate devicetree (overlays/fragments)? I've managed to compile these fragments with dtc into a .dtbo. But I fail to load them. Jan 02 19:25:59 the system i am building is static Jan 02 19:26:06 it doesn't use capes Jan 02 19:26:32 should i even have the cape_manager on my system? Jan 02 19:27:07 and if no, how do i apply the "config" dts i've generated with the ti pin mux tool? Jan 02 19:29:17 i have the feeling that i am trying to force some things together that don't belong... Jan 02 20:18:47 katz, what device do you use? i wasnt aware of this tool Jan 02 21:00:26 Can anyone give me a status update on the Beaglebone Blue? Jan 02 21:01:19 ready but being held up due to something from what i remember jkridner or someone saying Jan 02 21:01:46 Held up? On account of what? Jan 02 21:01:57 Maybe the power-up sequence? Jan 02 21:02:34 i assume licensing or something. i have been waiting for this thing since I found out about it being called the strawson robotics cape, which is almost two years now Jan 02 21:03:40 i just wish they used a different barometer Jan 02 21:03:51 should be great for arducopter Jan 02 21:04:27 I’m interested in it too; it’s not JUST a cape though, it’s a full Beaglebone, isn’t it? Jan 02 21:04:53 http://strawsondesign.com/ Jan 02 21:05:58 this is the page i found after seeing some video on youtube a year or so ago Jan 02 21:09:02 Yes, I remember that. Jan 02 21:09:18 I hope we’re going to see better encoder support... I plan on using lots of custom encoders. Jan 02 21:10:42 What OS and/or use is the beaglebone black ideal for? I have one "left over" and am looking for some way to use it … Jan 02 21:13:25 That’s a bit of a tricky question... Jan 02 21:14:21 The Beaglebone Black is best suited for circumstances where you need both an OS, but also custom low-level processing of input. Jan 02 21:14:52 ....and if you need a shit load of IO ports? ;) Jan 02 21:16:27 It’s sort of like having a Raspberry Pi but also an Arduino Mega on the same board, with the Arduino Mega feeding DIRECTLY into the processor... Jan 02 21:17:06 better than a mega. the prus run at 200mhz a pop i believe Jan 02 21:17:08 Only instead of Raspberry Pi, it’s some other ARM distro running on a single core, and instead of an Arduino Mega, you have two separate specialized IO processors. Jan 02 21:17:17 That too. Jan 02 21:17:44 the pru's can do so much more from pwm generation etc. on pins that arent even mean to be pwm hardware pins Jan 02 21:18:10 take a look at the bbbmini cape for instance. that uses the pru for pwm Jan 02 21:18:19 Tenacious-Techhu: will the BBB be able to create timing cirtical signals? RPI is not good for PWM, for example Jan 02 21:18:51 mattiz, bone has dedicated pwm hardware on more than just one pin Jan 02 21:19:05 nice Jan 02 21:19:24 the amount of pins available for gpio etc is loads more than a pi Jan 02 21:20:15 Yup. Jan 02 21:20:50 mistawright, I haven’t done any PRU programming yet... I would imagine it is slightly less convenient than the Arduino API, isn’t it? Jan 02 21:21:34 considering that you code it in assembly? Jan 02 21:22:12 Heh. Jan 02 21:22:16 i believe you may also be able to use c or c++ not 100 on that Jan 02 21:22:56 I was anticipating the possible availability of libraries... ^_^; Jan 02 21:23:16 i believe there is pru c compiler of sorts Jan 02 21:23:58 Heh; the Beaglebone Black is the “Playstation 3” of dev boards... XD Jan 02 21:25:06 https://github.com/omcaree/bbb-prupwm/blob/master/main.cpp Jan 02 21:25:19 this looks easy enough Jan 02 21:26:34 that may not even work anymore Jan 02 21:26:45 d'oh :p Jan 02 21:26:49 or with a 3.8 kernel only Jan 02 21:26:58 just something to be aware of Jan 02 21:27:20 See the part about “SPE”s: https://www.reddit.com/r/explainlikeimfive/comments/34maij/eli5_what_exactly_makes_the_playstation_3_so_hard/ Jan 02 21:29:58 mattiz, the Beaglebone Black is sort of like the Playstation 3... you have a single central CPU of well-known type, and then, instead of the SPEs, you have the PRUs, which you have to program with a completely separate development environment, because they speak an entirely different language than the main CPU. Jan 02 21:30:44 Now, this sucks for ease-of-development, but if you have a lot of input that needs some specialized processing before the CPU spends time on it, it’s FANTASTIC. Jan 02 21:31:13 So it does your Real-Time stuff as well as you program the PRU to do it. Jan 02 21:32:22 And then it does your CPU chewy “let me know when it’s done” stuff on the CPU. Jan 02 21:56:34 mistawright, you have any use for absolute position encoders? Jan 02 21:57:07 above my head Jan 02 21:57:07 lol Jan 02 21:57:29 currently that is Jan 02 22:06:00 pru assembly is nice though Jan 02 22:07:55 (with pasm I mean, not that piece of shit assembler shipped with the code generation tools for PRU) Jan 02 22:09:22 the C compiler is useless if you want to do real real-time (such as software pwm) Jan 02 22:10:39 mistawright, not at all; you use an absolute position encoder when you can NEVER afford to lose track of position... it’s just another way of encoding things. Jan 02 22:11:34 Tenacious-Techhu, is that taking advantage of the built encoders of the beaglebone black? Jan 02 22:11:47 those are quadrature decoders Jan 02 22:12:17 Quadrature Encoders are strictly relative... Jan 02 22:12:22 thanks for the correction. zmatt is a hell of a lot more knowledgeable on the board than I. I just think its the shit Jan 02 22:12:29 well, they can be absolute... 2-bit :P Jan 02 22:12:48 They can tell you how many steps you have moved from when you started, and in what direction, so long as you will never lose track... Jan 02 22:12:56 absolute encoders probably use Grey counting right? Jan 02 22:13:10 *Gray code Jan 02 22:13:14 But with absolute position encoders, so long as you can take a reading at all, you never lose track. Jan 02 22:13:28 Many do, certainly... Jan 02 22:13:54 Is this all optical based? Jan 02 22:13:55 There are cases where you may not want a Grey Code, but they are few. Jan 02 22:14:23 or would be a like a hal effect sensor? Jan 02 22:14:41 so that makes absolute encoding essentially a generalization of quadrature encoding, quadrature being the 2-bit Gray code Jan 02 22:14:47 Encoder Wheels can be anything that can permanently store a bit one way or another... Jan 02 22:15:10 It can be optical or not optical; it’s just a matter of what makes sense for your application. Jan 02 22:15:24 (the "absolute" part kicking in once you have enough bits to avoid using a code more than once on whatever range you want to encode) Jan 02 22:15:43 I could totally see bits encoded onto a disk-platter-like device, and the wheel read magnetically... Jan 02 22:15:48 But yes, they can be optical too. Jan 02 22:16:35 zmatt, you could certainly interpret it that way, but most people assume that quadrature encoding encodes relative position on a much larger wheel. Jan 02 22:16:52 which would be a fair assumption Jan 02 22:17:09 You know how a modern car stereo volume knob generally doesn’t have absolute position anymore? Jan 02 22:17:24 That’s quadrature encoding, right there. Jan 02 22:17:27 yep Jan 02 22:17:32 ok, good example Jan 02 22:17:55 so how is position not altered when said device is off? Jan 02 22:18:12 The hardware in the car stereo never knows the absolute position of the knob, and, for that application, never needs to. Jan 02 22:18:13 is that how it would behave as well or is just coded to take a new reading and go from there? Jan 02 22:18:37 I can see how that would work then Jan 02 22:18:39 mistawright, position CAN be altered when it’s off; in that application, it never needs to CARE that it’s been altered. Jan 02 22:19:14 turning the volume knob when the radio is off simply doesn't do anything Jan 02 22:19:15 But when you have an application that necessarily MUST care about the absolute position, quadrature encoders, and other relative position encoders COMPLETELY SUCK. Jan 02 22:19:34 You have to do some calibration sequence at startup, IF you can... Jan 02 22:19:44 And if you can’t, you’re just SOL. Jan 02 22:19:47 if the radio volume knob used an absolute encoder then changing the volume while the radio is off would work Jan 02 22:20:03 Exactly, zmatt. Jan 02 22:20:46 So if you have a robot, and you want its arms to ALWAYS know what position they’re at, you need an absolute position encoder. Jan 02 22:20:52 i would assume old radios just used a potentiometer Jan 02 22:21:02 Yup. Jan 02 22:21:05 mistawright: yes, that is a good assumption Jan 02 22:21:16 And that’s certainly a cheap way to do absolute position encoding. Jan 02 22:21:18 which could be considered a form of absolute encoding Jan 02 22:21:23 heh Jan 02 22:22:32 Tenacious-Techhu: btw, I'm not sure where this conversation started, but: taking a reading of an absolute encoder is obviously not very real-time in itself, so you could definitely use the pru C compiler instead of assembly if you'd prefer Jan 02 22:22:34 * Tenacious-Techhu curls his fingers into a gun shape, and “blows the smoke off the barrel” Jan 02 22:22:54 I would suggest trying pasm though, it's quite nice Jan 02 22:23:01 zmatt, it depends on how urgently you need that information. Jan 02 22:23:09 correct Jan 02 22:23:23 If you can afford the time, you generally calibrate... Jan 02 22:23:35 but it's not real-time in the same sense that doing pwm in software is Jan 02 22:23:38 If you can’t, you absolutely NEED absolute positioning encoding. Jan 02 22:23:49 It depends on what you are reacting to. Jan 02 22:24:29 whatever you're reacting to can't really expect a reaction in 10ns Jan 02 22:24:41 doing pwm on a pru can expect that sort of resolution Jan 02 22:24:55 If you have a fully autonomous F1 car that needs to calculate a path around a wall, you don’t have time to waste on polling. Jan 02 22:25:23 on the contrary, it probably does poll Jan 02 22:25:37 You need to know the full status of the car as frequently as possible, in order to gauge things like available traction. Jan 02 22:25:40 since if you're doing continuous processing then polling makes perfect sense Jan 02 22:26:00 read inputs, calculate, update outputs, read inputs, calculate, update outputs Jan 02 22:26:06 Polling reads sensors in order... Jan 02 22:26:23 im interested now I would like to do something like that on an rc car. I have seen machine learning used in this application as well Jan 02 22:26:38 Which means you have to guestimate what all the values are based on old data. Jan 02 22:26:58 In order to have a proper handle on the problem, you really need ALL the sensors SIMULTANEOUSLY. Jan 02 22:27:03 Tenacious-Techhu: as opposed to... ? Jan 02 22:27:13 You really can’t step through them sequentially, like with polling. Jan 02 22:27:17 ehm Jan 02 22:27:58 polling can be near-instantaneous... if it isn't, use a better connection to your sensors Jan 02 22:28:01 :P Jan 02 22:28:16 but all this has nothing to do with real-time or not Jan 02 22:28:24 something can have a lot of time available yet still be real-time Jan 02 22:28:32 Polling to ONE sensor, maybe. Jan 02 22:28:44 If you have a list of sensors, and you poll them, the information stops being simultaneous. Jan 02 22:29:15 You start getting errors as you try to guestimate how to integrate the values of the old readings in order to figure out what the value should be at the same instant. Jan 02 22:29:19 there's no "simultaneous", just "sufficiently simultaneous" Jan 02 22:29:29 That’s my point... Jan 02 22:29:35 no I mean in general Jan 02 22:29:55 For this sort of problem there ISN’T “sufficiently simultaneous”. Jan 02 22:30:03 For many problems, there are, certainly. Jan 02 22:30:14 Just not this kind of problem. Jan 02 22:30:16 nonsense Jan 02 22:31:06 mistawright: use something like what? Jan 02 22:31:32 knowing if wheels are slipping through encoders etc Jan 02 22:31:48 uhh Jan 02 22:31:52 software derived differential of sorts Jan 02 22:32:09 "wheel slipping though encoder" sounds like a mechanical failure to me Jan 02 22:32:11 Absolute position encoders completely mitigate issues resulting from wheels slipping past encoders between readings. Jan 02 22:32:33 you don't need absolute readings from a wheel Jan 02 22:32:39 quadrature is fine for those Jan 02 22:32:42 The wheel would have to do a full revolution between readings in order to become lost. Jan 02 22:32:56 zmatt, it depends on whether you need absolute position all the time or not. Jan 02 22:33:05 i.e. there's still a max velocity, just a higher one Jan 02 22:33:10 If you can’t afford to miss any step ever, then quadrature is not enough. Jan 02 22:33:20 you're being completely wrong now Jan 02 22:34:00 zmatt, putting it that way dismisses that the speed required to miss is a complete order of magnitude higher. Jan 02 22:34:02 especially since the absolute encoder merely moves the max velocity by a factor of (360 degrees / angle per quadrature step) Jan 02 22:34:14 that depends on your encoder wheel Jan 02 22:34:26 it also misses the point that "can't afford to miss any step ever" Jan 02 22:34:31 isn't what you get Jan 02 22:34:39 it's just a quantitative change Jan 02 22:34:55 Technically true, I suppose, but usually mechanical issues make that a practical impossibility. Jan 02 22:35:28 also, it means you have to read the encoder using PRU which will have a much slower max limit than reading by eQEP Jan 02 22:35:45 eQEP can I think handle 100.000.000 steps/s Jan 02 22:35:54 Now you’ve lost me; what’s eQEP? Jan 02 22:36:03 the hardware quadrature decoders in the AM335x Jan 02 22:36:40 I’ll have to have a look at that. Jan 02 22:36:49 That certainly does sound nice, if true. Jan 02 22:37:27 I suppose a 200 MHz processor could pull off 100 MHz Quadrature Encoder reading... Jan 02 22:37:51 Regardless, it would still have to be calibrated in order to get absolute position... Jan 02 22:37:57 Which is not an option in all applications. Jan 02 22:38:24 if you need absolute position Jan 02 22:38:31 The Beaglebone only has 2 of those anyway, though, right? Jan 02 22:38:34 3 Jan 02 22:38:52 what do you mean by "I suppose a 200 MHz processor could pull off 100 MHz Jan 02 22:38:53 Quadrature Encoder reading..." Jan 02 22:39:04 PRU has nothing to do with the eQEPs Jan 02 22:39:21 Yeah, still not enough for a 4-wheeled application, or even for a robot with arms and such. Jan 02 22:39:30 oh crap, got a train to catch, will be back later Jan 02 22:39:34 The PRU has to sample the eQEPs, doesn’t it? Jan 02 22:39:39 Nyquist Frequency, and all that. Jan 02 22:40:05 the eQEPs can track position in a 16-bit or 32-bit counter (don't remember which) Jan 02 22:40:18 now really bbl Jan 02 22:40:30 Right, but if there’s only one counter, then the processor has to grab that at that rate. Jan 02 22:40:34 Or lose position. Jan 02 22:40:46 Later, zmatt. Jan 02 22:42:01 So, mistawright, as I was saying, there are times where your absolute position matters a great deal. Jan 02 22:43:02 When you can afford to lose track of your position from time to time, say, because it’s being updated with another sensor anyway, or you can afford to recalibrate, you can get away with quadrature encoding. Jan 02 22:43:33 But when you can’t, or just don’t want to, absolute position encoding is an important option. Jan 02 22:44:30 The entire position is encoded, so you just have to read it and translate it, and you know where your position is. Jan 02 22:45:33 And, for the most part, you never have to worry about not taking readings fast enough; you will always know where everything is at the moment you ask. Jan 02 22:46:28 Unless, of course, your motion genuinely could have gone around the full circle before stopping... Jan 02 22:47:04 It basically makes your encoding readings MUCH more reliable. Jan 02 22:52:15 One of the things that me and zmatt drifted into was polling sampling vs. interrupt sampling... Jan 02 23:02:26 anyone have a beagle for sale? Jan 02 23:09:32 Tenacious-Techhu: reliability is not a good reason for an absolute encoder. if the velocity is higher than you are able to track, use a different encoder or insert a reduction gear Jan 02 23:10:03 note that almost certainly you'll be able to track much higher velocities with a quadrature encoder than with an absolute encoder Jan 02 23:10:38 if your motion can go "full circle" at all, then apparently you don't actually care about absolute position hence don't need an absolute encoder Jan 02 23:12:33 getting an absolute position reading is the only benefit of an absolute encoder, and it needs to be weighed against the fact it needs many signal lines, and you lose a lot of interfacing flexibility since absolute encoders are much rarer and you can't connect an n-wire encoder to something that requires a k-wire encoder (for n != k) in any simple or convenient way Jan 02 23:12:47 (in particular, you can' Jan 02 23:13:03 (in particular, you can't just omit one or more wires to reduce excess resolution) Jan 02 23:14:26 also, earlier you said "The PRU has to sample the eQEPs, doesn’t it?", that depends on your application of course. PRU most definitely can't poll eQEP at 200 MHz if that's what you're thinking, nor is there any reason to ever do so obviously Jan 02 23:15:29 in fact I really hope you don't need to poll your sensor (of any kind) at 200 MHz since you'll have real problems dealing with such a huge stream of data Jan 02 23:16:26 zmatt, I never said you could do such things. Jan 02 23:16:40 I’m approaching this from the “design from scratch” perspective. Jan 02 23:16:51 You certainly can’t just replace one with the other. Jan 02 23:17:35 Absolute position is absolute position; it doesn’t matter whether it’s circular or not. Jan 02 23:18:37 that depends on whether going 360 degrees matters for your mechanical system or not Jan 02 23:19:03 That’s a mechanical design question, and outside the scope of the benefits of one encoder or another. Jan 02 23:19:10 lol, no Jan 02 23:19:16 hi all Jan 02 23:19:27 i'd need a hand with yocto and a bbb Jan 02 23:19:28 So long as you can get a reading from an absolute position encoder, it doesn’t matter how many intermediate positions have been missed. Jan 02 23:19:41 compiled ok, prepared sd ok Jan 02 23:19:47 A quadrature encoder is useless after you miss ANY intermediate position. Jan 02 23:20:02 Tenacious-Techhu: which stops being true if it can rotate 360 degrees and this matters for your physical system Jan 02 23:20:10 Yes, true. Jan 02 23:20:14 when i try to boot "INIT: cannot execute "/bin/sh" Jan 02 23:20:15 INIT: Entering runlevel: 5 Jan 02 23:20:15 INIT: cannot execute "/bin/sh"" Jan 02 23:20:21 But the quadrature encoder stops being useful at the very first miss. Jan 02 23:20:27 Talorno: sounds like a broken system to me Jan 02 23:20:37 Whereas the absolute position encoder is good up until the entire circle has been missed. Jan 02 23:20:37 Talorno: but, yocto is very rarely used by people here Jan 02 23:20:59 seems like the only way to have a decent qt 5.7 or upper system Jan 02 23:21:14 crosscompiling is a shit Jan 02 23:21:20 i mean...doing it by hand Jan 02 23:21:24 Tenacious-Techhu: which is merely a quantitative difference, not the qualitative difference between getting a true absolute reading or not Jan 02 23:21:48 quantitative differences can be made in more ways Jan 02 23:21:53 like I said, a reduction gear Jan 02 23:22:34 so please don't confuse the benefit of absolute tracking (when it applies) with reliability (which depends on many factors) Jan 02 23:22:40 afk again Jan 02 23:24:20 zmatt, an absolute position encoder is reliable in more circumstances than a quadrature encoder. Jan 02 23:24:42 And a reduction gear is not a benefit of an encoder; it’s a benefit of the mechanical design. Jan 02 23:25:12 That reduction gear could apply just as well to the absolute positioning encoder as not. Jan 02 23:28:10 Besides, if you use a reduction gear, then you start having to account for slop in the gear train, which reduces the quality of your encoding samples. Jan 03 00:12:11 reduction gear does not apply to absolute positioning, it can just make it wrong Jan 03 00:13:05 and I didn't say reduction gear were perfect, nor did I deny that adding bits reduces the necessary sample rate for the same information transfer, but this is a property separate from absoluteness Jan 03 00:14:29 also I need to correct an earlier statement I made: you can in fact reduce resolution of an absolute encoder just by dropping bits (I performed the thought-experiment on the wrong end: dropping most-significant bits from a gray code does not result in a gray code) Jan 03 00:15:25 and now I'm going to make tea, kill and restart X11, and get some useful work done Jan 03 01:00:33 zmatt, absolute position encoders can work with reduction gear just fine; you’re just measuring the absolute position of the reduction gear. Jan 03 01:04:05 If you want to reduce the resolution of a standard grey code output, you have to eliminate bits in order of greatest reflection. Jan 03 01:06:56 Or least reflection, if you’re trying for absolute position of the whole wheel, rather than absolute position within a segment of the wheel. Jan 03 01:07:53 Regardless, what I said about the reliability of absolute position encoders is still true; they are more fault-tolerant, and hence, more reliable, than quadrature encoders. **** ENDING LOGGING AT Tue Jan 03 03:00:01 2017