This license is so laughably bad I had a hard time writing a parody of it [1]. It's not open source, it doesn't accomplish any of its goals, it's not novel in any way. It's a joke, a smokescreen for Prusa and it won't do anything to save him from competition. Good luck, Josef. I'd encourage everyone else to avoid this like it's radioactive.
I only ever directly interacted with Kris once, and that's all I needed. She was so kind to me when I reached out for advice and support during an extremely difficult time in my life.
I did some looking around, and it sounds like it fails to work correctly with namespace packages. Something about the way you have to add them to the path leads to them being later in the path, so there could be times where they don't get found because something earlier in the path gets used instead.
that "political spat" was actually targeted harassment towards a former PyPA member the last time someone actively working on packaging.python.org tried to be remotely opinionated. Since this ended with them stepping away and no one else has volunteered, it remains unopinionated.
Sounds like the steering council or whatever that runs python nowadays needs to step up. If people are being targeted for trying to improve packaging then the steering council should make a decision and direct all commentary, etc. to them, not individuals documenting best practices.
The whole 'let the community figure it out' seems to have failed and is causing nothing but more confusion and now attacks on people. The council needs to step up and say, "this is how python packaging will work, period. End of story, end of debate. There is no more discussion on this, the decision is final. All other python packaging tools now are non-standard and not recommended for use anymore".
That was the one good thing a BDFL model for leadership could achieve, making a hard decision in the face of many strong opinions.
You're not wrong, but it's also not the focus of the article. There's a lot of complexity in a pick and place system, for example I didn't even touch on the entirely separate board that's controlling the tool head. If I tried to capture all that at once, I'd be writing an entire textbook, not an article.
If you're interested in how the LumenPnP handles vision, you can check out the OpenPNP project which handles all of the computer vision involved.
Those are the same non-functional machines I have seen for the past decade in some cases. All of them got to vision and got stuck.
I truly hope your machine gets past that point, because it would be really good to have a genuine, open-source pick and place machine. With the current advances in ML/AI and running on graphics cards, it should be within the realm of a hobbyist nowadays.
I wish you good luck and hope to see your stuff on one of the crowdfunding sites one day.
I think you're working on some outdated assumptions. As mentioned in the article, the LumenPNP project is successful. Myself and many others have been successfully assembling boards with it since earlier this year. Lumen isn't my project, it's just the machine that the board I designed is intended to work with.
Thank you for the kind words! I'm glad it was useful.
> why not get it from 24V?
There are DC-DC converters in that same family that can do 4.75~36V -> 3.3V, but since I needed the 5V anyway for the LEDs and I/Os, tossing an inexpensive and small LDO for 5V -> 3.3V is an easy call.
Thank you! For the board layers I just used macOS's screenshot utility, though I would like to do something fancier in the future. The schematics are rendered using code I wrote specifically for this article, but I am planning to publish it as an open source library so others can use it. It needs a little bit more polishing before it's ready, though! You can follow me on Twitter if you wanna get updates about it.
I wish there was an easy way to embed a KiCad layout to a webpage in a zoomable format for design reviews. One way is to export an SVG file and show it on the web, but in my experience this starts to choke on large boards.
This website has a cool implementation of a KiCad web viewer:
That one seems a bit cumbersome. Drawing schematics and drawing layouts have much different hurdles in terms of performance, it would definitely be a fun challenge. :)
Hi! I'm planning on talking about that in an upcoming post. There's options - you can run 3d printer firmware like Marlin (C++/Arduino) or Klipper (Python & C), the tricky bit is getting those to talk to the vacuum sensors. Communication is via gcode commands sent over USB serial. Most folks are running their Lumen with OpenPNP on the host.
I'm actually running completely custom firmware that I wrote specifically for this board that's written in C and uses Raspberry Pi's pico SDK. It's similar to Marlin/Klipper in that the host communicates via gcode over USB serial and that movement commands are more or less done the same, but it gives me the flexibility to simplify the whole host view of the pneumatics. It absolutely wasn't necessary for me to this, I just wanted to.
Fantastic write up - thank you! I also love hearing about why each part was chosen. As an electronics hobbyist I often mimic portions of others' designs but I'm not always entirely sure why a certain part was chosen among the various options.
Do you prototype all this on a breadboard before making the PCB and picking specific parts? I'd be curious to hear more about your process. I feel like I always need to test everything I build on a breadboard first since I inevitably miss some small detail if I go straight to schematic + PCB design.
Great question! It really depends. If I'm working with a part I haven't ever worked with before, I'll often make a minimal breakout board that I can talk to with a devboard like an Arduino or Feather.
If I'm pretty familiar with everything, I generally dive into a rough PCB layout and debug from there. If I absolutely can't get anything to work, I'll go back to the drawing board and possibly do some little breakouts, for example: https://twitter.com/theavalkyrie/status/1457845661370568709
Edit: for this specific project I did make breakouts for testing the MOSFETs and solenoid drivers. I'm glad I did, since I was able to try out a couple of different options for each: https://twitter.com/theavalkyrie/status/1550878465876004865
Second the poster above, really enjoyed the reasoning around how and why you picked parts and the intent of various circuits..
Do you have any books you recommend on electronics? I feel I understand the basics, like what various components do in isolation, but would love to level up and understand circuit design like how you are approaching it here
I'll echo sibling's comment about just doing it. Theory only takes you so far, it's important to actually build and experiment, even if it's just in a simulator.
I can recommend Practical Electronics for Inventors as a solid base of projects to experiment with and learn from. If you want to learn how to improve circuits and optimize for specific behaviors, there is a wealth of information in manufacturer application notes. A lot of the protection circuitry used in my article follows advice found in application notes.
IMO the best way is to just pick a project and work on it. Using application notes and datasheets lets you piece together circuits, and you pick up design patterns along the way.
[1]: https://github.com/theacodes/socl