05/06/2021 at 00:34 •
Sixi2 has 1300 parts in 300 types.
Sixi3 has 300 parts in 25 types.
Please share with your friends and reblog this, because I need all the help I can get.
03/14/2021 at 06:42 •
Bad software is monolithic. good software is made of smaller, unit tested pieces.
Bad robots are monolithic. good robots are made of smaller, unit tested pieces.
I’ve been working on a single actuator that can be repeated six times to make an arm.
It has a harmonic drive and is daisy chain able. That means low part count, low part TYPE count, easy manufacture, easy maintenance, easy testing, easy reuse, and more.
Ive also been working on a pcb to run each unit. Canbus, 72mhz, 16bit absolute rotation resolver, it’s gonna be sweet. Already being populated, 25 days until it arrives.
I have fancier harmonic drives made of metal so I miiiight make a bigger unit just at the shoulder. We’ll see. The six-identical model should carry 2kg at 35cm with high repeatable accuracy. A bigger shoulder is just for those players that can afford to go further.
Right. I hate this layout and this crummy editor so I’m out. Come to my discord if you want to discuss further.
Ps: stop liking my old dead projects. Sixi 1 is old news.
10/25/2020 at 19:53 •
If you know how to model the tooth profile in a strain wave / harmonic gearbox, please let me know how to do it. All I've found is the pre-print on several academic papers. Thank you!
10/22/2020 at 22:14 •
10/21/2020 at 05:15 •
Finally, after half a year or more of struggle, I've figured out a not-inelegant way to record and playback robot states. It is now in the dev branch of the app.
In large part my confusion was caused by poor definition of terms. There are many ideas all referred to as "model" - the STL model of a 3d mesh, the Model in an Model-View-Controller pattern, the "model" designed to fit a paradigm, the simulated model of the robot... these all got muddled together. The knot was so bad that I couldn't see how to untangle it.
What I've realized is that there's a description of the PhysicalLimit of a robot and within that any number of states. Put another way, states are bounded by the PL. so a given state is one MVC Model and the PL is the MVC Controller.
Why does this matter? Well... I have a Sixi2 class that contains a PhysicalLimit, a Sim, a Live, a Cursor, and a set of states that form the recording of the robot. Cursor points to one of the states in the recording. i can then adjust one state by selecting it (making it the cursor) and then tweaking it. Dragging the IK pose of the cursor causes Sixi2 to use the PL to find the new FK pose of the cursor (using gradient descent). Put another way, PL is an MVC controller inside a Flyweight design pattern, and each state is a Memento - the minimum needed to restore the robot to that pose in the world.
I can command the robot to move to the cursor state, at which point both Sim and Live attempt to do so. if Live is connected to the physical machine (the serial connection is open) then the real machine will move. Because Sim is using the same path planner and timing as Live, the Sim and Live will move as one. This is a cheap way to detect unexpected interference - variation greater than some epsilon is sign that the real machine is colliding with something. It also gives me a way to get accurate time prediction on every recording.
It's late and I ramble. Maybe none of this will make sense to you, but it's the gibberish that got me to this point. I'm just glad the damn thing seems to work. Tomorrow I figure out how to add tools on the end of the robot as part of the state, and then I can finally record pouring myself a drink.
09/06/2020 at 17:20 •
Sixi robot in the wild pt 2
08/26/2020 at 22:57 •
- 08/21/2020 at 22:10 • 0 comments
- 08/08/2020 at 00:49 • 0 comments
07/28/2020 at 18:35 •
See the ROS page at http://wiki.ros.org/Robots/Sixi
or get the package directly at https://github.com/MarginallyClever/sixi-2/tree/master/ROSPackage