Project Logs

Collapse

• Designing an Even Smaller Balance-Bot

  Ben Steer • 05/03/2021 at 13:45 • 0 comments

  After reflecting on the first version of our mini self-balancing robot, I was wondering how I could improve the design and perhaps make it even smaller… We’re going to do an exercise in system design - which I love almost as much as creating robots - and come up with a plan for a balance-bot version 2!

  Heads up - this lil’ post contains some sponsored content from PCBWay.

  Changes in the New Design

  We’re going hard on reducing the mass of this bot; as a result, some of our components are going to change considerably. Let’s talk through the new design:

  • Chassis: We’re going to ditch most of the 3D printed parts that made up the body of the previous robot, and we’ll try to mount components directly to the PCB as much as possible. There may still be some 3D printed parts around the wheel assemblies, and the wheels themselves.

  • Minimal Features: I was overly ambitious with the previous robot, trying to add a camera, face, microphone and forklift (what a silly boy). We’re going barebones on this one and focusing on balancing, driving and turning nicely.

  • Surface-Mount PCB: Instead of the previous board, where we attached pre-made modules to our PCB using through-hole legs and headers, we’re going to have SMD mount as much as possible. The microcontroller(s) may still be mounted as modules, depending on how much work we want to put into the PCB design. Either way, this will reduce mass and let us make the board even tinier!

  • Raspberry Pi Swap-out: Instead of having a RasPi Zero, which is relatively big, we’ll go for a Wi-Fi capable microcontroller (MCU) that’s a bit more compact, like an Arduino Nano 33 IoT (which also includes a 6-axis IMU on board if we wanted to swing that way).

  • Steppers to DC Motors: Instead of our micro metal geared stepper motors (which weren’t quite beefy enough for the job), we’ll go with some brushed 6V DC motors with gearboxes and encoders, like these. This will require adding some motor controller elements to the PCB, instead of stepper driver modules. However, if we go with 6V, we won’t need 12V boost converters any more - we can draw power directly from the battery, or run them through some (relatively) high current voltage regulators.

  • LiPo to LiFePO4: Working with LiPo batteries makes me anxious lol - this time we’ll use a 2-cell LiFePO4 battery, which is less energy dense, but safer to work with.

  • Battery Indicator: It would be super handy to add a little array of LEDs to the board to indicate the remaining battery life. Last time, I had to wire and stick a little alarm board to the side of the bot, which was pretty annoying to do every time I swapped the battery out.

  The other elements of the balance bot will be similar to the original, including a dedicated MCU for balance control, 3D printed wheels, an IMU, and voltage regulators for the MCUs. Next, let’s figure out what this thing will look like.

  Physical Layout

  I’ve added a few sketches here for how I envisage the new robot being configured. Here you can see the general layout - the PCB is really the core structural element holding the robot together. Instead of having a plastic chassis with the battery mounted in an enclosure, we’ll have the battery mounted vertically on the back of the PCB with a very light frame to hold it in place. This means we can make the robot narrower, bringing the wheels closer together and reducing the overall dimensions of the robot. The motor and encoder assemblies will be mounted directly to the board with some 3D printed clamps/mounts and some pre-planned holes in the PCB.
  

  From the side view, you can see that the center of mass of the robot will be offset from center of the motor/wheel axes. We want the robot to be as statically stable as possible, which in our case, means it can nearly balance on its own if there is no outside influence. To help with this, the new design will allow the distance between the battery mount and the PCB to be customised, perhaps using some adjustable screws...

  Read more »

• Project Afterthoughts

  Ben Steer • 04/20/2021 at 02:16 • 0 comments

  I thought I'd make a few comments about what I would do differently if I did the project a second time.
  

  • I would either use stronger stepper motors next time, or DC motors that are stronger than these. They were powerful enough to keep it balanced, but not enough to reliably drive around and steer. I do like the precision of the steppers and not needing encoders though.
  • Mount the wheels more rigidly, rather than relying on the precision of 3D printed holes. Or at least get a better 3D printer XD
  • As mentioned in the first post, I would triple check the PCB design for places where pullup / pulldown resistors are needed (I hate janking things onto PCBs after the fact).
  • Spend some time setting up a method of flashing code to the Exen Mini remotely. That would save a looooot of prototyping time in the long run.

• Mini Self-Balancing Robot – Code & Run

  Ben Steer • 04/19/2021 at 10:32 • 0 comments

  In order to balance our little guy, we’re going to read in data from our inertial measurement unit (IMU), create a PID controller to catch the robot from falling, and write an accurate stepper motor controller from scratch. We’ll also read in commands from serial input, in order to tweak and configure our controller on the fly.

  I won’t give code snippets for every section of the program I’ve written, as that will make this post quite messy and detract from providing a concise overview. Instead, you can find my full program on my Github in the balance_bot repository, and refer to any code I mention here but don’t explicitly show. Keep in mind that some of the examples I give are simplified for clear explanation, so be sure to check out my Github if you want to implement something similar. Let’s get cracking!

  Measuring angles with an MPU6050

  The key piece of information we need to get our robot to balance, is the current pitch angle of the robot, which we’ll read from our MPU6050 IMU. To do this, I adapted some code from Jeff Rowberg’s MPU6050 library (as many do) for Arduino, specifically the MPU6050_DMP6 example. DMP stands for Digital Motion Processor, which is basically some circuitry in the chip which pre-processes the sensor values for us, meaning less work for us in the code.

  We take three main things from this example code. Firstly, some global variables which the program needs, namely the MPU6050 object, some flags, buffers, and vectors to store the sensor readings. You’ll find these defined in my code here. Secondly, we need to begin communication with the IMU and initialise the DMP unit, the code for which you’ll find in my setupMPU6050() function.

  Thirdly and finally, my loopIMU() function waits for an IMU reading to be available, and then calculates the robot’s pitch angle, storing it in a global variable called “pitch“. These measurements take less than 10ms to be available, meaning I’m able to call this function during each main loop and maintain it at a consistent 100Hz. This consistency is important for reliable control, which we’ll need, unless we want to see this guy on his face.

  One last thing. To make the angle reading as reliable as possible, you should run the IMU_Zero example in the MPU6050 library, following its instructions, in order to calibrate your specific chip. The output from this example program is a number of offset values, which you need to add to the setup code in setupMPU6050(), in the following section:

  // Accelerometer and gyrometer offsets.
  mpu.setXGyroOffset(-1535);
  mpu.setYGyroOffset(-255);
  mpu.setZGyroOffset(36);
  mpu.setXAccelOffset(-2947); mpu.setYAccelOffset(-5297);
  mpu.setZAccelOffset(2365);

   The values currently there are specific to my chip, and likely will cause inaccuracies with your own, so be sure to calibrate! Now, let’s do something with this angle.

  PID control

  If we want our little guy to stay upright, we’ll have to command his wheels to turn in such a way that he maintains an angle of about 90 degrees. A common control method used to address this is a PID controller, which we’ll use here. I won’t go into much detail about it, but essentially it uses the error between the desired angle (the setpoint) and measured angle (the observation), the accumulation of that error over time, and the rate of change of that error, in order to send commands to the wheels (the control signal).

  This might sound like a mouthful, but a basic implementation doesn’t require much code at all. I implemented it with a handful of global variables and a function, but I’d recommend using a struct (similar to a class in C++), or creating/using a library to keep things cleaner. It can be valuable to write it yourself, or at least see how someone else’s library works, in order to learn how it works, and perhaps to make sure it doesn’t have too much overhead for low-latency applications like this.

  The following snippet shows the core parts of my PID controller:...

  Read more »

View all 3 project logs