Cool makes sense, thanks.
A long time ago, I helped on an open source project called ioio board. It connected to an android phone via USB and provided arduino-like GPIO you could access from the java code running on the phone.
It worked pretty well, considering android has no respect for real time. Most of the âmagicâ was similar to klipper. It would send commands to the microcontroller and the micro would do real time instead of trying to bit bang theough USB.
I used one to drive an RC car from the phone. The phone was the interface and it did rudamentary openCV to detect obstacles from the back camera. The phoneâs GPS also worked. The project was kind of a joke because we had a competition at work to build robots that could knock over as many orange cups (cones) as possible. The idea was that it would find orange things in the image that were taller than they were wide and drive toward them. Once the GPS told it it had moved far enough away, it would 180 and drive through again. I had each individual part working. But when I combined them, it was too much for the little phone (this was over 15 years ago). A used $100 android phone has more power and sensors than anything else in that price range. It just doesnât have any GPIO.
1 Like
Oh super cool! Hahah love the orange cup use case. I could totally see this working through a web interface on your phone as well. ESP32 would be great for thisâŚ
You just feed it the important data - like router position, tool position, orientation, and adjacent design points - at a slow sampling rate (but reasonable for a UI), and do all of the UI processing on the phone. You could probably also send the entire design file at the start and just keep that on the phone to minimize the size of data per send.