Back
[06:48:27] <Kozuch> hello, I need to elevate SainSmart 4WD robot platform about 30-50cm above the current chassis top for sensor mount - will someone give a hint on how to do it? my sensors will be pretty light (about 200g). My location is EU
[06:49:42] <Jak_o_Shadows> 3d printed brackets and aluminium extensions?
[06:53:10] <Kozuch> I dont really want to 3d print for this - I thought there may be some parts (like metalic construction set toy for kids) to build this from - much like this:
http://www.merkurtoys.cz/vyrobky/kovove-stavebnice-merkur this is my local product, I wonder if there is something "dedicated" to robotics...
[06:54:38] <Kozuch> here in English:
http://www.merkurtoys.cz/en/products/construction-set
[06:55:08] <Kozuch> I actually do not need to elevate the whole "deck", but could be a "pole" only...
[07:08:44] <veverak> Kozuch: where in czech republic? :)
[07:09:29] <Kozuch> Hradec Kralove
[07:09:33] <veverak> nah, too far away
[07:09:47] <veverak> anyway, Merkur commonly used in robotics for exactly this purpose
[07:10:06] <Kozuch> yeah
[07:10:26] <SpeedEvil> Or just get some wood.
[07:10:53] <Kozuch> wood is good idea actually :)
[07:11:00] <veverak> I suggest using merkur for this and if you would need something more fancy
[07:11:10] <veverak> CAD it and idilna.cz will make it for you
[07:11:12] <veverak> :)
[07:11:29] <Kozuch> ok :)
[07:12:37] <Kozuch> veverak, do you know any CZ supplier for small wooden profiles I may use if there are any at all? may be too custom...
[07:13:10] <veverak> I think you should be able to find some 'RC Models' shop in your city
[07:13:18] <veverak> they usually have materials exactly for this
[07:13:40] <Kozuch> ok. wood may be built faster and cheaper than Merkur
[07:13:43] <veverak> even local hobby shops like Hornbach, Bauhaus etc... should have
[07:13:55] <veverak> but, you always need some tools for it
[07:15:04] <Kozuch> Bauhaus they have too big profiles... plastics may be usable too. I use
http://ehlinik.cz/ for bigger things but this quite a small scale
[07:15:30] <veverak> then local RC modelar
[07:15:35] <Kozuch> ok
[07:16:06] <veverak> Kozuch:
http://easy-rc-modely.cz/stavebni-materialy
[07:16:09] <veverak> for example...
[07:16:32] <veverak> if you are interested in robotics, it's always good to know where your local RC shop is ;)
[07:16:58] <veverak> 90% of homemade robots are RC models with intelligent electronics inside
[07:22:36] <veverak> 'screw glue'
[07:23:51] <Kozuch> nice!
[07:25:11] <Kozuch> seems like these guys have quite some stock! :)
http://www.litomysky.cz/mat/
[07:26:19] <veverak> damn you, don't know of anything close to it in Brno :/
[07:26:31] <veverak> but local RC shop still have decent stock
[07:33:21] <Kozuch> I am also looking for a bigger sized 4WD platform (dimensions starting around 40x40cm) similar to these:
http://www.superdroidrobots.com/shop/category.aspx/wheeled-robots/51/
[07:34:00] <Kozuch> dont really want to order it from US... but havent found anything similar in Europe
[07:34:12] <veverak> I always found it easier to DIY this platforms
[07:34:19] <veverak> they are usually simple enough :D
[07:34:51] <Kozuch> yes but I am not a huge tinkerer yet, not much time too
[07:36:21] <deshipu> I guess it's a question of what is your goal
[07:38:14] <Kozuch> need to get up and running computer vision application quickly :)
[07:38:49] <Kozuch> got all the SW, but the HW lags badly :(
[07:38:54] <deshipu> but that's justa sub-goal
[07:40:00] <veverak> wow
[07:40:02] <veverak> https://es.aliexpress.com/item/T900-4WD-Metal-Wall-E-Tank-Track-Caterpillar-Chassis-tracked-vehicle-mobile-platform-crawler-walee-diy/32606983634.html?spm=2114.43010208.4.13.h6eYhf
[07:40:04] <veverak> sweet
[07:41:09] <Kozuch> hoping for a robotics startup one day :)
[07:41:26] <Kozuch> yes there are sweet pieces out there...
[07:41:29] <veverak> you on university?
[07:41:46] <Kozuch> nope, private hobby
[07:42:35] <Kozuch> coding mobile apps for living nowdays, but hope to jump into autonomous robotics
[07:42:54] <Kozuch> computer vision is not that difficult as it seems actually...
[07:48:32] <deshipu> depends on what you are doing
[07:48:38] <deshipu> detecting color blobs is easy
[07:48:54] <Kozuch> https://www.aliexpress.com/item/Video-Remote-Control-4WD-Smart-Car-C600-with-Camera-Big-Load-More-than-50kg/32673591529.html
[07:49:02] <Kozuch> sweet
[07:52:11] <Kozuch> customs on the way from china suck though, been trying to source stuff locally, but the chinese have some nice offers
[07:52:27] <veverak> yep
[09:04:28] <deshipu> some progress
https://cdn.hackaday.io/images/6895731474292178584.jpg
[09:35:57] <veverak> sweet <3
[11:44:25] <Kozuch> guys, do I need motor encoders for a medium sized 4WD robot? The chassis in question is something like this one -
https://www.aliexpress.com/item/C285-4WD-Car-85mm-wheels-4-motors-with-Hall-Speed-Sensor-for-Smart-Car-development-Robotic/32673314587.html
[11:44:51] <Kozuch> this is with encoders but they also have other models without - do I really need encoders?
[11:45:38] <deshipu> if you want to do any kind of accurate positioning or routing ,then you do
[11:46:43] <Kozuch> well I dont really need much accuracy... operation will be outdoors, presicion to cm at most
[11:47:30] <Kozuch> will encoders help keep the robot running straight?
[11:47:58] <deshipu> yes
[11:48:01] <SpeedEvil> 'to a cm' - lol
[11:48:06] <deshipu> pretty much necessary for this
[11:48:29] <deshipu> you will be lucky if you get half a meter precision *with* the encodres
[11:48:30] <SpeedEvil> Unless you're on flat concrete and running slowly, with a non skid steer platform - no way
[11:48:50] <SpeedEvil> and even then you will be lucky
[11:49:26] <Kozuch> I meand my "navigation SW" will have cm precision, not the robot HW
[11:49:29] <Kozuch> meant
[11:50:26] <veverak> if it's in 'cm' precisiion
[11:50:35] <veverak> there is real chance that GPS will be able to compesate
[11:50:45] <veverak> also, you said something about computer vision?
[11:50:53] <veverak> if you are clever, that can be used too to compesate :)
[11:51:13] <veverak> but you need to know what you are doing
[11:51:18] <veverak> also, encoders can be added later.... :)
[11:52:40] <Kozuch> what I will do is do steering corrections according to my SW, so if there is some "steering drift" (without encoders) I will be correcting is constantly anyways...
[11:53:34] <Kozuch> will be using cm precise RTK GPS too
[11:54:33] <veverak> should work
[11:54:44] <veverak> practically, for steering correction, it's trend to use everything you can
[11:55:01] <Kozuch> hoewver encoders could help with odometry too (another source of odometry)
[11:55:08] <veverak> means, encoders + gps + visual correction
[11:55:14] <veverak> (kalman filters!!! :)) )
[11:55:23] <Kozuch> yes, big sensor fusion :)
[11:55:33] <veverak> I suppose with GPS it should work
[11:55:56] <veverak> it's just if it will be good enough
[11:56:04] <veverak> afaik with GPS you can't detect if you are rotating on the place?
[11:56:11] <veverak> -> you need IMU :D
[11:56:26] <veverak> and analyze video picture to detect how robot actually moves! :))
[11:56:57] <SpeedEvil> veverak: or two GPSs
[11:57:08] <deshipu> five at the least
[11:57:16] <veverak> 5 IMUs is basic
[11:57:21] <deshipu> and french fries for that
[11:57:23] <Kozuch> veverak, I do stereo vision odometry - it is VERY precise
[11:57:29] <veverak> cool
[11:57:37] <veverak> Kozuch: i mean, I would not use only one odometry source
[11:57:48] <deshipu> Kozuch: as long as you have an object you can recognize there, right?
[11:57:54] <veverak> stereo vision + gps should work
[11:58:00] <veverak> again
[11:58:01] <Kozuch> sure, fusion is always better (if one can do it :)))
[11:58:08] <deshipu> veverak: what do you do when they don't agree?
[11:58:15] <SpeedEvil> deshipu: be annoyed
[11:58:25] <veverak> Kozuch: think about it in a way that you should be able to mount encoders later
[11:58:29] <veverak> deshipu: stop?
[11:58:30] <veverak> :)
[11:58:32] <SpeedEvil> deshipu: you feed it all into one maximal likelyhood filter
[11:58:34] <deshipu> veverak: explode
[11:58:38] <veverak> deshipu: exactly!
[11:58:55] <veverak> deshipu: nah, algorithms should be able to tell how precise measurement of sensor is
[11:59:04] <veverak> and mergin algorithm should be able to react to it
[11:59:18] <veverak> (slow down, stop and decide until it calms down, call 911 otherwise)
[11:59:20] <veverak> or 112
[11:59:24] <veverak> depends on the country
[11:59:59] <veverak> Kozuch: anyway, encoders are always one of the more precise odometry sources
[12:00:39] <veverak> FU me
[12:00:45] <Kozuch> veverak, sure its better to have more sensors...
[12:00:56] <veverak> "why it doesn't returns reference and returns void? in doc it says otherwise"
[12:00:59] <deshipu> veverak: any idea for that merging algorithm?
[12:01:01] <veverak> "oh, wat, that's in std17"
[12:01:03] <veverak> ...
[12:01:08] <veverak> deshipu: kalmnas are used I suppose ?
[12:01:41] <veverak> I mean, I would calculate error betwen inserting into kalman propably
[12:02:10] <deshipu> veverak: kalman needs to be tuned
[12:02:15] <veverak> it does
[12:02:16] <veverak> :)
[12:02:51] <Kozuch> kalman is pretty hard to tune, I tried in my masters thesis but failed :)
[12:03:06] <Kozuch> did not have time enough to play around with it
[12:03:14] <veverak> hmm
[12:03:16] <veverak> ROS got node for it :)
[12:03:20] <veverak> http://wiki.ros.org/robot_localization
[12:03:24] <deshipu> I think everyone are just tuning it by trying random values
[12:03:27] <veverak> exactly the topic we are talking about
[12:03:58] <Kozuch> yes random values is what I ended up with at best :D
[12:04:23] <Kozuch> anyone experienced in post-mounting encoders on motors like this?
https://www.aliexpress.com/item/C37-4WD-Car-High-torque-Motor-Aluminium-Alloy-Chassis-130mm-Big-Tyre-Wheel-for-DIY-Smart/32675187665.html
[12:04:29] <veverak> not sure how it's configured for no though
[12:04:57] * veverak could DIY it
[12:05:34] <Kozuch> I guess I rather will get the encoders from factory as I try to minimize tinkering :D
[12:05:41] <veverak> :)
[12:05:52] <veverak> one shall not be afraid of tinkering
[12:06:16] <veverak> one losts flexibility that way
[12:06:16] * veverak hides
[12:07:30] <deshipu> looses
[12:07:36] <veverak> O:)
[12:07:45] <veverak> deshipu: anyway, maybe just averaging sensor values could work?
[12:07:55] <deshipu> loses
[12:08:13] <veverak> of course you still need to calculate difference and than decide upon it
[12:08:30] <deshipu> how do you average an image from camera with a serial output from a gps? :P
[12:08:38] <veverak> you are at [0,0,0] +-[1000mm,1000mm,1000m]
[12:08:57] <veverak> deshipu: well, of course you need to get 'pose' estimates from data before merging :P :)
[12:09:35] <deshipu> your emoticons have their own emoticons
[12:09:37] <SpeedEvil> deshipu: you take the gaussian errors of both processes and sum them to get a resultant gaussian
[12:10:56] <deshipu> SpeedEvil: what if the readings don't have normal distribution?
[12:12:37] <SpeedEvil> deshipu: now you have a problem
[12:16:11] <deshipu> veverak:
https://www.youtube.com/watch?v=_YrWX9ez3jM
[12:17:37] <veverak> cooooooooooooool
[12:17:39] <veverak> :)
[12:18:46] <deshipu> I don't like the delta legs
[12:18:54] <deshipu> but I guess they are the simplest to make
[12:19:01] <veverak> yay
[12:19:05] <veverak> my code compiled!
[12:19:18] <deshipu> it must be correct!
[12:19:23] <veverak> (main.cpp: #include <complicated_stuff>; main(){} )
[12:20:20] <deshipu> (defun (include complicated_stuff) main)
[12:31:12] <z64555> veverak: see, it wasn't that difficult
[12:31:22] <z64555> now do it at least a hundred more times
[12:36:28] <z64555> I wonder if I should map the servo captures into normalized space or just keep them in their voltage space
[12:37:04] <z64555> hm.
[12:38:15] <z64555> and then there's the ADC from the sensors to consider, as well as the over-clocked PWM to the ESC's
[12:38:45] <z64555> sigh
[12:38:54] <z64555> guess I'm stuck with the normalized space
[12:40:12] <veverak> called first method
[12:40:18] <veverak> terminate called after throwing an instance of 'std::bad_alloc'
[12:40:20] <veverak> yay
[12:40:43] <z64555> oh what did you do.
[12:40:50] <z64555> pastebin plz.
[12:42:09] <veverak> complex code
[12:42:21] <veverak> https://github.com/Schpin/schpin-ros/tree/master/schpin_stg/src
[12:43:24] <z64555> where's it occuring
[12:43:58] <veverak> didn't said
[12:44:27] <veverak> nah
[12:44:33] <veverak> it runs until it's out of memory
[12:45:42] <z64555> can you run a debugger and set break points?
[12:46:08] <veverak> maybe
[12:46:15] <z64555> that call to emplace_back inside the two loops is my first suspect
[12:46:20] <veverak> I suppose I will start on logging diagnostic messages
[12:46:34] <veverak> z64555: entire Waypoint::infill is my suspect
[12:49:06] <z64555> Reason I say that is because of those two for() loops access the constants -1 by reference
[12:49:39] <veverak> FU ME
[12:49:39] <z64555> which, I might add, makes no sense
[12:49:44] <veverak> that two for loops use same 'i'
[12:50:08] <z64555> and they're operating on constants.
[12:51:00] <veverak> z64555: where in code?
[12:51:19] <z64555> stg_reactor.cpp:main()::9
[12:51:39] <veverak> that part is OK
[12:51:41] <veverak> worked before
[12:51:43] <veverak> :)
[12:51:50] <veverak> Paths::insert started the problem
[12:52:08] * veverak used same iteration variable inside Waypoint::infill
[12:53:56] <z64555> hm, my mistake then. it won't hurt anything but it does obfuscate what it's doing
[12:54:08] <veverak> yeah, rewritten it a bit :
[12:54:10] <veverak> :)
[12:58:53] <z64555> why are you using emplace_back there instead of push_back?
[13:01:15] <z64555> mkay, so you can copy the waypoint but claim the parent to be that of the path
[13:02:49] <veverak> if you copy one it makes sense they have same parent
[13:02:59] <veverak> anyway
[13:03:01] <veverak> got the problem
[13:03:03] <veverak> get_steps_between(get_pose(), prev);
[13:03:05] <veverak> returns inf
[13:03:07] <veverak> ehmm :)
[13:03:18] <z64555> btw, you might want to doxy the rest of your structures (which probably should be classes)
[13:03:45] <z64555> which is where?
[13:04:04] <veverak> Waypoint::
[13:04:09] <veverak> z64555: in todo :)))
[13:05:06] <z64555> yeah, I can't help you if it's not where I can see it
[13:05:31] <veverak> Waypoint::get_steps_between
[13:05:52] <veverak> what the fuck
[13:06:03] <veverak> ROS_DEBUG_STREAM(" Distnace between poses: " << dist << " and steps: " << dist / _conf.max_dist);
[13:06:10] <veverak> [DEBUG] [1474306679.528342393]: Distnace between poses: 10 and steps: inf
[13:06:13] <veverak> did not see that comming
[13:08:32] <z64555> is _conf properly set
[13:08:45] <z64555> *Waypoint::_conf
[13:09:27] <veverak> checking that now
[13:09:29] <veverak> it's now somehow
[13:09:40] <veverak> *not
[13:09:53] <veverak> I mean, in .cpp file I set this to 1/1000 and that dataype is double
[13:09:55] <veverak> oh
[13:09:57] <veverak> wait
[13:10:25] <veverak> 1./1000
[13:10:29] <veverak> outtrolled :)
[13:10:36] <veverak> 0 means exactly this problems
[13:13:26] <veverak> few debug logging informations here and there
[13:13:28] <veverak> few asserts
[13:13:32] <veverak> and voila! :)
[13:52:33] <z64[droid]> The Tiva launchpad has such a weird pinout
[13:59:52] <z64[droid]> It doesn't match the pinout of the msp430 except for 4 pins
[14:01:31] <z64[droid]> And there are at most 4 pins adjacent that are in the same port, average cluster being about 2 or 3 pin
[14:02:16] <z64[droid]> Makes me wonder what the design rationale was
[15:21:13] <z64555> yay, more soldering.
[15:21:19] <z64555> jumpers turned out to be too short
[15:21:38] <z64555> on the ESC junction board, or whatever its called now
[15:31:50] * z64555 gets out the desolder pump
[15:39:23] * z64555 gets out the solder wick
[15:47:56] <z64555> sigh
[16:14:43] <z64555> ?
[16:14:55] <z64555> Didn't know there was an "extra long" set of headers
[16:37:30] <z64555> lol. what
[16:37:41] <z64555> I found the stranded black jumper wire
[17:43:49] * z64555 makes another power jumper
[17:45:01] <veverak> nah
[17:45:06] <veverak> can't test my code :/
[17:45:21] <veverak> actual version one thing segfaults
[17:45:56] <z64555> so clean it up, doxy it a bit more
[17:46:24] <veverak> not my part of the code
[17:46:31] <veverak> gui of ROS i was using to view 3d things
[17:46:32] <veverak> or, wanted to use
[17:46:49] <z64555> lol.
[17:55:43] <veverak> anyway
[17:55:54] <veverak> apart from QtGui there is this website JS version
[17:56:00] <veverak> still plenty of things to play with
[18:02:12] <z64555> Qt's supposed to be good
[18:06:21] <veverak> yeah, on github I found same issue
[18:06:28] <veverak> it seems there are problems with qt4/qt5
[18:06:57] <veverak> like it is linked with bad qt libraries
[18:07:12] <veverak> anyway, I wnated webinterface too, so it's not really a problem ;)
[19:35:52] <z64555> mkay. last set of jumpers made. everything connected. now back to fiddling with the code
[19:38:15] <veverak> DONE!
[19:39:12] <z64555> oh, were we racing?
[19:39:53] <veverak> nah
[19:39:55] <veverak> wrong
[19:40:01] <veverak> I coded not exactly the way I wanted
[19:40:02] <veverak> little repair
[19:47:15] <veverak> http://i.imgur.com/wNkGqyg.png
[19:47:17] <veverak> tadaaaah
[19:47:20] <veverak> :)
[19:47:23] <veverak> arrows: robot poses in space
[19:47:32] <veverak> blue lines: paths for legs to step on during the movement
[19:47:51] <veverak> deshipu:
http://i.imgur.com/wNkGqyg.png :)))))
[20:24:48] <z64555> quadroped?
[20:38:08] <z64555> at any rate, congrats
[20:38:14] <z64555> veverak:
[22:48:38] <anonnumberanon> deshipu, what is this microcontroller with wifi on your little poney?
[23:03:53] * __m00n__ farts
[23:13:30] * rue_shop3 thinks
[23:23:30] <__m00n__> oh yeah
[23:23:47] <__m00n__> thinks it close to bed time?
[23:34:53] <z64[droid]> Possibly.
[23:39:50] <z64[droid]> The extra long headers was to my advantage, I bent them into an L hook and soldered them to the adjacent header row. Thereby saving me a bunch of time from making a bunch of tiny jumpers
[23:40:28] <z64[droid]> The I/O setup in the code is going to be messy. :(
