Back
[00:02:59] <rue_house> yea its a rtc with 512 bits of eeprom, not a rtc with 512K of eeprom
[00:03:12] <rue_house> how do you roll over your buffers?
[00:03:22] <rue_house> do the heads and tails move?
[00:04:30] <rue_house> I need to work out current feedback for my servo driver
[00:04:36] <rue_house> its a mess of noise right now
[00:09:51] <z64555> rue_house: you have an index that resets to start
[00:09:58] <z64555> re: ring buffers
[00:10:43] <rue_house> k, moving pointers it sounds like
[00:10:53] <rue_house> one of two
[00:12:04] <z64555> the one on wikipedia has two indices, to allow pop's off the front of the buffer
[00:13:12] <z64555> a head and tail index
[00:15:08] <z64555> There's a singularity at full and empty states, so one way around that is to reduce the "full" amount of bytes by one. So the empty state would have the indices equal, while the full state would have the tail 1 position less than the head
[00:19:15] * rue_house nods
[00:19:19] <z64555> and, if you didn't know already, rollover of the indices can be achieved by taking the modulus of the index and the underlying array size
[00:19:45] <rue_house> yes, which makes it preferable to make the size a power of 2
[00:24:42] <rue_house> woof
[00:24:54] <rue_house> that 25.4mm bushing+block is huge
[00:25:13] * rue_house spits out bits of plastic
[00:25:25] <rue_house> I HAVE to stop chewing my tooth brushes
[00:25:49] <rue_house> 10cm across
[00:26:02] <rue_house> ooh wait
[00:26:09] <rue_house> oooh yea
[00:26:20] <rue_house> I got radius and diameter screwed up again
[00:27:03] <rue_house> muuuch better
[00:27:08] <rue_house> 5cm across
[00:28:19] <rue_house> awe, that kinda screws everything up
[00:41:54] <rue_house> awe, I cant turn on my 3d printer from here
[00:42:10] <rue_house> prolyl for the best, there's likley junk on its table
[02:30:11] <rue_shop3> I'm supposed to be able to get 0.25A from a usb with no isues, right?
[02:31:29] <rue_shop3> it says I should be good for .5A
[02:34:42] <Triffid_Hunter> rue_shop3: depends on the host. USB spec says no more than 100mA unless your device asks for more but most ports will happily provive 500mA without asking
[02:35:21] <Triffid_Hunter> rue_shop3: in fact, some motherboards just have a single 2A polyfuse on gangs of 4 ports, so you could hypothetically pull 2A from one port if the others are unused on such devices.. that violates the usb spec though and you should never rely on it
[02:45:12] <rue_shop3> right
[02:45:36] <rue_shop3> I can also dial the converter output from 12 down to 9 and save some current (linear regulator on the other end)
[02:46:47] <rue_shop3> my 1.75mm filament snapped on the bowden machine........... oooo what a mess
[02:47:01] <rue_shop3> I want that to never happen again
[02:47:14] <rue_shop3> I think I need to shape the pathway a bit in some places
[03:35:14] <rue_house> the volume of 3d printed parts on these china economy cnc machines is amazing
[07:24:17] <veverak> hmm
[07:24:27] <veverak> I have 'n' variables, and need to split them into groups
[07:24:52] <veverak> these values should generally be either close together with small difference, or have great difference
[07:25:10] <veverak> like either +- 1 diff or +- 10 difference
[07:25:49] <veverak> I need algorithm that takes array of such a values (unsorted) and splits them into groups with small variances
[07:25:54] <veverak> I wonder what could be used
[07:27:06] <veverak> generally, variables that have the +- 1 difference should be in group together
[07:27:34] <veverak> point is to have something that won't freak out where variables with +- 5 appear and won't break the universe
[07:34:06] <robopal> a tree, smaller values near the root, larger are the leafs?
[07:35:33] <robopal> your tree would have 10 levels, as much as 10 value difference
[07:36:48] <robopal> -4 or +4 difference could be left and right branch for every node
[07:37:27] <veverak> hmm
[07:37:30] <veverak> robopal: sounds interesting
[07:38:33] <veverak> self-balancing binary tree could do the trick effectively
[07:38:36] <veverak> hmm
[07:41:03] <veverak> woo wow wow
[07:41:05] <veverak> veverak
[07:41:07] <veverak> calm down
[07:41:13] <veverak> realistically you will never have more than 8 values
[07:41:22] <veverak> (it's about legs for walking robot)
[07:41:38] <veverak> less perfect, more KISS
[07:45:36] <veverak> robopal: anyway, tree, all values are leaf, it has to be balanced (RB-tree ?), left child is smaller than right child, after tree is made, you calculate variance for each node
[07:46:41] <veverak> than you go top->bottom, and when you find node with variance under coeficient -> take entire tree of that node and make it one group, than continue
[07:47:31] <veverak> or,hmm, that would have flaws too
[09:32:01] <deshipu> what do you need that for?
[10:16:53] <veverak> deshipu: picking which leg to move and where to move it
[10:17:12] <veverak> deshipu: number -> represents ho far leg is on it's track
[10:17:37] <veverak> group with smallest number is picked, to be moved as next
[10:17:48] <veverak> in case there are more than 1 leg in that group
[10:17:59] <veverak> -> use desired_leg_order to decide which leg to move
[10:19:32] <veverak> distance how far to move leg -> tends to snap into average of next group, if none goes distance defined as constant
[10:20:19] <veverak> usually, you should start with 'one group', first leg creates new one, and other legs are moved into new group
[10:20:38] <veverak> (that's for cases where you go forward on flat surface)
[10:23:35] <veverak> practical effect -> no matter what/how much breaks desired leg order and walkng, this thing will always end up in it again
[11:00:54] <deshipu> how many legs do you have again?
[11:00:59] <veverak> 4 ;)
[11:01:11] <deshipu> and you are moveing 1 at a time?
[11:01:20] <veverak> sometimes
[11:01:33] <deshipu> and sometimes less?
[11:01:35] <veverak> but number of legs is not relevant
[11:01:52] <veverak> you can move 2 at a time and it would behave similarly
[11:02:09] <veverak> hmm, to make it proper: this works only with legs on the ground
[11:02:11] <deshipu> well, considering how many possible combinations there are of 4 legs
[11:02:15] <veverak> P.S: you never know when you build centipied
[11:02:19] <deshipu> you could simply brute-force the thing
[11:02:32] <deshipu> check all possible combinations and pick the one that is best
[11:03:23] <deshipu> veverak: so why do you want legs that are far apart in the same group?
[11:03:55] <veverak> well
[11:03:58] <veverak> point here
[11:04:21] <veverak> that's not physical distance
[11:04:42] <deshipu> right, it's how far they are from their neutral point
[11:04:46] <veverak> yep
[11:05:11] <deshipu> so I can see why you want to move legs that are close together
[11:05:18] <veverak> yep
[11:05:20] <deshipu> but why also add the ones that are far?
[11:05:28] <veverak> ?
[11:05:31] <veverak> don't follow
[11:05:40] <veverak> deshipu: you calculate these groups when you want to move another leg
[11:05:41] <veverak> to pick one
[11:05:45] <veverak> next time you recalculate it
[11:06:04] <deshipu> you said that you want groups so that in every group the legs are either close or far
[11:06:04] <veverak> you split into groups, pick smallest group, pick leg from it, drop everything
[11:06:09] <veverak> (so there are obvious optimalizations)
[11:06:18] <veverak> deshipu: nooo, in each group legs are close
[11:06:27] <deshipu> that's easy to do
[11:06:29] <veverak> but groups should be far away from each other
[11:06:36] <deshipu> right
[11:07:07] <deshipu> so just do disjoint sets
[11:07:16] <deshipu> like in kruskal's algorithm
[11:07:47] <deshipu> except break it at some point before you get the full spanning tree
[11:07:53] <deshipu> to get several groups
[11:08:20] <veverak> hmm
[11:08:30] <veverak> well, I wrote "had yet to pick proper grouping algorithm"
[11:08:37] <veverak> because, in case I won't need the groups for other things
[11:08:44] <veverak> I need only to make first group
[11:08:49] <veverak> with smallest values
[11:08:52] <veverak> that could be easy ;)
[11:09:23] <deshipu> depending on what properties you want that group to have exactly, it may be non-trivial
[11:09:47] <veverak> that needs some testing
[11:09:49] <deshipu> I'm not even entirely sure this whould grouping thing helps
[11:10:05] <veverak> ah, I need groups to pick where leg should land next, yeah :D
[11:10:09] <deshipu> if you discard the groups anyways
[11:10:34] <veverak> deshipu: forgot about the "where to land next" part
[11:10:47] <deshipu> so what's the goal here?
[11:11:21] <deshipu> to keep the legs as varied as possible in their positions, so that no matter how you change the direction, you get the same expected value for their distance?
[11:11:34] <deshipu> or the opposite, to keep them together?
[11:11:50] <deshipu> or something else entirely?
[11:12:36] <veverak> deshipu: idea is to have mechanism that stabilizes everything
[11:12:50] <veverak> stable -> you can freely move legs in desired leg order
[11:13:24] <veverak> unstable -> for some reasons, it get's into chaotic state (like when other mechanisms executes something, or this can happend just when walking on cure)
[11:13:32] <veverak> *curve
[11:14:06] <veverak> or when you throw book under it's legs
[11:14:25] <veverak> practically, legs can end up in many different configurations
[11:14:41] <veverak> with this mechanism, it should always find a sensible way to continue walking and endup walking with desired leg order
[11:14:55] <veverak> (because legs travel distance, so they "snap" to group in front of it)
[11:15:23] <deshipu> ah, so the latter
[11:15:57] <deshipu> I wonder if you could keep the groups fixed, and just have some legs "ungrouped" temporarily
[11:16:12] <deshipu> I mean, the same leg would always snap to the same group
[11:16:21] <veverak> well
[11:16:23] <veverak> practically
[11:16:27] <veverak> you start with 1 group
[11:16:29] <deshipu> so the division of legs into groups would be constant
[11:16:36] <veverak> make second group
[11:16:42] <veverak> and move all legs from first group to second group
[11:16:45] <veverak> until, you have 1 group again
[11:16:54] <veverak> (in case of flat plane and straight line this should happen)
[11:17:07] <deshipu> wait, one group?
[11:17:13] <deshipu> all legs moving at the same time?
[11:17:22] <veverak> what? :D
[11:17:24] <veverak> nope
[11:17:32] <veverak> deshipu: this is concerning only legs on ground
[11:17:46] <veverak> and group is actually "group of legs that are on the ground and traveled same relevant distance"
[11:18:01] <deshipu> relative
[11:18:07] <veverak> yeah, relative
[11:18:28] <veverak> ( practically, for each leg position, you can get relevant body position, and than just compare those body positions)
[11:18:56] <deshipu> I think I'm either missing the context, or just can't understand it :)
[11:19:30] * veverak is writing the stuff
[11:19:36] <veverak> and soon will start to make pictures
[11:19:48] <veverak> anyway
[11:19:56] <veverak> deshipu: basic idea is that you can compare how far legs traveled
[11:20:15] <veverak> in sensible way
[11:20:50] <veverak> ie, if all legs would make step with same distance, you can use "number of steps made" to compare them
[11:21:43] <veverak> after that, if you figure out you can lift one leg -> you get all legs on the ground, split them into groups with same number of steps -> pick group with smallest number of steps -> pick leg from it and lift it.
[11:22:39] <veverak> of course, practically I can't use "number of steps" and use different approach to compare, which is not discrete, so it makes entire thing more complicated
[11:22:41] <deshipu> not all legs are equally costly to lift
[11:23:12] <deshipu> for some you need to change body balance, which takes time
[11:23:37] <veverak> that's another part of machinery ;)
[11:23:42] <deshipu> this is the reason why some leg orders work better than other
[11:24:01] <veverak> this generates path for legs for some distance forward
[11:24:19] <veverak> alongside, based on what was generated for legs, body path is changed so it shifts balance accordingly
[11:24:25] <veverak> (yeah, that means a lot of calculations)
[11:25:03] <veverak> deshipu: to be precise
[11:25:07] <veverak> for now, I use entire known goal path
[11:25:10] <veverak> and run 50Hz cycle
[11:25:30] <veverak> that each time: generate body path based on previous leg paths, generated new leg paths based on new body path
[11:25:56] <veverak> yeah, first few cycles body path is straight ;)
[11:28:41] <veverak> or, first few cycles this entire paths wil wildly change, but it should calm down after a few of them
[11:30:31] <veverak> well, after design, C++ implementation and I hope rpi3 will be able to handle the calculations
[11:30:47] <veverak> than, massive algorithm optimalizations and C++ optimalizations
[11:42:33] <veverak> deshipu: cost of lifting leg is properly used in algorithm that actually moves the leg
[11:42:39] <veverak> this just picks order