> 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?
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.