Project Logs

Collapse

• Bobble-Bot Joins Hacktoberfest

  Mike Moore • 10/04/2020 at 18:59 • 0 comments

  I don't know about everyone else, but October is my favorite month of the year! It has finally started to cool off in South Texas. We've had some amazing weather days lately. Despite all that, of course, I'm still inside more than I should be (damn you COVID). So I find myself cruising around on the internet, when all of a sudden, I spot something that immediately made me think of Bobble-Bot... 

  And it's another great reason to love October! Hacktoberfest 2020! 

  Caught up in the spirit of October and open-source software, I decided to write up some issues and submit them to our project's GitHub. If you're interested in contributing to the Bobble-Bot software stack, now's your chance! 

  In my opinion, the computer vision and navigation related issues would make for a pretty fun hobby project for those looking to learn or get practice in ROS.

   Here's to happy hacking with Bobble-Bot in October!

• Build a Bobble-Bot

  JSook • 09/28/2019 at 22:08 • 0 comments

  Robots can be complicated, everyone knows that. Bobble-bot is design to be as simple as possible. It only takes a few tools to assemble the robot - a 2.5mm allen wrench, a 2.0mm allen allen wrench, and something to cut zip-tie tails. Easy-peasy! 

  Hopefully you've seen the Bobble-Bot assembly video in a previous post. It only took about 30 minutes to take a whole bot from loose components to fully bobbling. The robot itself is small, light-weight, and easy to handle. About 185mm x 222mm x 120mm without extra peripherals, roughly 3lbs. 

  The robot is easily split into three sections. The right actuator, left actuator, and center section. The Actuators are nearly identical save for a couple mirrored components. It takes eight unique parts and a handful of screws to assemble each actuator. The two actuators are then easily bolted to the Central Bulkhead of the robot, P/N BS2S009. 

  The center section of the robot secures the Raspberry Pi 3B, with the SOE developed CAN shield, and SOE developed Power Distribution Unit (PDU), and the battery. The Bobble-Bot has unique mounts for each of these components. 
  

  The last component to be attached is the DFRobot SEN0140 10 Axis Inertial Measurement Unit (IMU). The IMU is mounted between the wheels, aligned with the axis of rotation of the wheels themselves. This mounting configuration minimizes the complexity of transformations required to get useful data from the sensor. 

  To complete the assembly of the bot, a few cables are required. Each Chupacabra Servo Drive requires a power connection from the PDU as well as a CAN connection to the Raspberry Pi. Each wheel has a magnetic encoder that is connected directly to its Chupacabra. The Raspberry Pi gets a power connection from the PDU and a CAN signal to trigger the PDU's safety circuit. Finally, the IMU is connected to the Raspberry Pi's GPIO pins. 

  That's it! Being geared toward students, Bobble-Bot is intended to be completely customizable. All, and I mean all, of the structural components are 3D printed. The Bobble-Bot also has 6 threaded inserts on the top half of the robot that can be used for any custom peripherals you can dream up. The Raspberry Pi has ample GPIO availability, four USB ports, and an ethernet port all ready to be exploited to your robotic delight. 

  This is Bobble-bot - What will you build?

  - Josh

• Look Ma, no inductors!

  James Holley • 09/27/2019 at 23:49 • 1 comment

  Hello everyone, it's time to address the elephant in the room... or on the sides of Bobble-Bot.

  We've fielded questions about our inductors for a while now, and the short story is, we don't need them!  Here's a picture of the old Bobble-Bot with inductors and a picture of updated Bobble-Bot with some slimmed down sides.

  For those of you that are always looking for more details, here's the full scoop.  Bobble-bot includes custom motor controller boards that allow us to interface with hobby motors, yet still perform servo control.  That is, we're using BLDC (brushless direct current) hobby motors to keep the price down - motors that are usually used on quadcopters or RC planes - and adding a sensor and motor controller board that allows us to do fine motor control so we can stay balanced.  Servo control of these types of motors is hard because the motors are really small and don't have a lot of inductance themselves.  This makes current control (and therefore servo control) difficult.  Consider the following circuit (from circuitlab.com where you can do some free online circuit simulations):

  What we're trying to do here is understand how we can regulate current through L1.  In a BLDC motor, current maps to torque, and this is especially true at stall conditions, so regulating or controlling current allows the control of motor torque.  The resistance here is small - wires are hooked up directly to the motor, and the inductance here is also small.  Note that these parameters will change depending on what kind of motor you use and the size and gauge of the wires you are using to hook up to it.  For our purposes today explaining the purpose of the inductors, I've just chosen some general numbers that are easy to see what is going on.  

  If you run a time domain simulation on this circuit, you will see the following:

  Here you see that there's almost no output voltage across the inductor.  The current of an inductor is the change in voltage over time, so what you end up getting is small voltage change, and therefore a small amount of current.  Let's see what happens if we add some more inductance to our circuit.

  What I've done here is added our inductors to the side of the robot - big inductors are the training wheels for current control, let's take a look at the effect.

  And... BOOM - we've got what we wanted - we now have more output voltage across our motor, but unfortunately, we've done so at the expense of some big pieces of metal attached to the side of the robot.

  So what next?  How do we get rid of them?  The next step is to remove the inductors, but then increase the frequency at which we are commanding our motors - this is done by increasing the frequency of the voltage source pictured on the left side of the diagram, or in Bobble-Bot's case, increasing the PWM frequency and control loop frequency of our motor controller.  Here's what that circuit looks like:

  And the response:

  You can see that we are getting voltage across our inductor again, and that allows current control to be back in the picture for the original circuit.

  By putting in some work and speeding up the control algorithm on our motor control boards, we were able to achieve the current control that gave us enough performance to stay balanced without needing the inductors.  This also translates into power savings, faster motor response, and faster overall speed from our motors.  

  And of course, what blog post is complete without a video!?  Enjoy!

• The Making of Bobble-Bot

  Mike Moore • 08/22/2019 at 03:24 • 0 comments

  We are happy to announce that we have now successfully made three Bobble-Bots, and all are working great! Here's a behind the scenes look at our current "assembly process" (one Josh).

  A follow on post will contain a more detailed write-up with pictures from the process. Check back soon!

  Looking for Help

  In order to meet customer requests, we're now actively looking to expand the Bobble-Bot team. Please contact us if you would like to contribute as a consultant doing graphic design and/or technical writing. Familiarity with ROS would be a huge plus. Thanks!

• Using Matlab for Object Tracking

  Mike Moore • 07/03/2019 at 17:37 • 0 comments

  Recently I received some feedback from a few of our users requesting a Matlab sample project that can communicate with Bobble-Bot. This seemed like a reasonable enough request, so I released a new Matlab interface for Bobble-Bot last night. I'm thankful for the feedback, and excited to provide the capability to our users. Keep the requests coming. We'll do what we can!

  If you're unfamiliar, Matlab and its sister software package, Simulink, are engineering applications that combine textual and graphical programming to facilitate model based design. Both packages are commonly used in engineering curriculum around the globe. Together they provide a huge ecosystem of supporting software packages that facilitate design and analysis. Both are often used within robotics educational curriculum. The Bobble-Bot Matlab interface will allow for students already familiar with Matlab to get up and running with Bobble-Bot quickly.

  This post will give some more information on the integration of Matlab and Bobble-Bot. I will work through one example use case and provide links on how to get started on your own. See the graphic above to understand where we're headed. By the end of this post, you'll be able to teach Bobble-Bot to seek for and follow a blue ball using Matlab in combination with techniques from image processing. The source code for the demonstration project can be found here. Keep in mind, this is just a jumping off point. Once you have Matlab talking to Bobble-Bot, a whole world of possibilities opens up. You'll have the full power of the Matlab engine at your disposal! Enough hype... let's just get started and see how this actually works.

  Get the Software You'll Need

  This example is adaptable for both simulation and real hardware. This post will focus on simulation in order to make it easier for others to follow along. That said, the first step is to make sure you have the Bobble-Bot simulator. Go grab it for free from GitHub. Follow the instructions on the README to get going. More detail can also be found in this blog post.

  Next up, you'll need Matlab and the Image Processing and Robotics System Toolboxes. If you're a student, check with your university to see if you can get a copy of Matlab and these toolboxes for free. If you're in industry, be prepared to shell out some dough if you do not already have these available to you. Such is the way of the Matlab.

  Finally, clone this additional repository in order to get the custom Bobble-Bot ROS message interface for Matlab along with the ball following example.

  git clone https://github.com/super-owesome/bobble_matlab.git

  Add Camera Sensor to Bobble-Bot URDF

  Now we'll need to modify the URDF in bobble_description to add a camera sensor and plugin to the Gazebo simulation. This will enable Matlab to see the environment via a ROS camera message topic. To do this, un-comment the following line in bobble.urdf.xacro so that section looks like so:

  <xacro:include filename="$(find bobble_description)/xacro/bobble_chassis.urdf.xacro" />
  <xacro:include filename="$(find bobble_description)/xacro/camera.urdf.xacro" />
  <xacro:include filename="$(find bobble_description)/xacro/bno055_imu.urdf.xacro" />

  Be sure to re-build the simulation after making this change using catkin build.

  Load the Bobble-Bot ROS Messages into Matlab

  Let's make sure we can use Matlab to communicate with the Bobble-Bot sim. Start by launching the sim with the following command:

  roslaunch bobble_controllers run_sim.launch

  Next, launch Matlab and navigate to your bobble_matlab folder. Call the LoadBobbleMessages function to load the custom Bobble-Bot ROS messages into your path. This is a one time operation. From there, you can initialize the Bobble-Bot simulation connection and test sending some commands like so:

  >> LoadBobbleMessages();
  ...

  Read more »

• Get Real(time)

  James Holley • 06/23/2019 at 20:04 • 0 comments

  One of the coolest features of Bobble Bot's software is the realtime kernel running on the Raspberry Pi.  Admitting that I think the realtime kernel is 'cool' just shot me up in the rankings of "Most Likely to Get a Wedgie in the Near Future," but whatever, I'm going to tell you about it anyway.

  In the controls world, timing and speed are everything.  Jitter is the deviation from true periodicity of a periodic signal, or in layman's terms, the difference in time of when you expect your control loop to execute, and the actual time it does.  This has been studied extensively and leads to a conclusion we all knew was coming - if your control loop doesn't execute consistently, there are going to be problems.  

  When we get asked about Bobble Bot and the control system, a lot of times people ask "Why didn't you use a microcontroller?"  This is an excellent question - microcontrollers are built to execute control loops at a given rate- no operating system, deterministic servicing of interrupts and quick writes to communication ports or GPIO.  This minimizes the effort you have to go through to mitigate problems with jitter.  However, microcontrollers have limited functionality and a steeper learning curve for developers.  The Raspberry Pi was designed to "put the power of computing and digital making into the hands of people all over the world" - in layman's terms again, it's a really accessible cheap computer for teaching programming to people.  So, we thought it would be super owesome if we could merge both worlds - give control loop access to people via the Raspberry Pi so they are able to work on and experiment with control systems that have demanding requirements.  To make this happen, we chose the Raspberry Pi + Realtime Linux Kernel.

  The realtime kernel for Linux is becoming more popular and is working its way into the mainline development.  Better yet, a group of developers have integrated the RT patches into the Raspbian 4.14-y kernel.  I was also happy to find another hackaday project dedicated to testing this kernel!  Building the kernel is documented here, with the only notable exception for the version we are using for Bobble Bot is setting CONFIG_HZ_1000=y and CONFIG_HZ=1000, which increases the scheduler base frequency (click here for more details on the scheduler if you want them).

  RT-Tests were then used to test the latency of the realtime kernel (bottom) against the standard kernel (top).  

  These charts make it pretty clear - if you want to make sure a thread is executed at a consistent rate, you are going to need the realtime kernel.  Also, the latency of the regular kernel exceeded 16 ms at one point - for an unstable system like Bobble Bot, this could cause a fall.

  Even though these charts do a pretty good job of illustrating what you get with the RT Kernel, I wanted to provide another example you can test on your own.  This is just a small piece of C++ code that toggles a pin on the Raspberry Pi in a RT thread.  DISCLAIMER: This is just a bit of test code.  I think using delays and iostreams in a RT thread is usually bad practice, but for the sake of getting a little program off the ground, we're doing it anyway.

  gpio-rt-test.c
  

  #include <pthread.h>
  #include <sys/mman.h>
  #include <wiringPi.h>
  #include <iostream>
  
  int main(int argc, char **argv)
  {
    struct sched_param param;
  
    // Using GPIO pin 21 - feel free to use whatever is convenient for the test
    const unsigned int GPIO_PIN = 21;
  
    // Comment out the section below to remove RT scheduling
    param.sched_priority=sched_get_priority_max(SCHED_FIFO);
    if(sched_setscheduler(0,SCHED_FIFO,¶m) == -1){
      std::cout << ">>> Failed to schedule RT thread." << std::endl;
      return -1;
    }
    if(mlockall(MCL_CURRENT|MCL_FUTURE) == -1) {
      std::cout << ">>> Failed to lock memory." << std::endl;
      return -1;
    }
    // End of section to comment out for RT scheduling
  
   wiringPiSetup();
  ...

  Read more »

• Mike's Software is Broke...Again!

  Mike Moore • 05/26/2019 at 21:35 • 0 comments

  The only excuse I have left

   Why test when James breaks everything anyway?

  Developing software for a complex embedded system is hard. Tracking down a single bug in such a system can often take hours. Even worse, "fixing" a bug in one of these systems often uncovers another bug. It is a vicious cycle that embedded software developers unfortunately know all too well. Time spent resolving these issues during the development of a new product is costly. Many projects fail as a result of brittle and inadequately tested software. Many more succeed, but only after pouring a tremendous amount of money and resources into solving these issues. Fortunately, there are free and open-source tools that can be used to help avoid these problems. This project log will show the approach taken for developing and testing Bobble-Bot's embedded software.  
  

  There's no excuse for your sloppy code, Mike

  Software folks are quickly running out of viable excuses for buggy and un-testable code. I'm personally sick of uttering the phrase "but...it worked on my machine".  Many free and open-source tools are now available that can help developers create and maintain a set of automated tests of their code. Here's the list of tools that we use for testing Bobble-Bot's software (all are free).

  • Google test
  • GitLab CI
  • rostest
  • Gazebo
  • Jupyter Notebook

  Testing Bobble-Bot Software

  One of the main design goals for Bobble-Bot was to open up the software development process to the open-source community. This facilitates collaboration and learning, but it also introduces some risk. How can we ensure that our software continues to work as developers from around the world make contributions? Fortunately, this is a problem that has been solved many times over by the open-source software community. To mitigate the risk, we simply stand on the shoulders of giants. Bobble-Bot, like many other open-source projects, relies on an automated testing and continuous integration pipeline in order to ensure that our software remains in a working state.

  What this all means is that every time a change is submitted to our project's GitHub repository, an automated build and testing pipeline is triggered. This testing pipeline is comprised of stages which build, test, and analyze the proposed changes. The picture above is a view of the pipeline in action. The testing stage includes eighteen different pass/fail checks that are performed on the balance controller using our simulator. The analyze stage produces a summary Jupyter notebook which is automatically uploaded to our build server as the final and primary output of the testing pipeline. This notebook is a document that is manually reviewed before accepting the proposed software changes to our development baseline. The table below describes the tests that are done and provides links to the actual source code for each test.

  Bobble-Bot's automated tests

  Test Name	Description	Source Code
  No balance	Bobble-Bot uncontrolled	no_balance.test
  Impulse force	Balance control active, impulse applied	impulse_force.test
  Balance control	Balance control active, drive around	balance_controller.test
  Drive square	Balance control active, drive in square	js_drive_square.test

  Testing With Simulation

  Simulation can be an invaluable tool for automated testing. For Bobble-Bot, we use Gazebo as our simulation environment of choice. Gazebo was selected because it is free and it integrates well with ROS. Of course, in order for your test results to be trustworthy, your simulation must adequately approximate reality. Check out this post where we establish the validity of the Bobble-Bot...

  Read more »

• Bobble Build: Part 2 - Crimpin' ain't Easy

  James Holley • 05/19/2019 at 21:33 • 1 comment

  Is crimpin' easy?  Hell yeah!

  Making cables is the WORST part of finishing a build.  We've all been there - adding the final touches to a project just to find out that some (or all) of the cables have a loose connection, bad crimp / solder, wrong pinout, etc.  Sometimes pins push back out of their connectors or, as you are trying to solder a pin, you melt the whole thing...  

  Getting your cable assembly reliable and easy can be hard on DIYers.  Below is an image from customcable.ca that captures some of the pros and cons of soldering vs. crimping at a high level.

  The biggest problem for hobbyists and DIYers... Crimping doesn't have a low initial setup cost?!?!?  Like I said, crimpin' ain't easy.  But wait!  It's not so bad - here's what we're using for Bobble-Bot.

  If you take a look for this guy, you'll see its priced in the $425 range.  Yikes!  A little steep for some of us, but lets put it in perspective - Can this tool reduce the number of bad connections down the line?  Is it easier and more reliable than soldering?  

  Right now I'm putting together 2 Bobble Bots, each with 60 crimped connections, making 120 connections total - when you have a lot of connections in front of you, any mistake can spiral into hours of lost time troubleshooting or repairing a poor initial job.  If I spend 5 minutes on each connection, I'm looking at 10 hours of work just putting together cables.  That's not super owesome at all.

  The major takeaway: If you plan on doing a lot of cabling, get yourself a crimper.  It will cost a bit up front, but you'll see how much time it saves you down the line.  We reuse this crimper and different styles of the CLIK-Mate connectors for most of our projects that require small gauge wire.  The connectors themselves are cheap and reliable.

  So, how does one crimp?  The first step is stripping the wire - don't strip too much.  The nice part about crimped connections is you can minimize the amount of exposed wire and not have to use heat shrink.  The back prongs of a CLICK-mate connector are designed to hold onto the insulation of the wire.  Here is a close up of the minuscule amount of wire I stripped off the end - for reference the wire is 28 AWG.

  After that, I insert the connector in the crimper and close the crimper about half way - there is a piece of backing that is used to push the wire against to ensure it is inserted at the proper depth.  Closing half way makes sure the connector is removing most of the room where the wire could mistakenly push through past the backing.

  After that, you just put the wire in and sqeeze the handles down.  Completed crimp below.

  One of the best parts about crimping is you can inspect the connector after it has been crimped to verify your connection is in good condition.  Compare this with soldering, where you could end up with cold joint and the outside still looks OK.  Here's a pic of a good crimp.

  You can see that the insulation has been grasped by the back tongs and the wire is smushed down under the front tongs.  I always do a pull test after each crimp after visual inspection.  Better to know that its going to come apart before it ends up in a cable.  Slide it into the connector and its done!

  Rinse and repeat 120 times... Maybe a coffee break or two mixed in there and...

  
  

  So we have more Bobble Bots on the loose - look for some updates on testing, software, and design refinement in the coming weeks.

  -James

• Bobble Build: Part 1 - Solder on!

  James Holley • 05/13/2019 at 04:32 • 1 comment

  New PCBs are in, time to start soldering on components!  

  The board we're going to cover in this post is the PDU  (Power Distribution Unit). 
  

  When it comes to LiPo batteries, I always try to stay on the safer side of things when I can, so the main components are an inline fuse and relay.  The fuse we are using right now is rated to 15A - probably way more amperage than we need, but it will shut off power in case something short circuits.  The relay will be used so that a signal from our on-board computer (Raspberry Pi) will be required to power the motors.  This is nice just in case Bobble Bot takes a spill or the computer loses power, we can cut power to the wheels so our day doesn't get any worse.  Other than that, the PDU just gives us a couple of nice connectors from the battery to boards we want to power - there's not much to it.  The schematic is posted below for anyone that wants to take a closer look or offer any pointers.

  I included a LED so you can see when the relay is closed and power is passing through - don't mess with the bot while the power is hot!

  This is a connector and transistor circuit that completes the relay - pin 2 is connected to the Raspberry Pi GPIO and completes the circuit through the MOSFET.  Pins 3 and 4 can be connected through a switch if you want an additional check on power going through the relay.

  So now... I've chosen some SMT parts for the resistors, transistor, and LED.  Even though these parts are a little trickier to solder, they have some good advantages.  SMT parts are usually cheaper than through hole parts when buying in bulk, so you can save some money down the line if you know you are going to use a lot of them.  If you are ever planning on getting your boards manufactured and assembled, SMT parts are the go to - through hole parts have to be soldered by hand, so you will have to go SMT at this point.  SMT parts take up less board space and they don't stick through the bottom.  This can be helpful for keeping interference with mechanical mounting to a minimum.  And, if you have a little practice, they are not to difficult to solder yourself!  I use a simple technique to help me solder them down - I usually go with 0805 components or larger to make the job easier.  

  I've soldered in my fuse and relay - time to go after the SMT parts to the bottom right of the picture.

  The first step is to get the resistor on the board and to fill one of the two pads with solder.  The other pad is kept clean. Make your life easy - the right pad is soldered here because... well.. I'm right handed, so that's the hand I hold the soldering iron in.  Soldering SMT can be a little delicate, so make sure you set yourself up for success.
  

  I have two go to tools for the next step - a probe and a pair of tweezers.  Which one I use depends on the location of the soldering and how big the component is.  For smaller components, a straight probe to push the SMT part is usually more helpful than trying to grab it.  

  Heat up the solder on the pad, and push the part into place - make sure that the part is flush with the board.  A trick I usually use is to hold the part in place with the probe or tweezers and remove the soldering iron first.  Wait for the solder to solidify, and you are good to go.

  Once one side is soldered down, you can move to the other pad to complete the job.  Here's a picture of the finished resistor.

  And there you have it!  After that its just rinse and repeat until you get the final product:

  The first PDU is on the newly printed parts, ready for some functional testing!  After that, it'll be time to make cables and get everything wired up. 

  Bobble on,

  James

• New Bobble-Bot Chassis - A 3D Printing Story

  JSook • 04/28/2019 at 16:45 • 0 comments

  We've spent the past month getting two new chassis built, color coordinated this time. Getting the first robot built, tested, and controllable took quite a while. The BB2 robot was designed, built, assembled, and disassembled more times than a sane person would care to count. After getting the mechanical design nailed down, it was a simple task to 3D print a couple fresh chassis - not.
  
  3D Printing has become the method of choice for manufacturing custom components on the cheap. I'm sure many of you have some experience 3D printing and probably own your own machines. Anyone that owns an entry level 3D printer quickly learns their temperament. Hobby level 3D printing technology has changed the world, allowing an ambitious soul to quickly turn their ideas into reality. When the machine is working, the user is blessed with the ability to manufacture virtually any geometry their imagination desires. Maker-heaven forbid the machine is in a bad mood, a 12 hour print can take a week (ask me how I know). 
  

  The construction of BB2 is primarily based on 3D printing. A single bot takes approximately 24 hours of print time. With a few kilos of PLA in hand I started the printing process. Our Makerbot was having none of it. Constant under temperature conditions, filament jams, missed lines, and fan speed errors it would take a few weeks to get the issues under control.

  The Makerbot Replicator+ used to manufacture the bots does have several hundred hours on it, turns out it was time for a significant overhaul. Adjusting the belt tensions helped with missing lines of parts, but didn't entirely solve the issues. To combat the under temperature issue I disabled the PLA cooling fan (relax, not the extruder cooling fan). The extruder was able to hold 215C, but a side-effect is that the parts were extremely stringy with poor surface finishes. Opening and cleaning the extruder helped with filament jams but didn't stop them completely. Another issue I noticed but wasn't able to easily solve was a failure of the Smart Extruder+'s proximity sensor. After wasting far too much time messing with the extruder I traded $200 to Amazon for a replacement. $200 well spent, heater problems were solved, surface finishes improved, overall reliability of the machine was back to something acceptable. I suspect the root cause of the extruder failure is a defective heating element. Before the machine changed it's mind back we printed around the clock until all the parts were completed. 

  I spent another day post processing the parts, cleaning support material away from the larger parts and installing heat-set threaded inserts. Surprisingly, almost all the parts bolted right up save for a few issues with motor fitment. We're installing the electronics on the bots now, standby for another progress update! Coordinated bobbling coming soon.

View all 13 project logs