Tracked robots usually require at least two wheels inside to work properly. However, [James Bruton] discovered a curious tractor design from the 1940s, the Fordson Rotaped, which only uses a single sprocket wheel inside each track. Being [James], he built a self-balancing robot around the rotaped concept.
Instead of a lot of short track sections, the Rotaped uses six long sections of track, about the same length as the wheel’s diameter. To keep the track on the wheel, a series of chains or an oval frame is used on the inside of the track.
As is usual for [James]’ projects, most of the mechanical parts are 3D printed. To hold the tracks in place, he stretches a bungee cord loop around three points on each side of the track. To make things more interesting, he made the robot balanced on the tracks. This took a bit of PID tuning to get working without oscillations, since the wheels experience a slight cogging effect inside the tracks. The wheels are driven by a pair of brushless motors with O-Drive controllers. The balancing is handled by an Arduino Mega, which reads processed position values from an Arduino Pro Mini connected to an MPU6050 IMU.
This might be a viable alternative to conventional tracks for certain applications, and the reduced part count is certainly an advantage. Let us know in the comments if it spawns any ideas. [James] has previously built another tracked rover, which uses flexible 3D printed track sections. By far, the biggest 3D printed tracked vehicle we’ve seen was [Ivan Miranda]’s ridable tank.
Thanks to 3D printing and cheap hobby servos, building you’re own small walking robot is not particularly difficult, but getting them to walk smoothly can be an entirely different story. Knowing this from experience, [Max.K] tackled the software side first by creating a virtual simulation of his ZeroBug hexapod, before building it.
Learning from his previous experience building a quadruped, ZeroBug started life in Processing as a simple stick figure, which gradually increased in complexity as [Max.K] figured out how to make it walk properly. He first developed the required movement sequence for the tip of each leg, and then added joints and calculated the actuator movements using reverse kinematics. Using the results of the simulations, he designed the mechanics and pulled it back into the simulation for final validation.
Each leg uses three micro servos which are controlled by an STM32F103 on a custom PCB, which handles all the motion calculations. It receives commands over UART from a python script running on a Raspberry Pi Zero. This allows for user control over a web interface using WiFi, or from a gamepad using a Bluetooth connection. [Max.K] also added a pincer to the front to allow it to interact with its environment. Video after the break.
The final product moves a lot smoother than most other servo-driven hexapods we’ve seen, and the entire project is well documented. The electronics and software are available on GitHub and the mechanics on Thingiverse.
The Romo was a little iPhone-controlled robot brought to market with a Kickstarter campaign back in 2013. It originally used the audio jack from the iPhone for the control interface, but was quickly followed by an updated version that used iPhone 4’s 30 pin connector and later the Lightning port. Romotive, the company behind Romo, eventually went out of business, but fortunately, they open-sourced the IOS app and the firmware. This has led to a few third-party apps currently on the app store.
[David] wanted to use other hardware for control, so he set about reverse-engineering the protocol using the open-source software and a logic analyzer. Unsurprisingly, it uses a serial interface to send and receive commands, with two additional pins to detect the connection and wake up the Romo. After breaking out the interface header on the board, he was able to modify the Romo to mount a Raspberry Pi Zero, and power it using the internal battery.
[David] has not made his code public yet, but it sounds like he plans to. It looks like Romo’s can be a fun little experimentation platform, and they can be found for cheap on eBay. We covered another cool Romo hack back in 2014, which used a projector and vision system to create a Mariokart-like game. For a completely open-source smartphone robot, check out the OpenBot.
If you march sufficiently deep into the wilderness of control theory, you’ll no doubt encounter the inverted pendulum problem. These balancing acts have emerged with a number of variants over the years, but just because it’s been done before doesn’t mean there’s no space for something new. Here, [David Gonzalez], has taken this classic problem and given it an original own spin–literally–where the balancing act is now a ball balanced precariously upon a spinning wheel. (Video, embedded below.) Mix in a little computer vision for sensing, a dash of brushless motor control, a bit of math, and you have yourself a closed-loop system that’s bound to turn a few heads.
[David’s] implementation is a healthy mix of classic control theory with some modern electronics. From the theory bucket, there’s a state-space controller to drive both the angle and angular velocity of the ball to zero. The “state” is a combination of four terms: the ball angle, the ball’s angular velocity, the wheel angle, and the wheel’s angular velocity. [David] weights each of these terms and sums them together to create an input value to adjust the motor velocity driving the wheel and balance the ball.
From the electronics bin, [David] opted for an ESP32 running Arduino, the custom Janus Brushless Motor Controller running SimpleFOC, and a Maix Bit Microcontroller with an added camera running MicroPython to compute the ball angle. Finally, if you’re curious to dig into the source code, [David] has kindly posted the firmware on Github.
We love seeing folks mix a bit of control theory into an amalgamation of familiar electronics. And as both precision sensors and motor controllers continue to improve, we’re excited to see how the landscape of projects changes yet again. Hungry for more folks closing the loop on unstable systems? Look no further than [UFactory’s] ball balancing robot and [Gear Down for What’s] two wheeled speedster.
While the disquieting appearance of some of the robots coming out of DARPA and other labs might give us some reservations about how much intelligence we want to give to those robots, there’s a lot to be learned from them before their inevitable global takeover. This small quadruped called the Mini Pupper is just the robot for that job. With a low cost and familiar platform, it’s the ideal robot to learn some of the tricks of the trade.
For a quadruped so small, some unique changes had to be made to ensure the robot’s functionality. There have been a few developments since it was first shown over a year ago. The first was to design a custom servo that could handle the unique characteristics of this robot. From there, some other improvements were made to the robot chassis such as using threaded rods for ease of assembly and maintenance. Some other things have stayed the same though like using a Raspberry Pi to handle the control systems and self-navigation.
Of course everything needed to make this robot yourself is open source, from the code to the schematics. For experimenting with quadrupeds and even with automatic navigation, this would be a great way to get started, and the small size will also limit its ability for a Skynet-style takeover as well. That’s a nice bonus.
Earlier this week it was widely reported that Softbank’s friendly-faced almost-humanoid Pepper robot was not long for this world, as the Japanese company’s subsidiary in France that had been responsible for the robotic darling of the last decade was being downsized, and that production had paused. Had it gone the way of Sony’s Aibo robotic puppy or Honda’s crouching-astronaut ASIMO? It seems not, because the company soon rolled back a little and was at pains to communicate that reports of Pepper’s untimely death had been greatly exaggerated. It wasn’t so long ago that Pepper was the face of future home robotics, so has the golden future become a little tarnished? Perhaps it’s time to revisit our plastic friend.
A Product Still Looking For A Function
A Pepper earning an honest crust as a tourist guide at the Heijo Palace museum. Tokumeigakarinoaoshima, CC BY-SA 4.0.
Pepper made its debut back in 2014, a diminutive and child-like robot with basic speech recognition and conversation skills, the ability to recognize some facial expressions, and a voice to match those big manga-style eyes. It was a robot built for personal interaction rather than work, as those soft tactile hands are better suited to a handshake than holding a tool. It found its way into Softbank stores as well as a variety of other retail environments, it was also used in experiments to assess whether it could work as a companion robot in medical settings, and it even made an appearance as a cheerleading squad. It didn’t matter that it was found to be riddled with insecurities, it very soon became a favourite with media tech pundits, but it remained at heart a product that was seeking a purpose rather than one ready-made to fit a particular function.
I first encountered a Pepper in 2016, at the UK’s National Museum of Computing. It was simply an exhibit under the watchful eye of a museum volunteer rather than being used to perform a job, and it shared an extremely busy gallery with an exhibit of Acorn classroom computers from the 1980s and early ’90s. It was an odd mix of the unexpected and the frustrating, as it definitely saw me and let me shake its hand but stubbornly refused to engage in conversation. Perhaps it was taking its performance as a human child seriously and being shy, but the overwhelming impression was of something that wasn’t ready for anything more than experimental interaction except via its touch screen. As a striking contrast in 2016 the UK saw the first release of the Amazon Echo, a disembodied voice assistant that might not have had a cute face but which could immediately have meaningful interactions with its owner.
How Can A Humanoid Robot Compete With A Disembodied Voice?
In comparing the Pepper with an Amazon Echo it’s possible that we’ve arrived at the root of the problem. Something that looks cool is all very well, but without immediate functionality, it will never capture the hearts of customers. Alexa brought with it the immense power of Amazon’s cloud computing infrastructure, while Pepper had to make do with whatever it had on board. It didn’t matter to potential customers that a cloud-connected microphone presents a huge privacy issue, for them a much cheaper device the size of a hockey puck would always win the day if it could unfailingly tell them the evening’s TV schedule or remind them about Aunty’s birthday.
Over the next decade we will see the arrival of affordable and compact processing power that can do more of the work for which Amazon currently use the cloud. Maybe Pepper will never fully receive that particular upgrade, but it’s certain that if Softbank don’t do it then somebody else will. Meanwhile there’s a reminder from another French company that being first and being cute in the home assistant market is hardly a guarantee of success, who remembers the Nabaztag?
Brushless DC (BLDC) motors are standard fare in low-precision, speedy RC applications. The control schemes needed to run them slowly or precisely go deep into motor theory and might put these motors out of reach for your next homebrew robot project. [Antun Skuric] and crew aim to change just that. They’ve taken the field-oriented control algorithm and encapsulated it into a compact Arduino library, added a host of examples, and minted a stackable BLDC motor control shield to boot. The sum of their efforts is captured into the SimpleFOC Project in the aim of bringing precision BLDC control to a wide community of new hackers.
Field-Oriented Control is a BLDC motor control scheme that involves using a microprocessor to control the stator winding current in such a way that it always applies torque to the rotor. Doing so requires that your processor measure both motor current (think: shunt resistor) and rotor position (think: encoder). Implementing the algorithm, though, can get a bit tricky since it touches bits of linear algebra, motor physics, and control theory. But that’s the magic behind SimpleFOC. With the library at your fingertips, you don’t have to! And with that, the hardest part of brushless motor control has been made simpler with a solution that’s almost plug-in-and-play.
SimpleFOC has been implemented to extend to a variety of possible implementations. While you can certainly design your own control board, you can also start with the SimpleFOC motor shield for a single motor pulling up to 5 A of current. From there, you’ve got a pretty wide range of micros to choose from as the library has been extended to work on the Arduino, Teensy, STM32, and a few other microcontroller families. For implementation details, theory, and setup, there’s a healthy set of documentation to reference. And if you’re looking to share your project or ask questions, you can pop into the community forum for some high-fives and tips. Best of all, the source code has been offered for your enjoyment under a generous MIT License.
While the project kicked off last year, it’s undergoing continuous improvements including added support for current sensing and torque control in addition to position control. With a healthy community emerging around the project, we’ll keep our eyes peeled for more projects that build off of this fantastic reference design.
