Hopey

There's higher res photos on amazon.fr, linked in this thread.

Yeah, at €100, I might have to get me one of them when the time comes. Or wait until there's a discount. Just spotted another thing: I think that the material handler is designed to be motorised with the 8293 PF set. Check out the pole reverser in this shot: big version Edit: I also just spotted in the above, where the grey & beige bevel gears are in the claw, this piece in light grey? Edit 2: And another one: On either side of that piece, and connecting the two yellow 5L half beams on either side of the 11L beam in the arm/boom/jib/whatever in this shot, do I see some of these 3/4 pins in beige? A frictionless version, perhaps? Finally, I'm not sure what's going on with the axle through the beige single bevel gear in the claw. It appears to be red (or possibly orange?), but if it's only 2L, I don't see how it can attach to anything on the other side. Unless it's fixed so it can't turn, and using that function swings the claw, rather than closing it, but that seems unlikely. A new part perhaps? Perhaps a shorter one of these? Edit again: Whoops, it's just a mini linear actuator. My bad, I haven't got any of them yet, so I'm not very familiar with them.

Sorry if this is old news, but most of these are up for pre-order on amazon.fr: 42000 F1 car - €98.30 42002 Hovercraft - €14.97 42004 Backhoe - €18.80 42007 Motocross Bike - €28.10 42006 Material Handler - €61.80 There's some quite high-res images available, including at least one B-model not shown above, for 42004: <edit sorry about the huge image> Bigger version Can anyone spot any differences in these shots of the F1 car and the leaked images from a few months back?

You can fit 8 rechargeable AAAs into the standard PF battery pack. I've had no problems using this with V1 receivers.

These are awesome, I love the idea of simply exploring what's possible, in a 'because it's there' kind of way. Just thinking out loud here, because I don;t have the parts to do it myself. I'm looking at the way the red parts move relative to the adjacent ones. Two of its edges remain parallel to those in the next one clockwise, while the other two remain parallel to those in the next one anticlockwise. The parallel edges are closest to each other as they pass through the centre, and farthest apart as they pass they outside edge. Do you think you could you attach some kind of scissor linkages to each pair of red parts, such that it folds up just small enough to fit through as it goes through the centre, and opens up as it passes the outside? It may be too much; you may be approaching the limits of the friction already. Just a thought. Keep it up, I'd love to see more of these. You could make some very inspired GBC modules, methinks.

Very impressive, however one thing sticks out to me: all of the reinforcing is done using technic bricks rather than liftarms. Is this a stylistic choice? It seems to me that most of them could be replaced with liftarms, resulting in a significantly lighter structure. A 1x12 technic brick weighs 4.2g, while an equivalent 1x11 liftarm weighs only 3.0g, a more than 25% reduction. I can't tell exactly how many there are in the main arm (jib? sorry I don't know the terminology) that could be replaced, but there's at least a few dozen. Wouldn't using liftarms make a lighter structure, hence able to lift more weight? Is that part of the challenge, or are liftarms less rigid?

I assume you're talking about in the USA; it would seem that it's not as simple as 40% off; it's buy 1 (at full price), get 1 at 40% off, presumably the cheaper of the two. Here in the UK, they had a 3-for-2 deal last week. I got a pretty good deal; I bought the "Lego City Police Value Pack (66428)" and "Dino Defence (5887)" for £79.99 each as the big christmas presents for my boys, and got a 9396 helicopter for myself for free (normally £69.99). Becasue I bought them in store and spent over £100, I also got £10 credit on a loyalty card (which I've sinced used), so effectively I got all three for £150, which isn't to be scoffed at. One thing that shat me a bit though; if you bought 6 things in one transaction, the till didn't divvy them up into sensible groups of 3 and give you the cheapest of each group of 3 free, it'd just give you whatever 2 were the cheapest. So if you bought three £100 sets and three £2 minifigs, they'd charge £302 and give you two free minifigs, while if you bought them in two transactions you'd only pay £204. Which is rather rude, if you ask me.

Nice. The price tag's taken me aback a bit, but I think I might look into getting the missing pieces on bricklink. Could I substitute the pneumatic cylinder with the square bottom for any of them? I've got a few of these, and they're a little cheaper on bricklink.

Thanks, I appreciate the time you've put into helping me out with this. I think I've got enough now to keep me busy for quite a while...

Thanks, this gives me plenty of lines of enquiry for when I get to doing the indexing, although I think I'll aim for a correctly identifying from a small set slowly first, then use indexing and such to improve it. I'd never have guessed that such a technical discussion would bring up so many interesting anecdotes :) I'm currently investigating using fourier transforms for the comparison, and I'm not quite sure what I need to do next. I apply some filters to get a nice clean image (experimenting with blurs, edge detection, thresholds, back projections) then do a FFT. I end up with 2 matrices, the magnitude and the phase. If I normalise the magnitude to the grayscale range and use it as an image I see the typical cross pattern. However, all the things I've read about it have pretty much stopped at this point with a "look at the pretty pictures" and talk about the patterns that are visible, without doing any further computation. How do I go about extracting some useful information from the image from it's fourier transform? Do I do things like edge detection on the transformed data to find the strongest axes and whatnot? I'm finding this all very interesting, although I'm getting a little put off by the fact that most of the results for most of the searches I've been doing have been abstracts from Phd theses, grant proposals and other higher academic stuff. So I might be in a little over my head, but will persevere :)

So it's coming along slowly, at the moment I'm just learning how to use the relevant parts of opencv, along with gtk. Also trying to unlearn the Java way of thinking so I can understand c++ properly :) A question for ShaydDeGrai (or whoever might know): I'm getting a little ahead of myself with this, but I'm thinking about how to optimise the search. Effectively, the process is going to be taking some representation of the input image of the part and comparing it against some representation of every view of every part. Needless to say, if done naively this will take an inordinate amount of time, so one thing I'm thinking of is somehow indexing them. Part of the process will be to take the ldraw parts catalog, generating views of each piece and storing them somehow (probably in a database). Is there some way of storing a simple numerical summary of each image? Something like a hash of it, but not a hash, as a hash function is chaotic, so similar images won't have similar hashes. Pseudocode along the lines of: function T summary(image) {...} //Building database: for image in generate_ldraw_images() { T summ = summary(image); insert into images (image, summ); } //Matching input: image = get_image(); T summ = summary(image); for dbimage in (select * from images i order by |i.summ - summ| limit n) { if(match(image, dbimage) return dbimage; } i.e, some relatively quick function I can run than calculates some metric of the image which is similar for similar images. I have no idea what such a function might be, how many dimensions the result may have (hence T above), or how I might calculate it. I may be asking too much here; it may be that the "order by" in the above has the same computational complexity as the simple brute-force comparison. But if such a thing exists (with temporal transforms and whatnot), it'd be very handy. An alternative is to do it in the spatial domain; Build some sort of tree consisting of stock images, starting at the top with simple shapes (a square, a circle, a 2:1 rectangle, etc), getting slightly more complex as it goes down, with the actual part images at the leaves. It wouldn't be a binary tree, there'd be several children of each node. Ldraw views would be inserted by making some comparison (in the temporal domain? I dunno) with the images at the each level, starting at the top, choosing the closest match at each point. The matching process (or at least the narrowing down of the candidates to compare with more scrutiny) would involve repeating this process with the input image. I'm not sure if it'd work i.e. if it chooses the wrong great-great-grandparent it'd never find the right part, and I'm not sure how I'd calculate the intermediate shapes, but I't be nice to get me some of that sweet O(nlogn) action. Either way, the plan is to do what I can to decrease the computation required to find a match, by increasing the amount of computation done when inserting the database images. Hopefully this'll work, time will tell. I had thought of the idea of trying to evolve a lego-recognising neural net, but given your anecdote, I think I'll steer clear :) As an aside, anyone know of a more specialist forum where I might discuss some of this stuff?

Is this what you were going for?:

Noice. Judging by the grille, I'm guessing it's supposed to be a Statesman? Never seen one with suicide doors though...

I'm not sure yet. Obviously there's going to be some constraints, but the less restrictive, the better. It all depends on how well I can get it to work. Initially, I imagine it will be rather restrictive, and I was even considering requiring 2 or 3 different angles, which would make allowing multiple parts to be identified trickier. I've been experimenting with opencv, and I've come up with stuff like this: This is just a very simple threshold filter, in suboptimal conditions, and yet I'd say it's enough to match the bent liftarm and probably the axle. The plate and brick highlight the difficulty (or impossibility) of identifying from a single angle, and I'm definitely going to have to have a think about backgrounds before it can recognise that white gear. The plan is to get it to recognise some objects in optimal conditions, then work to improve it. Better lighting would remove the highlights on the studs of the plate. An edge detection algorithm might find the gear a it better. Recognising studs might help differentiate tiles from plates. And so on. Rather than focus on all the problems I might run into, I'm hoping to just make something simple that works sometimes, then incrementally improve "sometimes". But I think that's enough for tonight :)

Yeah, I was referring to the easy case. My initial brute-force approach is going to be generating views of each piece from some number of angles all around it, then simply comparing the input image to each of them (using transforms as you've described) and returning the best match. If I can eliminate rotation about the Z axis (from the camera's frame of reference) then this should be possible. Once I get that proof-of-concept working, it's really just a matter of optimising it. Thanks again for the help; looks like I've got some reading to do...

Thanks for your input, it's great to know that there's someone knowledgeable around. I briefly studied Fourier transforms at uni, and although most of it's fallen out of my brain since then, I think I get the general idea. I'm currently learning the opencv library, which is capable of doing most if not all of what you've described, and can certainly do Fourier transforms of one type or another. I think I'll try and implement it in such a way that I can swap different algorithms out, if that's at all possible, and use the "best" one after some experimentation. I imagine it'll be a two-step process. I haven't fully thought this through, but I'm thinking that if I can get a reasonable scale calibration, then I should be able to estimate a cuboid bounding box spatially, and only compare against parts with a similar size, i.e. if the part is 1x2x5 studs, then I only need to compare it to parts that are (approximately) that size. A quick question that comes to mind: how does rotation impact the convolution of the transformed images? i.e. if I transformed and convoluted an image, and the same image rotated say 30 degrees, would it still 'match', or would I need to do some other operation as well? Thanks for the help, you certainly haven't made my eyes glazed over :)

Yes, possibly in the future, but I don't want to start writing different versions for different platforms just yet. I really don't know how much processing power is going to be needed, and it may well not be practical to do it entirely on a mobile device. However, with a C++ library, it would be straightforward to write apps for various platforms which simply take a photo, maybe do some pre-processing of it, then upload the result to an internet server which does the processing and returns the parts list. That's a long way off though. Absolutely. I don't intend for it to be able to deal with a pile of mixed pieces, or assembled pieces. It may be possible, but that's a goal for a long time in the future. The requirement will be that the image consists of pieces laid out with some minimum gap between each piece. For now, I'm assuming that a human will disassemble the pieces, and either a human or some simple device will lay them out, but the exact nature of how this is done is beyond the scope of what I'm planning. I'm note even going to attempt to do overlapping pieces. As for orientations, this becomes a question of which is the easier task; implementing a system that can identify a piece from any angle, or or calculating (or entering) all possible orientations that each piece can have and implementing a system that can identify them more easily using that information. Time will tell. The system in the video can also use the weight of the piece, since they are delivered one at a time. Yep, determining the colour won't be a trivial task either. To be honest, I'll need to do some research on colour spaces and colour calibration. I like the idea of there being a standard calibration model that you would build and take an image of, say 4 1x2 bricks in red, green, blue and white. It's an open question to me at the moment whether I'd need a sample of every colour in order to do the calibration. But to be honest, determining the colour is a low priority for me at the moment. That's the plan :)

Yes, something like that. I hadn't actually thought of minifigures, which pose several problems: - differentiating parts from the same mould with different stuff printed on them, such as minifig heads & torsos - multi-part parts, with moveable joints. I've assumed that you'll need to have the parts disassembled, but a "disassembled" minifig torso still has its arms and hands. How will I identify a minifig torso with an arm missing? Or with its arms up in the air? Or with legs bent? etc. Oh well, these are the challenges I'll have to get to. I don't think it'd be worthwhile, as all it could really help with is determining the silhouette, which I think I can do fairly easily in OpenCV. Also, I don't have one :)

I'm really not that interested in building a sorting machine (out of Lego or otherwise), at least not at this stage. To clarify, the scope of what I'm planning is software that takes an image and lists the parts. There might be a thin wrapper around it that connects it to a webcam or whatever, but for the most part it will be a library that anyone can integrate into their own software. The point of making it open is to encourage this, so that people with more parts and building experience than me can build sorting machines and whatnot. I'm not sure how you might be able to help at the moment. What does the "LDraw Indexer" logo in your avatar mean? Assuming I use the LDraw parts library for the 3d models, I'll definitely need the advice of someone who knows the details of the format; I've not looked into this at all yet.

Hiya. (I hope this is in the right forum, I almost put it in the LDD etc one, but it didn't really seem to fit) I'm a programmer and AFOL looking for something of a hobby programming project, and I'm thinking about working on a Lego brick recognition application (or library). Jumping right to the point, imagine if you could throw a handful of parts onto a sheet of paper, take a photo of it, and have a program list precisely identify each part. The two most obvious applications of this would be automatically taking inventory, or as part of an automatic sorting machine. I've done a bit of googling, and I'm not entirely breaking new ground here. Several folks have done this before (such as , unfortunately his website's in Japanese), but there doesn't appear to be anything publicly available, so I'm thinking of starting my own.I've also done some reading on the technical side of it. The first step would be to extract the silhouette of the part (possibly from several angles), which I believe can be done using OpenCV; I think this bit would be relatively straightforward, though not without its difficulties. The next step would be using a database of the 3d models of parts (such as that used by MLCad) and determine which part most closely matches. This is by no means an easy task, but there is at least some literature on the subject. One could also possibly use the colour and weight of the part to narrow down the search. And that's it basically. There's a huge amount of technical details that would need to be addressed, such as dealing with overlapping parts, partially assembled parts, very similar parts, parts with decals, etc, and also making sure it's efficient enough to not require a supercomputer to do the detection in a reasonable amount of time, but hey, if it was easy it wouldn't be a challenge. Maybe there's some parts it can't do, no big deal. The plan is to do it incrementally. Maybe the first version will only recognise one part at a time, from only a small subset of parts, and require them to be in a specific orientation, and later more features would be added. I'm going to go ahead and assume that if something like this existed, at least some people would be interested in using it; the questions I have at the moment are: Am I re-inventing the wheel here? Has this already been done by someone that I'm unaware of? Are there any experts in image recognition floating around, or does anyone know of any they could point me in the direction of? Is anyone interested in collaborating with me on this? I'll probably go ahead with it regardless, but I'd like it to be more of a collaborative effort, preferably from someone with some experience working on open-source projects, if only in an advisory role. FWIW, I plan on doing it in C++, as I'd like to get a bit more experience with it (my speciality is Java). Cheers!

That uses 8 of these wishbone pieces, which he doesn't have. Anyway, you got me thinking about it, and I reckon it's possible. Here's my first attempt: Obviously it's just a concept, and there's a few challenges left as an exercise, such as attaching the other end of the spring to something, doing the steering linkage, and of course driving it, but that shouldn't be too difficult. Note the offset of the uni joints. Typically the centres of the uni joints would be in between the pivots of the wishbones, but that's not possible in this case, as the outer one needs to be on the steering axis. They don't have to be between the pivots, however, the lengh of the centre part of the linkage just has to be the same length as the wishbones (5L in this case). I hope that makes sense. My first intuition was to use 4 liftarms per wheel, but this seemed unnecessary, and the two I've used above seem to be enough. I might make something based on this myself if I can find the time...

I've got a similar collection, consisting of 8110, 8043 and 8109 (flatbed truck) and have had a couple of goes at building crawlers. One was an attempt to recrea te the 9398 crawler, which used 4 m-motors for drive and one for steering. This was quite heavy and needed to be geared down a bit to get it to do any decent climbing. One thing I discovered with this was that driving 5 motors at once doesn't work; as soon as I tried to steer the drive motors slowed noticeably. The other one was trying to do a simple, light chassis, with each wheel independently driven by an m motor. This one was much lighter, and crawled much better. This used a linear actuator to steer so that I wouldn't need to stall the steering motor to steer. I don't think you'll be happy with the performance of 2 M motors, but 4 works very well if you can keep the weight down (see the video in the second link above). I'm not sure how well you'll be able to make a suspension system, I have a similar part list and found myself quite limited. You've got a few more of the 6L links than I do, so might be able to do a bit better. You can certainly make a double wishbone suspension with the portal hubs, but I think you'll end up with something that's very wide, and not particularly tight. (I'm planning on getting myself an 8070 for christmas to expand my suspension possibilities).

I think the first one would be very useful, and the second one somewhat useful, though rather more specialised. Not sure if I'm hijacking by making my own suggestions, but two that I've come up with are: Two variations of the standard blue axle pin , one where the axle bit is 2L, and one where the pin bit is 2L. I've had a number of times when trying to build a rather dense studless desing in which one of these would have come in handy. A 2x2 PF "polarity reverser" plate. This needs a little explanation. It'd be shaped exactly like the plug that PF motors use to connect, but with no wires attached. One would connect a motor to an IR reciever (or battery pack or whatever), then put this plate on top of that, then connect a second motor on top of this. The two motors would then drive in opposite directions. This would allow you, for instance, to directly attach a motor to each of two wheels and drive them from a single IR channel. (When I made a direct-drive crawler with a motor on each wheel, I had to drive the left wheels from one channel and the right wheels from another, and attach the levers on the IR remote together so that they worked together, with one reversed). It would also allow much simpler installation of an adder, as each motor could directly drive one input to the differential. I imagine there's other applications. I doubt TLG would find enough use in actual models to produce this, but I think it'd be useful for MOCers.

If you're willing to do a bit of modification and are slightly handy with a soldering iron, you can make a 9.6V rechargeable battery pack out of the standard PF battery pack by putting 8 AAA batteries. link to thread I used very cheap batteries (8 for £4) and it works fine (although I've not done any rigorous testing) and if you spent a bit on some decent ones (I hear eneloops are good) it'd be even better.

This is possible. I made a pseudo-9398, using the actual instructions and the parts that I had (8043, 8110 and 8109), and used 2 M motors in place of each L motor: Apparently you're not supposed to do it like this, but I've not had any issues with it. You can even take it to extremes (That's 6 M motors driving a single axle, by the way).