Welcome back to the Pintobotics newsletter! This time we’re going to have sections individually written by one of us, which will hopefully allow for more personality and blog-like detail. We’re going to be exploring new formats for at least these first newsletters, so let us know if you have any feedback.
Ø32 controller update (Chris)
The brushless DC motor controller is one of the steps we’re taking to create a high power density robot squirrel. This week, we got the motor spinning with much higher torque and efficiency using sensored six-step commutation.
The drone BLDC motors we are using have 6 combinations of ways we can apply current to the stator coils to generate a magnetic field, which create magnetic field vectors along a circle spaced 60º from each other. The motor controller firmware reads the current rotational angle of the motor, then switches on the magnetic field vector closest to 90º to the angle of the rotor. Torque is maximized when the magnetic field from the coils is perpendicular to the permanent magnet in the rotor, so we cycle through the states to keep the generated magnetic field at approximately the right angle.
In the last update, we had the motor spinning in open-loop control. This is a much simpler method that steps through the six vectors at a constant rate, then hopes the rotor follows it. However, this is inefficient because if the spinning field rate is too slow, the motor catches up and the angle is nearly 0º. If the spinning field is too fast, the motor is left behind and usually does not spin at all. You can even tell by how hot the motor gets.
One challenge was the lack of debugging tools. I’ve been using the Arduino serial monitor and plotter for serial communication between my laptop and the motor controller, but it doesn’t support sending commands and plotting data at the same time. Last week I spent a chunk of time developing a better serial app that allows sending keystrokes, plotting, and saving to CSV. Now it should be faster to develop while monitoring values such as RPM and temperature.
Serpent Serial Plotter was made with python using pyserial, tkinter, and pyinstaller. Matplotlib was used initially but proved to be too slow, even with blitting.
Next two weeks, I will be working on space vector modulation (SVM) for finer field oriented control. There are only six magnetic field vectors to work with, so there are hard transitions between the 6 sectors of the circle. We can get smoother control higher power by switching between the 2 vectors closest to the optimal angle in a way that averages to the optimal angle. The effective vector would then continuously rotate around the circle at precisely 90º to the rotor. Also, I want to quantify the motor speed, torque, and efficiency. At about half duty cycle at 11V, the motor has a free speed of around 5200 rpm. It draws 15W at stall and feels like a stiff spring, but I honestly have no idea what the stall torque is. I’ll be using a digital scale and a length of string to approximate the torque.
Mechanical design update (Jack)
Here is the most recent update on the mechanical design of the leg mechanism. It might not look too much different from the last update, but most of the components have been redesigned. The legs mechanism remains the same geometry, but the shapes of the links are modified.
Leg Assembly:
To make a 1:1 scale squirrel robot, the dimensions of mechanisms need to be controlled very carefully during the design, because the smaller dimension will give smaller inertia and make the mechanism able to fit into the squirrel body.
The biggest challenge in the leg mechanism is to reduce the dimension of the cuboid housing that holds the two brushless motors, because it has to accommodate the combined width of 2 brushless motors, 2 motor controllers, 2 spur gears, and a differential assembly that contains 3 bevel gears.
Gear Box:
In order to fit all those components while maintaining a slim build, the motor housing has very intricate undercuts.
Motor housing with all components inside:
The width of the leg mechanism is currently 76 mm, which itself is wider than a full-size squirrel. However, the squirrel will have two of those leg assemblies, but the assembly could not be made much narrower than that.
The gear ratio of the spur gear that drives the bevel gear is 1:3, and the gear ratio of the bevel gear is 3:1, which makes the total gear ratio to be 1:1. The small bevel gear that is supposed to be fixed between the large bevel gears are not integrated into the design yet, because we still think we can make some modifications to reduce the gear ratio of the bevel gears.
Short-term Goals:
In the next two weeks, I will design the small bevel gear that will drive the twisted string into the differential. Then, I will start to work on the landing mechanism. A passive landing system will be developed first before an active landing system. The passive landing system will be the front leg of the squirrel. It will have a spring damper system to absorb the moment during the landing to prevent the “second jump” after the robot touch the ground.
Squirrel thoughts (Chris)
I want to put down some thoughts about why I’m excited to be working on this project, and some ideals I want to follow when designing.
Personally, I believe that hardware development is going to be increasingly relevant in robotics, especially with all the interest in AI recently. OpenAI brought attention to the power of large language models (LLMs) to generate new content. Some of these models, like this one from Google Robotics, can use natural language to come up with a plan to manipulate items in the real world, and actually perform the task on a robotic platform. There is also impressive development in using deep reinforcement learning to train legged robots to walk on new terrain. Without any prior training or existing physical models, this quadruped at Berkeley learned how to walk within 20 minutes of stumbling around in the real world.
Although I am interested in working on controls and it is clear that improved planning and control will allow robots to perform amazing new movements, I think that at this rate we will be increasingly hitting the mechanical limits of the system as controllers are getting better at exploiting trajectories that get the very most out of each actuator. Can we allow even more room for development by raising the limits with better, or completely new hardware? Both software and hardware need to improve together so that neither is limited by the other. If one side speeds up, the other will need to as well.
The convenient thing about the hype in learning-based controllers is that we know someone is likely already working on something that will be able to adapt to a new system like the squirrel. Deepmind’s RoboCAT (not much to do with the animal cat) can generate its own training data to learn grasping behaviors on arms and manipulators it has never seen before. In the next few years, there may be a solution that fits the squirrel. Therefore, my approach is focusing on creating a system that makes many more things physically possible, so that in the future better controllers can realize those possibilities. Main ideas of this approach:
Use/create power dense actuators and mechanisms, and minimize inertias for higher accelerations, which allow more agile movements
Design mechanisms that maximize utilization of actuators in each movement so there is less dead weight. For example, our first jumping leg design has a differential to use both motors simultaneously for leg extension or for leg pitch, so that both motors are used for a given motion.
Explore novel mechanisms and niche capabilities they may create
Remote control (teleoperation) to test capabilities without needing autonomous planning
Robust enough to withstand bad controllers/human operators
Increased degrees of freedom is not necessarily a bad thing
Basically, I think robotics software is currently progressing faster than hardware, so I want to design hardware for future software to expand into.
Squirrel thoughts (Jack)
I want to share some thoughts on the squirrel from the latest updates.
When designing a very small biomimetic robot, one of the biggest challenge could be packaging. It is difficult to fit all functioning components in a small space. The current leg design is about 1:2 scale, which is much larger than what I am looking for.
Since it is very difficult to make the leg mechanism narrower, I am considering separating the encoder from the motor controller, so that the leg mechanism could be made even narrower.
Even though the leg assembly is not good enough to be biomimetic, it is a good prototype for testing the mechanism’s output to determine whether it will be enough for powering the robot to jump.
As a result, I plan to remove the yaw control for now, and use this mechanism to power both rear legs. The degree of freedom will be reduced from 3 to 2, and it will reduce the complexity in prototyping.
As Professor Yim told us, the landing of the robot will likely be more difficult than jumping. As a result, I will develop a passive landing system soon, and we can put together a robot functioning in 2D to test the jumping and landing.
Thanks for reading, and see you in two weeks!
Other links:
Youtube channel for (almost) real-time updates
Hackaday.io for more technical details on the motor controller
Great updates. Enjoyed the explanations behind the motors and mechanical designs as well as the challenges and your proposed solutions. Loved the videos and images and even some of the thinking about where the project is going and its challenges ahead.
“robotics software is currently progressing faster than hardware, so I want to design hardware for future software to expand into.” This is very exciting too.
Looking forward to the next update.