@Deemoss Unfortunately, this circuit is not intended to be used for precise (sub-millimeter accuracy) positioning. The sensor-generator setup will provide a rough idea if the robot (sensors) gets too close/far from the perimeter cable.
Hi, I have built the circuits on bread boards and testing with the analog read on my Arduino but am only getting a small change in values when the coil is 1mm from the loop. I get a low value of 56 and a high of about 200
I am hoping to use your design as an electronic finish line in a electronic billy cart timing system I am working on so I was hoping to get a high level with the coil 10cm from the loop. Should I be able to get a better result in a bread board?
I think I have a bad 22nF capacitor. It only measures 16nF
I am powering the generator with a 12v lead acid battery.
The shops are all closed for a long weekend now so I will have to wait and get a replacement capacitor on Tuesday and try again.
@Jepster This might be possible by using multiple generators with different output square wave frequencies as the frequency can be easily varied with the onboard potentiometer (about 32KHz to 44KHz). You will also have to use multiple sensor boards on the robot with different inductors/capacitors values knowing that the frequency of each tank circuit should match the frequency of its generator board.
For example :
The new Arachne perimeter generator is also doing a great job when using "concentric" as my bottom fill pattern. I had some models that are mostly round and the old permiter generator was creating a mess, the new one generates a really nice one
Arachne does seem to help a lot with bulge but it is causing holes in the letters for smaller text - probably because it does not seem to fill tight angles so well. I have been able to improve this a bit with the "Split middle perimeter threshold" parameter in "Advanced" but it still leaves some of my text with holes.
I was thinking about that but my text is on the same layers as my bulging perimeters so I tried using a box modifier. Unfortunately, the "Perimeter generator" setting does not appear to be available to modify.
If i read the article correctly, it seems that Arachne widens the extruded lines filling the gaps, instead of filling it with a gap-fill.
In the slicer preview it still looks like it's not filled.
My guess is that if I switched to ABS I would have it, at least with the older 2.3.x PS. I sure got it with the Benchy a couple years ago when I sanity checked another user's print using the same type and brand of filament.
The picture is interesting because you can absolutely tell where the solid layer ends and just perimeters remain. He may not have the bulge but it looks like the extruded PLA is experiencing different cooling which makes sense from a physics standpoint.
The bulge is very variable, different materials, different printers (even when all are MK3's), different environments all seem to potentially effect it. Its why there's never been a single simple fix.
I don't expect the arachnae slicing to magically make it perfect now either. I'm sure it will improve things for many in a lot of cases. Just as I am sure that it will make other things worse in some cases too.
I know this still in beta but I'm my excitement with this Arachne is now turning into a disappointment. I really hope they fix whatever is going up here, the seam is all over the place and the print comes with very weird artifacts that you can even see on the slicer.
Think of Arachne as a tool in your tool box, it's not the tool for everything, it has uses, I wish they hadn't made it the default,(at least you can choose not to use it). Now were going to be seeing a lot of these kinda posts through out the forum, and of course the ever present it's a bug, it was clearly stated in the alpha2 brief that in some cases it would cause these types of effects on Sharp corners, and there's more. Folks using this algorithm should learn what to expect from it and how to use it properly before reporting. Don't get discouraged by it, learn how to use it for what it's good for.
However the Arachne perimeter generator has a tendency to round concave corners, as shown in the picture below. While the perimeter curves with circular segments at concave corners produced by Arachne are geometrically correct (they satisfy the constant offset distance requirement), they may not be optimal for FDM due to the tendency of extruded plastic to shrink into concave corners, thus the classic perimeter generator producing mitered offset curves with sharp corners may print more accurate concave corners. For most prints the Arachne perimeter generator is superior, but for some functional prints where the accuracy of concave corners is important the classic perimeter generator may be better.
Based on the very limited amount of information we have. We don't have the model, we don't have the .3mf file. We have a vague description from a user we have no idea of that persons skill level, we can make an assumption since 2.5alpha has only been released for 3 or 4 days, that this has not been tested properly. Simply looking at two images and saying "This seems like a bug." is a problem. I've been testing this software since about two hours after it was released and to agree with your statement
I have found several myself. I have also been testing the Cura version even longer, and it has issues as well, make no mistake though, there are many things in slicer that can cause issues when not applied correctly, they are not bugs they are features intended for advance or higher users with great understanding of the software.
The point I was trying to make in my previous post was, take the time to check yourself, don't just jump on the bandwagon, test it for real, be methodical and know your shit, before you tell someone else how to do something or make claims of bugs and things not working properly.
Once again I will say I'm not pointing fingers and taking names, I'm not casting aspersions, or trying to belittle anyone, do what you want. I'm just trying to raise awareness, it helps the community.
Wrapping an item for item in iterable construct in parentheses makes it a lazy generator expression, which has the appearance you see. Now, the reason it does this instead of giving you an error that you would get from trying to send a non-iterable to sum() is because it doesn't evaluate anything. If you sent this generator expression to list() to evaluate it, you would get an error.
The first problem is that you have your parentheses in the wrong places. You want to call sum() on a generator expression, but instead you have written a generator expression using sum(). So you might try this:
This is because you are trying to unpack four values from each element of the list, but each element contains only two. Python unpacks each element to two floats, then tries to unpack each float to two variables. This is where the error message rears its ugly head.
So you need to change parts1() to return a list of a list of lists of lists. That is, each item in the list is a list, which contains two lists, each containing the coordinates of a point (a given point and its successor). One way to do this is to use the built-in zip() function with an offset or rotated copy of the list.
You could do this without the extra copy of the list by iterating over the coordinates in poly and keeping track of the last items you saw. But you couldn't write it as a generator expression. Instead you'd use a regular for loop.
I am also a little confused about your question, it seems that you are not intentionally using the generator and just wants to get the perimeter?I think it would be better to clean up the function perimeter() a little bit and not use a generator there, and simply iterate through the list poly and taking every adjacent pair and calculate it this way.
Hi folks. I'm a newb. My background is primarily in mechanical and fluids, so the electronics/coding is outside my wheelhouse, but not impossible for me. I am working on a small vehicle (about the size of a Roomba, or 1.5' diameter) that's similar to a lawn mower robot. I'm using an Arduino Uno and have had success at the newb level...for example, I have set up the Arduino to make my vehicle go forward (four wheel drive) until it "sees" an object (via sonar sensor), then it stops, turns 135 degrees clockwise, then goes forward again until it sees it's next object, in which case it repeats the above algorithm.
Now I'll talk about what I need help with. I need to set up a perimeter that the vehicle will stay within. My vision is to use an electric wire, similar to invisible fence used to keep dogs in the yard. I've searched these forums and the web but all I have come up with are solutions that are 5-10 years old and require me to fabricate the perimeter wire transmitter/controller with solutions that look questionable in terms of being satisfactory for outdoor use. I'd like to focus my time on my vehicle (as opposed to the perimeter wire), so I am wondering if maybe in the 5-10 years that has elapsed, did somebody develop a perimeter wire solution that I can buy/use off the shelf? And if so, what is the receiver/sensor solution that I would use on my vehicle that detects the perimeter wire?
Here are the details that I think might be useful in developing answers to my question:
*Outdoor use
*Perimeter wire and controller are powered by standard USA household 110 Volts
*Perimeter wire length is 450 feet
*Skill level: I have a technical background but not much with electronics/coding. I have a lot of potential, but I'm still coming up the learning curve. Therefore, use of expert slang/shorthand may be lost on me.
*Budget is commensurate with an amateur enthusiast. I'd be willing to spend around a few hundred dollars (more or less) for the perimeter wire and controller only (i.e., this budget is not intended to cover the receiver/sensor parts that go on my vehicle).