| 00:53.46 | *** join/#qi-hardware wolfspraul (~wolfsprau@brln-4d0cd028.pool.mediaways.net) |
| 01:17.55 | *** join/#qi-hardware sb0 (~sb@124244181048.ctinets.com) |
| 01:34.01 | *** join/#qi-hardware astr (~astr@79-69-194-120.dynamic.dsl.as9105.com) |
| 01:37.31 | *** join/#qi-hardware rz2k (~rz2k@188.244.39.169) |
| 02:14.36 | *** join/#qi-hardware atommann (~atommann@58.251.146.217) |
| 02:39.33 | *** join/#qi-hardware sb0 (~sb0@124244181048.ctinets.com) |
| 02:49.30 | *** join/#qi-hardware astr (~astr@79-69-197-74.dynamic.dsl.as9105.com) |
| 03:52.03 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:11.26 | *** join/#qi-hardware DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:58.44 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 05:01.32 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 05:03.53 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 05:06.42 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 05:20.05 | *** join/#qi-hardware xiangfu (~xiangfu@111.206.2.13) |
| 06:02.53 | *** join/#qi-hardware atommann_ (~atommann@23.27.206.2) |
| 06:19.17 | *** join/#qi-hardware nicksydney (~quassel@122.129.dsl.syd.iprimus.net.au) |
| 06:24.29 | *** join/#qi-hardware atommann (~atommann@23.27.206.2) |
| 06:48.28 | *** join/#qi-hardware xiangfu (~xiangfu@106.120.178.237) |
| 07:33.44 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 07:51.43 | *** join/#qi-hardware dandon_ (~dandon@88.151.75.63) |
| 07:56.37 | *** join/#qi-hardware dandon (~dandon@88.151.74.254) |
| 08:07.14 | *** join/#qi-hardware atommann (~atommann@58.251.146.217) |
| 08:10.15 | *** join/#qi-hardware fmeerkoetter (~fmee@p5DDCDE62.dip0.t-ipconnect.de) |
| 08:11.00 | *** join/#qi-hardware jekhor_ (~jek@nat-minsk-pool-46-53-200-14.telecom.by) |
| 08:12.43 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 08:23.10 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 08:29.50 | *** join/#qi-hardware valhalla (~valhalla@81-174-44-179.v4.ngi.it) |
| 09:03.25 | *** join/#qi-hardware valhalla (~valhalla@212-124-164-221.v4.ngi.it) |
| 09:30.15 | *** join/#qi-hardware pcercuei (~paul@137.71.226.54) |
| 10:15.41 | *** join/#qi-hardware jekhor_ (~jek@port-162-adslby-pool37.infonet.by) |
| 10:24.45 | *** join/#qi-hardware jekhor__ (~jek@port-162-adslby-pool37.infonet.by) |
| 11:05.37 | *** join/#qi-hardware fmeerkoetter (~fmee@193.158.222.106) |
| 12:00.00 | *** join/#qi-hardware wej (~j@2001:1af8:4010:a027:21::4e) |
| 12:55.34 | qi-bot | [commit] Werner Almesberger: slicer/README: correct style and a typo (master) http://qi-hw.com/p/cae-tools/73c0489 |
| 12:55.35 | qi-bot | [commit] Werner Almesberger: slicer/stl.c, stl.h: copy over from Neo900 misc/meme/ (master) http://qi-hw.com/p/cae-tools/632a60f |
| 12:55.36 | qi-bot | [commit] Werner Almesberger: slicer/stl.h, stl.c: adapt for use in slicer (master) http://qi-hw.com/p/cae-tools/5f31b94 |
| 12:55.38 | qi-bot | [commit] Werner Almesberger: slicer/slice.h, slice.c, util.h: extract outlines of Z slices from mesh (master) http://qi-hw.com/p/cae-tools/49abc13 |
| 12:55.40 | qi-bot | [commit] Werner Almesberger: slicer/slice.c (add): only output lower end of vertical walls (still needs work) (master) http://qi-hw.com/p/cae-tools/3f2c6cd |
| 12:55.42 | qi-bot | [commit] Werner Almesberger: slicer/stl.c (stl_load_file): support binary STL as well (on little-endian hosts) (master) http://qi-hw.com/p/cae-tools/c82ea10 |
| 12:55.44 | qi-bot | [commit] Werner Almesberger: slicer/slice.c: repeat lower cuts at intermediate points (master) http://qi-hw.com/p/cae-tools/6a12d47 |
| 12:55.46 | qi-bot | [commit] Werner Almesberger: slicer/stl.c: mention where the format is documented (master) http://qi-hw.com/p/cae-tools/c984021 |
| 12:55.48 | qi-bot | [commit] Werner Almesberger: slicer/slice.c (add): detect and report inclined facets (master) http://qi-hw.com/p/cae-tools/a30024d |
| 12:55.50 | qi-bot | [commit] Werner Almesberger: slicer/stl.c (stl_load_binary): remove debug output (master) http://qi-hw.com/p/cae-tools/65fa69c |
| 12:55.52 | qi-bot | [commit] Werner Almesberger: slicer/slice.c, slice.h: optionally draw a box around the object (master) http://qi-hw.com/p/cae-tools/6b7ceca |
| 12:55.54 | qi-bot | [commit] Werner Almesberger: slicer/Makefile, slicer.c: forgot to commit these files :-( (master) http://qi-hw.com/p/cae-tools/aa327c8 |
| 12:55.56 | qi-bot | [commit] Werner Almesberger: slicer/slice.c (dump_layer): don't draw the top end of walls (master) http://qi-hw.com/p/cae-tools/9fc0962 |
| 12:55.58 | qi-bot | [commit] Werner Almesberger: slicer/: new option -z to add intermediate layers (master) http://qi-hw.com/p/cae-tools/b2d6ef5 |
| 12:56.06 | pcercuei | C-C-C-COMBO BREAKER |
| 12:56.54 | wpwrak | phew :) http://knowyourmeme.com/memes/combo-breaker |
| 12:57.48 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 12:59.19 | *** join/#qi-hardware FAMAS (~FAMAS@182.48.84.141) |
| 13:00.38 | wpwrak | (giving freecad another try. but without having to suffer crappy toolpaths in return :) |
| 15:16.17 | *** join/#qi-hardware xiangfu (~xiangfu@123.125.212.79) |
| 15:16.31 | *** join/#qi-hardware jekhor__ (~jek@port-162-adslby-pool37.infonet.by) |
| 15:37.59 | *** join/#qi-hardware Nik05 (~Nik05@unaffiliated/nik05) |
| 16:08.27 | *** join/#qi-hardware rejon (~rejon@2600:100a:b122:988e:223:15ff:fe2a:9c6c) |
| 16:16.44 | *** join/#qi-hardware idundidit (~idundidit@66-215-119-163.dhcp.atsc.ca.charter.com) |
| 16:31.12 | *** join/#qi-hardware atommann (~atommann@58.251.146.217) |
| 17:42.32 | DocScrutinizer05 | pcercuei: I tend to agree |
| 17:43.05 | DocScrutinizer05 | posting commit messages to IRC is kinda abusive |
| 17:54.51 | wpwrak | naw, i like it. shows where things are happening. but it may help if very long sequences would get truncated. |
| 18:19.26 | DocScrutinizer05 | by definition/netiquette of IRC, a bot shouldn't spam a channel with unsolicited info. It might be tolerable when you do this in a dedicated channel which users would join only when they are interested in that sort of automated update about "where things happen". For a channel with /topic "hardware hackers join here to discuss Ben NanoNote, atben / atusb 802.15.4 wireless, and other community driven hw projects" I'd consider such |
| 18:19.28 | DocScrutinizer05 | automated 'tweets' quite inappropriate |
| 18:20.37 | DocScrutinizer05 | but obviously that's pretty much up to the individual channel's policies, as set up by the channel founders |
| 18:55.42 | *** join/#qi-hardware pcercuei (~pcercuei@95.91.238.32) |
| 19:09.37 | *** join/#qi-hardware wolfspraul (~wolfsprau@brln-4d0cd028.pool.mediaWays.net) |
| 19:37.58 | *** join/#qi-hardware Haswell (~Haswell@unaffiliated/haswell) |
| 19:55.58 | *** join/#qi-hardware wolfspraul (~wolfsprau@brln-4d0cd028.pool.mediaWays.net) |
| 20:22.09 | *** join/#qi-hardware jekhor__ (~jek@nat-minsk-pool-46-53-200-14.telecom.by) |
| 20:39.47 | *** join/#qi-hardware wolfspraul (~wolfsprau@brln-4d0cd028.pool.mediaWays.net) |
| 20:44.05 | *** join/#qi-hardware rejon (~rejon@2600:100a:b122:988e:223:15ff:fe2a:9c6c) |
| 20:47.46 | *** join/#qi-hardware fmeerkoetter (~fmee@p5DDCDE62.dip0.t-ipconnect.de) |
| 20:50.18 | DocScrutinizer05 | wpwrak: wut? Argentinia building the RN40 since EIGHTY years and still not even half done? real fun! |
| 20:55.28 | DocScrutinizer05 | well, Koeln dome took longer to be not finished yet ;-) |
| 21:15.52 | wpwrak | i think you mean paved, not constructed. where are many unpaved roads in argentia. please remember that it's a big country and traffic can be fairly light in some areas :) |
| 21:22.16 | wpwrak | s/where/there/ |
| 21:22.16 | qi-bot | wpwrak meant: "i think you mean paved, not constructed. there are many unpaved roads in argentia. please remember that it's a big country and traffic can be fairly light in some areas :)" |
| 21:28.41 | eintopf | wpwrak: do you have a car in argentia? |
| 21:29.15 | wpwrak | yup, and i think i've driven on RN40 (the paved part :) |
| 21:30.05 | eintopf | image some linux car with a big fat linux sticker at the back |
| 21:30.39 | eintopf | oh wait |
| 21:30.43 | eintopf | I know wpwrak car |
| 21:31.12 | eintopf | http://www.spiegel.de/auto/aktuell/mobiles-buero-auf-dem-beifahrersitz-polizei-stoppt-autofahrer-a-866960.html - (german article) |
| 21:31.30 | eintopf | you don't need to understand german if you see this picture: |
| 21:31.31 | eintopf | http://cdn2.spiegel.de/images/image-424469-galleryV9-nokm.jpg |
| 21:32.09 | eintopf | but the solder station is missing there |
| 21:32.53 | eintopf | maybe baking some boards on the top of the motor while driving the car ;-) |
| 21:35.27 | eintopf | wpwrak: please don't be angry.... it's just funny. Maybe you have something similar in your car and for me that's pretty cool |
| 21:36.34 | wpwrak | that looks kinda dangerous :) |
| 21:38.12 | wpwrak | naw, the only "diy" addition is a gps support |
| 21:41.43 | eintopf | :-( |
| 21:44.46 | *** join/#qi-hardware jow_laptop (~jow@srv.mein.io) |
| 21:45.24 | eintopf | I finished my implementation for controlling a inverted pendulum via matlab PID code generation (some project for my study) |
| 21:45.44 | eintopf | it's simulated in a physic engine only |
| 21:46.09 | eintopf | but I implemented a cool opengl plotter for the PID error |
| 21:46.51 | eintopf | my experience, you don't need the fancy matlab thing... but I can't say this in my course |
| 21:47.49 | eintopf | and matlab simulink code generation - I don't know if I can setup some settings for generating code for 8bit mcu. I mean the code generator need to be sure that there is no overflow, etc... |
| 21:49.53 | eintopf | somebody wants to have some x86_64 binary to see how a PID works? it's magic |
| 21:50.27 | DocScrutinizer05 | thanks, I've built both analog and digital PID controllers |
| 21:50.32 | DocScrutinizer05 | :-) |
| 21:50.35 | eintopf | it's magic because I have only some error value with no dimension and the PID try to get this error at 0... okay that's how a PID works |
| 21:50.45 | eintopf | but the gains, it's purely randomness |
| 21:50.52 | eintopf | DocScrutinizer05: :O analog PID controller? |
| 21:50.57 | DocScrutinizer05 | sure |
| 21:51.00 | eintopf | this is fast |
| 21:51.06 | DocScrutinizer05 | that's how that stuff started |
| 21:51.16 | eintopf | ah, ok. |
| 21:51.22 | DocScrutinizer05 | some prolly 100 years ago |
| 21:51.22 | eintopf | do you also do some fuzzy logic? |
| 21:51.32 | DocScrutinizer05 | hardly ever |
| 21:51.51 | DocScrutinizer05 | I think fuzzy logic is a joke |
| 21:52.19 | DocScrutinizer05 | I can do logic of arbitrary "fuzziness" in proper digital |
| 21:53.24 | DocScrutinizer05 | no need for "gaaaaaanz viel 0 is ein klein bisschen 1" |
| 21:54.04 | eintopf | and for what do you use the PID? |
| 21:54.11 | eintopf | for controlling things... |
| 21:54.22 | eintopf | I mean when do you use PID and when fuzzy |
| 21:55.19 | eintopf | okay the PID error value plot looks more like a sin(x) with some damping |
| 21:55.30 | eintopf | and fuzzy looks different, then fuzzy is maybe better |
| 21:56.20 | DocScrutinizer05 | when it looks too much like sin(x) you should adjust the integral factor |
| 21:57.10 | eintopf | ah, an expert |
| 21:57.34 | eintopf | I have a little input box where I can change the values on the fly |
| 21:58.57 | DocScrutinizer05 | PID regulators are used literally everywhere |
| 22:02.20 | *** join/#qi-hardware dandon (~dandon@88.151.79.199) |
| 22:03.02 | DocScrutinizer05 | there is math to calibrate the PID from known parameters of the controlled system, but they are tedious and it's generally easier to simply adjust the stuff live |
| 22:04.37 | DocScrutinizer05 | particularly since it's quite difficult to acquire a comprehensive set of parameters of the controlled system, incl all actors and sensors |
| 22:05.33 | eintopf | yes, matlab has also some feature to auto-detect the gains |
| 22:05.45 | eintopf | but then I need to have my physical model inside matlab |
| 22:06.07 | eintopf | and my physic engine only understand setMotorSpeed(500) |
| 22:06.15 | eintopf | don't know what 500 means :-) |
| 22:06.36 | DocScrutinizer05 | hehe |
| 22:06.38 | eintopf | this will cost much time |
| 22:06.46 | eintopf | but for the PID this doesn't matter |
| 22:06.57 | eintopf | he only tries to get the error value -> 0 |
| 22:07.02 | DocScrutinizer05 | yep |
| 22:07.31 | DocScrutinizer05 | it's more about inertia and momentum, about delays etc in your system |
| 22:07.38 | DocScrutinizer05 | phase shift |
| 22:08.14 | DocScrutinizer05 | and those are hard to measure, for any physical object |
| 22:09.41 | DocScrutinizer05 | basically you compensate delay with the D component and inertia with the I component |
| 22:10.00 | DocScrutinizer05 | funny even the letters match :-D |
| 22:10.07 | DocScrutinizer05 | just noticed first time |
| 22:12.44 | DocScrutinizer05 | you can also think of differential component as highpass and integral component as lowpass |
| 22:13.18 | eintopf | I used the normal PID controller from wikipedia |
| 22:13.21 | eintopf | pure simple |
| 22:13.57 | eintopf | with the matlab componentes Integral 1/s and derivate |
| 22:14.08 | eintopf | and sum function at end |
| 22:14.28 | eintopf | the P gain is only to set my "setMotorSpeed" to some value which fits |
| 22:14.42 | eintopf | not too fast, not too slow |
| 22:14.53 | eintopf | and I simple experiment with all values |
| 22:15.43 | eintopf | I know the matlab builtin PID controller has some filter |
| 22:16.04 | eintopf | but I didn't understand that, if I set the filter coefficient above 0, nothing worked anymore |
| 22:16.16 | eintopf | a build a own one |
| 22:16.34 | eintopf | http://www.mathworks.com/help/simulink/slref/pid_controller_parallel.png |
| 22:16.53 | eintopf | that's the normal MATLAB PID controller |
| 22:17.29 | eintopf | I simple have a "normal" deivate block after D-Gain |
| 22:17.47 | eintopf | don't know what matlab tries to do there |
| 22:19.06 | DocScrutinizer05 | well, they build a differentiator from an integrator |
| 22:20.16 | DocScrutinizer05 | a highpass for x is what you get from x-lowpass(x) |
| 22:21.52 | DocScrutinizer05 | in simple analog this would be a capacitor feeding back opamp output to negative input |
| 22:22.26 | DocScrutinizer05 | ooops sorry, nope, the contrary |
| 22:22.56 | DocScrutinizer05 | this would be a capacitor shorting high frequencies of the feedback to ground, in negative input |
| 22:25.22 | DocScrutinizer05 | the 1/s feeding back low frequencies to the inverting input, thus attenuating them |
| 22:26.49 | eintopf | ah |
| 22:27.08 | DocScrutinizer05 | and such feedback however can't reduce the amplification to <1 |
| 22:27.49 | eintopf | I know lowpass filter. A rc-circuit. |
| 22:27.56 | DocScrutinizer05 | :nod: |
| 22:28.01 | eintopf | oh |
| 22:29.27 | eintopf | When I started my study I had some frequency generator and making serval RC-circuits. Then I looked at oscilloscope what happens |
| 22:29.42 | eintopf | the first time where I understand for what's good for |
| 22:30.00 | DocScrutinizer05 | ypur amplification in such feedback filter needs to be >1 to produce any significant difference in output signal between filtered and non-filtered frequencies |
| 22:31.32 | DocScrutinizer05 | quite possibly a feed-forward filter would be better suited for that usecase than a feedback filter |
| 22:33.14 | DocScrutinizer05 | a filter without feedback could result in output amplitude approaching zero for frequency approaching zero |
| 22:35.02 | eintopf | I think I don't do any filtering now, but thanks for the info |
| 22:35.19 | DocScrutinizer05 | the stuff http://www.mathworks.com/help/simulink/slref/pid_controller_parallel.png shows would still have output = input (amplification = 1) and for higher frequencies it would reach the amplification of the "N filter coefficient" |
| 22:36.38 | eintopf | I also saw some filtering about position and the acceleration, which is calculated by position''. They had some weights with pos_filter = (pos_avg * 0.1) + (real_pos * 0,9); |
| 22:37.46 | eintopf | ah so I don't have higher frequency, this will reduce some wobble pendulum :-) |
| 22:46.21 | DocScrutinizer05 | maybe it helps to think about you following another car with your car on the highway. You have a very accurate way to detect the distance to the car you're following and your goal is to keep a certain constant distance |
| 22:47.04 | DocScrutinizer05 | consider what you would do to the trottle when you notice your distance is 10% too short. |
| 22:47.48 | DocScrutinizer05 | you also would act differnt based on your observation if that distance is short but constant or the car before you is actually slower than you |
| 22:48.14 | DocScrutinizer05 | that's the D component |
| 22:48.58 | DocScrutinizer05 | to adjust your speed to the other car quickly |
| 22:49.59 | DocScrutinizer05 | when you notice you're 10% short but same speed, you slowly reduce throttle gradually. That's the I component |
| 22:50.12 | eintopf | ahhh |
| 22:52.56 | DocScrutinizer05 | too much I without any D would result in oscillation |
| 22:53.52 | DocScrutinizer05 | but too high D would also result in oscillation |
| 22:54.25 | DocScrutinizer05 | both of them too low would result in your distance never getting right |
| 23:04.53 | DocScrutinizer05 | the P component is basically just to adjust the target distance you want to keep |
| 23:11.05 | DocScrutinizer05 | sorry when there's anything incorrect in all this, it's what I recall from my experience with PID which is quite several years ago already |
| 23:13.37 | DocScrutinizer05 | also note there are serial PID as well. What you shown is a parallel PID |
| 23:22.34 | DocScrutinizer05 | I think you can have hours of fun with https://en.wikipedia.org/wiki/PID_controller and particularly https://de.wikipedia.org/wiki/Regler#PID-Regler ;-) |
| 23:52.28 | DocScrutinizer05 | actually nope, P component is what determines the working point and thus characteristics of the whole regulator. (over-damped vs overshooting) |
