The usual way robotics is taught – and nearly everything, for that matter – is simple. A teacher gets a pre-built module or kit, teaches the students how to use the kit, and class is adjourned. There are significant and obvious drawbacks to this. [Kevin Harrington]’s entry for the Hackaday Prize turns that pedagogy on its head. It’s a robotics development platform that encourages everyone to create their own robots from scratch, starting with the question, ‘how many legs do you want your robot to have’.
Bowler Studio uses OpenCV for image processing, a kinematics engine, a JCSG-based CAD and 3D modeling engine to interface with motors, create 3D models according to kinematic models, feed imaging data to a robot, and create graphical interfaces for robots. It’s an entire robotics creation studio in a single package, and of course everything can be backed up to the cloud.
The electronic backbone is another one of [Kevin] and Neuron Robotics’ projects, DyIO, a USB peripheral that makes for a great robotics platform. The DyIO can control up to 24 servos, enough for a very, very complex robot, and also has the ability to control motors, read encoders, or just blink pins.
These two projects together make for a great way to learn the ins and outs of robots that are a little more complex than a simple wheeled robot, and expandable enough to make some really, really cool projects
Where’s the movie?
https://youtu.be/lBeZVOUrRDk
Here is a playlist of a bunch of features made during development: https://www.youtube.com/playlist?list=PLrTh8skra716MUsQDSzVYOw5MoKaOhmMs
https://www.kickstarter.com/projects/neuronrobotics/wifi-dyio-robot-controller-w-24-channels
Support his kick-starter if you can it’s a great idea!
Thanks for the Boost!
Why not use ROS?
The Robot Operating System is designed for this, is open source, used by thousands of people, and works on Arduinos, small laptops, etc.
Also interfaces to Matlab, Java, etc…
Why make yet another standard??
As a researcher we had major problems implementing ROS on systems where real-time control was important. The basic underlying architecture of ROS is a single GOD server which controls packet processing (and controlled loss) and allows many leaf nodes to connect and pass messages, sort of like IRC. The problem comes when a lot of data needs to be processed by different nodes in the system as part of a real time loop (sense in one node, act in another). Under ROS, you have the first problem that all data can not be passed directly, it is required to be serialized and passed through the server, where an explicitly indeterminate amount of time passes before the message arrives at the processing node. This introduces 2 problems, a processing overhead of serialization and deserialization, and also a fatal time inconsistency that makes closed-loop control all but impossible(in a closed-for stable way).
In the Bowler Operating system the system is designed around FRP (Functional Reactive Programming) principals and uses the JVM as the common memory space for passing *references* to data and devices back and forth. By adding lots of languages that can be parsed and compiled into JVM objects, we allow for just as much design and language freedom and legacy systems, while allowing those different languages to actually communicate in a common memory space. When additional IO is needed the BowlerProtocol extends the real-time nature to the protocol itself, implementing timing watchdogs into the protocol itself, and also implementing a fully zero-conf reflection-in-protocol system that allows device developers to simply implement the way packets are defined, and the host application will use introspection to build live the packet parsers for talking to specific devices.
And Rosjava has been abandoned for a few years now, i would happily add ros nodes if someone from ROS would maintain the Java client libraries. I could generate the device descriptors on the fly from the bowler reflection information and make it all seamless…