> I don't think it has the ability to select arbitrary edges and apply such features (I could be wrong).
That's actually how it works. Chamfers and fillets are handled by OpenCascade, so they can be applied to arbitrary edges. They only exist on the solid model though, so they are not integrated with the solver.
I'd be curious to see how native chamfers/fillets in solvespace would work, I imagine some amazing things could be done if they'd be part of the solver.
I've seen commercial products that use socketed devboards inside. If anything, it's just an indication that the hobbyist and professional spaces are slowly converging.
Please be aware that this is not a first-party open source release of a previously secret internal spec/implementation, but rather the result of an impressive reverse-engineering effort by Christian Nöding, whose videos about this project have been posted on here as well. Still, minor kudos to Behringer for giving the official permission and sharing some internals to make this possible.
For the METR rating (first half of the article), it is indeed 50% success rate at completing the task. The win rate only applies to the GDPval rating (second half of the article).
It's because the default "analog output" PWM mode of a microcontroller will only give a rough approximation of the signal that the servo actually requires. For a servo, the duty cycle is (almost) irrelevant, the 0-100% scale has no meaning here. What matters is the actual length of the control pulses in milliseconds - the gaps between them can be arbitrarily long within a certain range.
If you think about it, it actually makes a tiny bit of sense. First, it is failsafe: Breaking the control line or shorting it to ground will not move the servo to 0%, shorting it to signal level will not move it to 100% - it just doesn't move at all and stops applying force. Any sentient being within the movement range will definitely prefer it that way instead of random movements. Second, it can actually be pretty precise: The driver circuit can be completely analog, it doesn't have to be limited by arbitrary digital quantization steps. All it needs to do is check if the current encoder value is above or below the target and apply power to the motor accordingly.
There have never been any grid-scale nuclear power plants in the state of Berlin. I don't see how this statement relates to the prior discussion in any way other than vague geographic proximity.
In this specific case, they started digging through a HDD image that someone else pulled. They're still trying to get hold of an actual Redbox machine to investigate the hardware as well.
Would it be possible (in theory) to build a receiver on an embedded platform, for instance an audio-only ESP32 speaker, or is there something in the protocol that requires a more powerful device?
Fun fact: 400V 3-phase and 3x 230V are the very same thing. You'll get 230V AC between Neutral and each of the three phases, but the AC voltage between two of the phases will actually be 400V.
This was one of the first games I installed on my very first Android phone, the Motorola Milestone. 15 years later, I'm still playing it nearly every day.
I'm a bit disappointed though that the original desktop version doesn't really play nicely on touchscreens.
For inkjet technology, it's the print head. Fundamentally, an inkjet printer works similar to a plotter, laser engraver, FDM 3D printer, or CNC router: There's a mechanism that accurately places the tool head at the desired X and Y position in order to do its business [0]. This part is a solved problem, there are many open-source reference designs to draw from.
For a printer, the devil is in the details though - quite literally: A printer needs to place tiny ink dots on the work piece in a fast, accurate, predictable, and repeatable manner. Placing just one single dot at a time would be prohibitively slow, so the print head needs an array of tiny nozzles in order to print multiple rows in one pass. The design also needs to ensure a consistent (and adjustable) dot size across all nozzles regardless of the ink level.
Designing and manufacturing such a print head is extremely complicated (if not impossible) for a hobbyist, and as of today there is no vendor-agnostic third-party design you can just buy off the shelf. The only forays into DIY printers are either rudimentary low-res single-nozzle designs [1], fully repurposing existing printer hardware [2], or reverse-engineering proprietary ink cartridges that come with a built-in print head [3].
[0] Technically, this is not entirely correct because a typical printer's Y axis is a rotating drum that transports the paper instead of a linear axis. Also, a printer's X axis is usually equipped with an encoder ribbon that allows for far more accurate positioning compared to the classic open-loop stepper motor systems used in many open-source designs.
That's actually how it works. Chamfers and fillets are handled by OpenCascade, so they can be applied to arbitrary edges. They only exist on the solid model though, so they are not integrated with the solver.
I'd be curious to see how native chamfers/fillets in solvespace would work, I imagine some amazing things could be done if they'd be part of the solver.