Back
[02:08:15] <[VEGETA]> in robot navigation, does it use point clouds or laser scan data to build navigation map?
[02:09:16] <[VEGETA]> let say I want 3d navigation, is it done by using point clouds to build the 3d map
[02:09:23] <[VEGETA]> or mere 2d costmap?
[02:22:28] <rue_house> SLAM?
[02:31:15] <pokmo> hi
[02:31:31] <pokmo> i have a 1cm universal joint. does anyone know of a good way for braking it?
[02:57:29] <Triffid_Hunter> [VEGETA]: whatever you want to write
[02:58:01] <[VEGETA]> triffid_hunter, what?
[02:59:44] <Triffid_Hunter> [VEGETA]: either can work well depending on what you're doing with the map
[03:01:03] <[VEGETA]> triffid_hunter: I want to create a system that uses kinect to generate a 3D map. then detect dynamic obstacles in 3d (maybe by 3d point clouds segmentation), mark them and put them in the 3d map
[03:01:23] <[VEGETA]> robot will know them and the system will send it their estimated future path
[03:01:32] <[VEGETA]> so can the robot re-plan its path
[03:01:58] <[VEGETA]> I don't want 2d navigation only... 3d is essential.
[03:02:15] <[VEGETA]> triffid_hunter: i hope that made the idea clear
[03:02:32] <Triffid_Hunter> [VEGETA]: sounds like you answered your own question.. if you need 3d, a 2d map isn't gonna work
[03:02:53] <[VEGETA]> triffid_hunter: great, how to achieve the 3d
[03:03:05] <[VEGETA]> is my plan sounds reasonable
[03:03:41] <Triffid_Hunter> [VEGETA]: your plan resembles a field of current academic research, it's not an easy thing to do yet
[03:04:09] <[VEGETA]> how is that?
[03:04:23] <Triffid_Hunter> [VEGETA]:
http://youtu.be/quGhaggn3cQ may interest you
[03:04:23] <[VEGETA]> i saw some examples using ros
[03:04:48] <Triffid_Hunter> ah, ros.. I've been trying to get into that but it's so damn hard to install :/
[03:06:19] <[VEGETA]> yes it is so damn hard, but worth it
[03:06:32] <[VEGETA]> your video talks about something else other than mine
[03:06:36] <[VEGETA]> totally different
[03:08:23] <[VEGETA]> triffid_hunter: look at this:
https://www.youtube.com/watch?v=bCIQ58K0vcg
[03:08:33] <[VEGETA]> it is already done most of my job ~
[03:08:48] <[VEGETA]> the only thing left is dynamic obstacles detection and re-planning
[03:11:53] <Triffid_Hunter> [VEGETA]: looks like SLAM
[03:12:00] <[VEGETA]> yes yes
[03:12:03] <Triffid_Hunter> but using voxel grid
[03:12:27] <[VEGETA]> the difference that I want is the ability to detect dynamic obstacles and estimate their future path
[03:12:37] <[VEGETA]> so the robot can adjust its path
[03:12:43] <[VEGETA]> or wait or do w/e
[03:13:18] <[VEGETA]> i don't know the difference between voxel grid and normal cloud points made by Octomap
[03:14:17] <Triffid_Hunter> [VEGETA]: voxel grid divides space into cubes and stores occupancy for each cube. point cloud stores positions of individual points
[03:15:16] <Triffid_Hunter> [VEGETA]: minecraft uses voxels for example, whereas most other 3d games use point clouds with facets between them
[03:20:49] <[VEGETA]> ok but what is the benefit of using voxels? better for computation?
[03:22:42] <Triffid_Hunter> [VEGETA]: yeah things are a lot simpler to compute, but you also get a coarse map which may or may not be problematic depending on application
[03:23:18] <veverak> voxels it's called! :)
[03:23:57] <[VEGETA]> veverak: you slept and woke up to be the "nazi grammar troll"? :)
[03:24:16] <veverak> nope nope
[03:24:24] <veverak> just happy that I know how that concept is called
[03:24:36] <[VEGETA]> triffid_hunter: well, for a good laptop i think point clouds are no problem. but for say pi 3 maybe
[03:24:56] <veverak> [VEGETA]: it really depends on what you want to do
[03:25:11] <veverak> I think that for "3d image of surrounding space" voxels are good enough anyway
[03:25:47] <veverak> I mean, you are not NASA to make robots go 2mm near obstacles...
[03:26:09] <[VEGETA]> veverak: Yes, I like what is good enough. i don't think my robot will care about those 2 cm^3 of free space that will be covered by a voxel
[03:26:35] <veverak> [VEGETA]: exactly
[03:26:38] <veverak> :)
[03:27:38] <[VEGETA]> veverak, this is for fun:
https://www.youtube.com/watch?v=TQM8bUHOEuE < you are the nazi grammar troll hehehehe
[03:30:05] <veverak> wut? :)
[03:30:17] <veverak> it was not grammar nazi related
[03:31:26] <Triffid_Hunter> grammar nazi? where?
[03:32:00] <[VEGETA]> hhhh
[03:32:20] <[VEGETA]> it is official: veverak is the grammar nazi
[03:33:00] <veverak> nah, nevermind
[03:33:06] <veverak> back to by morning procedure
[03:33:09] <veverak> ;)
[03:33:40] <Triffid_Hunter> [VEGETA]: how so? haven't seen him correcting any grammar..
[03:35:08] <[VEGETA]> triffid_hunter: it is a joke... he said you should write voxels instead of voxel
[03:35:51] <Triffid_Hunter> [VEGETA]: no he didn't, he was expressing elation that he was familiar with them..
[03:36:23] <z64555> oh. Voxels are not just points. they also have some other data associated with them
[03:36:44] <z64555> with point clouds it is just that, an array of positions
[03:37:05] <z64555> A simple example is a 3D object
[03:37:32] <z64555> With a point cloud, you just have the shape of the object, but no polygons etc. drawing the face
[03:37:41] <z64555> 'cause it's all just points
[03:38:11] <z64555> With a voxel amp, you have the shape of the object, and still no polys, BUT, you can have color assigned to the points
[03:38:43] <z64555> so you could draw a little "billboard" square at each point, and have it assume the color of that voxel
[03:39:00] <z64555> and therefor can draw samething
[03:39:35] <Triffid_Hunter> the asteroids in space engineers are voxel based, they use some fancy chunk of math to wrap vertexes around them in a moderately organic way that doesn't leave them looking too blocky
[03:40:28] <veverak> z64555: I had idea for voxel space once
[03:41:09] <veverak> take pictures of space with camera, position camera in voxel space and colorize all voxels with pixel color in line of sight of the picture
[03:41:17] <z64555> ah, I've heard of those. Those are voxels but some people call them atoms. Since voxels have historically used billboards (2D square polygons that always face the camera) and atoms use a random blob mesh
[03:41:18] <veverak> that,s practically infignite range but you can somehow limit that I suppose
[03:41:24] <veverak> than do the same from different angle
[03:41:42] <veverak> and when you colorize something which got color, you mix the two colors and write how much they are different
[03:42:02] <veverak> give some time and progress, you should have voxels with high color difference -> propably air
[03:42:03] <z64555> veverak: Novalogic is known for taking map data from fly-by survellance of real-world locations
[03:42:22] <z64555> which basically coupled a color map with a height map, and the voxel terrain was built from those two
[03:42:43] <veverak> and voxels with small color difference -> propably soemthing non-air
[03:42:45] <veverak> :)
[03:42:59] <z64555> problem: tie-die shirts.
[03:43:46] <z64555> also, cheap CCD cameras have terrible color consitancy across the senesory array
[03:44:13] <veverak> yeah, and "gloss" is your enemy
[03:44:39] <Triffid_Hunter> also glass.. sonar is great for picking up glass, visual solutions not so much ;)
[03:44:50] <veverak> z64555: anyway, I suppose that you can upgrade voxels with many other solutions
[03:45:00] <veverak> "color variety" can be only one of the thins
[03:45:07] <z64555> voxels are terrible, terrible at being accelerated
[03:45:08] <[VEGETA]> I guess octomap supports both point clouds and voxels
[03:45:15] <veverak> combine it with kinect and sonar and it can work?
[03:45:29] <z64555> ...whatever that means. It's something I asked the game devs about and they didn't reply back. :/
[03:45:58] <veverak> z64555: graphic acceleration?
[03:46:18] <z64555> possibly
[03:46:59] <[VEGETA]> z64555: do these game devs have a channel here?
[03:47:22] <z64555> no, they're difficult to reach, even via email
[03:48:21] <veverak> zzz64: anyway, basic idea was to create voxel space and for each unit calculate chance if it's space robot can go trough or not
[03:48:32] <veverak> based on camera+colors magic, sonar, kinect...
[03:48:52] <veverak> I suppose robot will than prefer "path" with lowest chance of voxels being solids
[03:50:38] <[VEGETA]> i like unity 3d for game development... but it is not my major xD
[05:44:08] <[VEGETA]> veverak, a path is 2d path or 3d one? i guess ground vehicles only wants 2d
[05:50:31] <LiohAu> sorry i'm not a good english speaker, what do you understand by this : "Kangaroo will use 3.3V logic as well, but of course, 1.8V is too." ?
[05:50:53] <LiohAu> does this means that the 1.8v is also ok ?
[05:51:07] <LiohAu> or does this mean that 1.8v is not ok, and only 3.3v is ok ?
[05:54:58] <Jak_o_Shadows> A Kangaroo?
[05:55:32] <LiohAu> (it's a motor controller)
[05:55:43] <Jak_o_Shadows> ah. Less interesting than a kangaroo robot
[05:55:59] <LiohAu> look at Festo for this
[05:56:09] <Jak_o_Shadows> eh, they made a hopping rat. Not a kangaroo
[05:56:56] <LiohAu> well for me it's a kangaroo :P
[05:57:27] <LiohAu> didn't interpret this as a rorschach test :D
[05:57:49] <Jak_o_Shadows> haha.
[05:57:59] <Jak_o_Shadows> I just think you need more spring elements to make a kangaroo hop
[06:00:07] <LiohAu> and about my comprehension issue ? :P
[06:00:32] <Jak_o_Shadows> haha. You're not australian I think? We'd have stronger opinions
[06:11:40] <veverak> [VEGETA]: depends, I would use 3D
[06:12:04] <veverak> that is doable for robot
[06:13:01] <veverak> so it's Z is close to ground and when robot tries to reach pos, won't make a big deal about not reaching the z pos
[07:00:52] <[VEGETA]> veverak, yes your idea is correct
[07:01:37] <[VEGETA]> you know any ros packages good at that
[07:02:54] <veverak> nope
[07:02:56] <veverak> :)
[07:46:58] <[VEGETA]> gonna travel north vor weekend... see you after 3 days
[08:15:11] <pokmo> hi
[08:15:23] <pokmo> does anyone know of a good way for braking an universal joint?
[08:15:38] <pokmo> a small universal joint, that is. it's 1cm in diameter
[08:30:17] <theBear> err, braking one side of it
[08:30:41] <theBear> i don't see what;s so special
[09:03:58] <rue_house> break or dissassemble
[09:04:10] <rue_house> you dissassemble it in the reverse order it was assembled
[09:04:26] <rue_house> you break it with a large hammer and a chimp like attitude
[09:08:52] <theBear> you chimp like it with a large hammer you bought it
[09:08:57] <theBear> !!
[09:09:10] * theBear turns the capitalist model on its head overnight
[09:09:29] <theBear> victory for the politariat
[09:09:33] <theBear> huzzah]
[09:12:59] <rue_house> http://www.google.com/patents/US4851775
[09:13:14] <rue_house> is it me, or does that pattent seem to have a BIT TOO MUCH detail?
[09:45:49] <theBear> god forbid you get appled on such an amazing and innovative idea
[09:46:27] <theBear> heh, i admit, it is more oriented to other things than many patents
[11:20:57] <zzz64> LiohAu: "1.8v is too low of a voltage." they're missing a few words
[11:56:02] <theBear> it feels like they saying that 1.8v logic levels will work/be seen to me
[12:08:26] <SpeedEvil> http://imgur.com/gallery/UqUYw8q - on climbing stairs.
[12:08:34] <SpeedEvil> The cool way
[15:20:53] <Loshki> theBear: "get appled"? Appled?
[17:17:40] <SpeedEvil> Loshki: cider
[17:18:18] <Loshki> SpeedEvil: Ah, thank you
[18:14:55] <alexi5> hello
[18:17:19] <theBear> SpeedEvil, hehe
[18:17:30] <theBear> Loshki, round corners
[22:26:21] <rue_shop3> ok a human needs targeting help on numbers
[22:26:24] <rue_shop3> so, theBear
[22:26:33] <rue_shop3> we have one row of numbers that we need to hit
[22:26:38] <rue_shop3> 2 5 7 8
[22:26:51] <rue_shop3> and one row of dynamic numbers were we are now
[22:26:57] <rue_shop3> 1 5 9 3
[22:27:28] <rue_shop3> and we want to use colour to tell the human if each realtime needs to go up or down, or is on target
[22:27:34] <rue_shop3> so, what colour scheme do we use?
[22:27:46] <rue_shop3> green sounds like a good one to be 'on target'
[22:27:57] <rue_shop3> maybe red for too high and blue for too low?
[22:28:10] <rue_shop3> anyone?
[22:28:43] <rue_shop3> cmon, I'm writing software for controlling a 12' mecha, it needs to look good and be a little practical
[23:01:47] <rue_shop3> oooo thats really hard, to match the position like that
[23:02:10] <rue_shop3> it would help if the trainers joints had some resistance to them, they all move so freely
[23:02:23] <rue_shop3> it would also help to have some force feedback
[23:14:34] * Tom_itx pushes rue_shop3 with some force
[23:15:06] <rue_shop3> if only I could paste in colour
[23:15:19] <rue_shop3> its still hard to hit, but its a bit of guidance
[23:15:28] <rue_shop3> -- PAUSED --
[23:15:28] <rue_shop3> -20.62 , 42.75 , 8.85 , 43.77 , -2.51 , 29.89
[23:15:28] <rue_shop3> -54.23 , 88.25 , 71.82 , -45.92 , 39.47 , 7.62
[23:15:54] <rue_shop3> the bottom numbers are realtime, in colour, to let you try to match the position you were at
[23:16:16] <rue_shop3> I think I need to add a way of adjusting the positions for a point by keybaord too
[23:16:24] <rue_shop3> right now its just by the trainer
[23:16:40] <rue_shop3> and I need a way to change the offset between the trainer and the arm in realtime
[23:35:48] <rue_shop3> so I have 3 transforms
[23:36:30] <rue_shop3> one takes the ADC numbers from the trainer and turns them into degrees, one is a 1:1 used for copying, and the last takes the degrees and turns them into servo units to go to the robot
[23:36:43] <rue_shop3> so I can modify the 1:1 for offsets
[23:37:53] <rue_shop3> to do that I take the diffrence between the last position, and the current position, and thats the new offset
[23:53:08] <rue_shop3> [in INP out] [in BRIDGE out] [in OUT out]
[23:53:08] <rue_shop3> ADC DEG DEG DEG DEG SERVO_COUNT
[23:53:14] <rue_shop3> ok I think I get this
[23:53:22] <rue_shop3> each buffer has an output and an input
[23:53:34] <rue_shop3> the output of each is tied to the input of the next
[23:56:20] <rue_shop3> there are 3 function calls, one to get INP to do its math between its in and out buffers
[23:56:45] <rue_shop3> one to get the bridge to do math between the INP.out and OUT.in buffers,
[23:57:07] <rue_shop3> and one to do the math between the OUTs in and out buffers