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.

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

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!

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!

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();
>> handles = InitBobbleSimConnection()
>> ActivateBobbleBot(handles.cmdBbPub);
>> velMsg = rosmessage(handles.velPub);
>> velMsg.Linear.X = 0.25; send(handles.velPub, velMsg);
>> velMsg.Linear.X = -0.25; send(handles.velPub, velMsg);
>> velMsg.Linear.X = 0.0; send(handles.velPub, velMsg);
>> ResetBobbleBot(handles.cmdBbPub);
>> ActivateBobbleBot(handles.cmdBbPub);
>> velMsg.Angular.Z = 0.1; send(handles.velPub, velMsg);
>> velMsg.Angular.Z = -0.1; send(handles.velPub, velMsg);
>> velMsg.Angular.Z = 0.0; send(handles.velPub, velMsg);
>> ResetBobbleBot(handles.cmdBbPub);
>> rosshutdown()

For convenience, the above commands are also provided in script form so they can be run with a single command like so:

run TestBobbleConnection.m

If everything is working correctly, the commands above should result in something like the following behavior:

There is no sense in continuing on unless you have the above test working. File an issue here if you are having trouble and I will try to help.

Add Blue Ball to Gazebo Scene

Using the Gazebo Model Editor, create a spherical blue ball. To do this click Edit -> Model Editor (CTRL+M). From there use the Simple Shapes option to drag a sphere onto your scene. Edit the sphere's settings to make it blue and get the size that you want. When done click File -> Exit Model Editor (CTRL+X). Be sure to save your blue ball model upon exiting.

Test Object Detection

Once you have the blue ball within Bobble-Bot's field of view, visualized by the ugly square box at the top of Bobble-Bot, you're ready to switch back over to Matlab to test the object detection algorithm. Enter the commands below:

>> handles = InitBobbleSimConnection()
>> blueBallParams.blueMax = 120;
>> blueBallParams.darkMin = 30;
>> latestImg = readImage(handles.colorImgSub.LatestMessage);
>> [c,~,ball] = FindBlueBall(latestImg,blueBallParams);
>> PlotBlueBallLocation(latestImg, ball, c);

You can repeat the above steps to tune the blueMax and darkMin values and observe their impact on blue ball detection under various simulated lighting conditions. If everything works, you should get something like this:

Tune PID Control Loop

With proper blue ball detection now working, we're ready for the last step: tuning the ball following PID controller. The default values I provide will work fine, but you'll want to experiment with different values to observe their effect. The gains are defined in Follow.m. To run the entire control loop, use the following command:

run Follow.m

If everything works, you should now be able to manipulate the blue ball's location in sim and watch as Bobble-Bot tries to find the ball and then drive to it. Here's an example of what to expect:

Conclusion

That about does it for this post. Hopefully the provided code gives you a jumping off point for trying your own high level Bobble-Bot controllers using Matlab. Thanks for reading!

References

This post would not be possible without the excellent support provided by MathWorks. This Bobble-Bot example relies heavily on functions found within the Image Processing and Robotics System Toolbox. Here are some references that were most useful to me while putting this post together.

• Matlab and ROS Integration
• Matlab Example ROS Project
• Custom ROS Messages in Matlab

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();

  pinMode(GPIO_PIN, OUTPUT);

  for(;;)
  {
    //std::cout << ">>> Setting pin high." << std::endl;
    digitalWrite(GPIO_PIN, HIGH); delay(1);
    //std::cout << ">>> Setting pin low." << std::endl;
    digitalWrite(GPIO_PIN, LOW); delay(1);
  }

  return 0;
}

Compile this with:

g++ -o gpio-rt-test gpio-rt-test.c -l wiringPi

and run with:

sudo ./gpio-rt-test

I then hooked up my oscilloscope to the pin and measured the resulting waveform.  The regular thread is the top image, the RT thread is the bottom image.

The GPIO for the RT thread executes at exactly 1 ms - or at least close enough to 1 ms given my oscilloscope settings.  You can easily juxtapose this with the non-rt thread in the top picture. I saved the RT thread wave in light blue for comparison.  You can see that the GPIO is late and the falling edge is also occurring at different times - this is a recipe for high jitter.  Give this a try on your own Raspberry Pi. 

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

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 simulation. The summary gif below captures what the "impulse_force.test" actually looks like both in simulation and reality. Looks close enough to us!

Reporting Test Results

Comprehensive automated tests are owesome, but what should you do with all that data generated by your tests? In most cases, you want a clear way to summarize the results. Additionally, it would be great if the results were easily reproducible by others. You know...for science!

For Bobble-Bot, we went with Jupyter Notebook. Jupyter is a commonly used open-source tool in data science. It allows for organizing and sharing data processing and analysis code in a readable notebook style format. There are many great examples of Jupyter Notebooks available for free on the web. 

We used Jupyter to author a test summary notebook that presents the simulation data recorded during our automated tests. The best part is that the generation of the summary report can also be automated. We generate the report within an analysis stage of our continuous integration pipeline. The report gives developers insight into how their changes impact the integrated controller performance. Here is a sample section from the report. The full report contains summary plots from the no balance test, the impulse response test, and the driving tests. The source notebook for the full report can be found here.

We use this report to ensure that any software modifications made to Bobble-Bot's embedded controller are well vetted in simulation first. This reduces our risk of damaging hardware due to inadvertent software bugs. It also helps us to quickly evaluate proposed software changes from the open-source community prior to merging them into the main-line of development.

Writing Integration Tests with ROS & Gazebo

This could easily be a post in its own right. Maybe at some point I'll write one up with more detail. In the mean-time, checkout the code found here to see how Bobble-Bot uses a Gazebo simulation to perform its automated integration tests. Here's an outline of the basic steps to follow for any ROS + Gazebo integration test.

Include test dependencies in package.xml

We added the following lines as test dependencies to our package.xml file. Our integration test requires an IMU model that our controller code does not actually depend on. This is the "hector_gazebo_plugins" test dependency shown below.

<test_depend>rostest</test_depend>
<test_depend>xacro</test_depend>
<test_depend>hector_gazebo_plugins</test_depend>
<test_depend>rosunit</test_depend>

 Include rostest in CMake

Add lines like the following in order to add your tests to CMakeLists.txt. Our full CMakeLists.txt is here.

find_package(
  catkin
  REQUIRED COMPONENTS
  rostest
)

catkin_package(
  INCLUDE_DIRS include
  LIBRARIES ${PROJECT_NAME}
  CATKIN_DEPENDS
  rostest
)

if (CATKIN_ENABLE_TESTING)
    add_rostest_gtest(balance_controller_test
          test/balance_controller.test
          test/balance_controller_test.cpp)
    target_link_libraries(balance_controller_test ${catkin_LIBRARIES})
endif() 

Write a test

This is a snippet of code from our balance test cpp file that is responsible for doing the simulated right turn at the very end of our simulation based integration test.

TEST_F(BalanceSimControllerTest, testTurnRight)
{
  // send a turn rate command of -0.1 rad/s
  geometry_msgs::Twist cmd_vel;
  cmd_vel.angular.z = -0.1;
  publish_vel_cmd(cmd_vel);
  // wait for 3s
  ros::Duration(3.0).sleep();
  bobble_controllers::BobbleBotStatus status = getLastStatus();
  const double expected_turn_rate = -25.0;
  // should be turning at least -25 deg/s
  EXPECT_LT(status.TurnRate, expected_turn_rate);
}

int main(int argc, char** argv)
{
  testing::InitGoogleTest(&argc, argv);
  ros::init(argc, argv, "balance_controller_test");
  ros::AsyncSpinner spinner(1);
  spinner.start();
  int ret = RUN_ALL_TESTS();
  spinner.stop();
  ros::shutdown();
  return ret;
}

Write a launch file

You'll want a ROS launch file to use to kick off your test. We use a common launch file for all of our tests in conjunction with one launch file specific to each integration test. Here's the launch file for our balance control test.

<launch>
  <arg name="paused" default="false"/>
  <arg name="gui" default="false"/>
  <include file="$(find bobble_controllers)/test/common.launch">
    <arg name="paused" value="$(arg paused)"/>
    <arg name="gui" value="$(arg gui)"/>
  </include>
  <rosparam file="$(find bobble_controllers)/test/config.yaml" 
            command="load"/>
  <test test-name="balance_controller_test"
        pkg="bobble_controllers"
        type="balance_controller_test"
        required="true"
        time-limit="90.0">
  </test>
</launch> 

Build and run the test

You can use catkin to build the test, run it, and report the results. We use the commands below.

catkin run_tests --verbose --no-deps --this --force-color -j1
catkin_test_results --verbose ../../build/bobble_controllers/

Here's what the simulated integration test actually looks like in Gazebo. As you can see, we use simple 3D meshes for our automated tests.

Continuous Integration with GitLab CI

Once you have written your test and you have it working on your machine, you are ready to have a build server automate it. This is the step of the process that allows your test to be continually run every time a change is submitted to the repository. Again, this is a topic that could be a post unto itself, so we just summarize the process and provide reference links for further reading. 

For Bobble-Bot, we make use of a private GitLab repository for continuous integration that remains in sync with our public facing GitHub repository. To do this, we rely on a nice GitLab feature for pull and push mirroring to GitHub. Our build server uses a Docker executor to build and test our code within a Bobble-Bot simulation container. Using Docker for Gazebo & ROS simulations is a subject for another day.

GitLab uses YAML to specify the instructions to be executed by the build server. Here's a summary snippet from our .gitlab-ci.yml file.

Here's a screen shot of an example pipeline while it's running. As you can see, we are actively developing and testing modifications to support migration to ROS2! Check back soon for an updated post on the status of ROS2 for Bobble-Bot.

More Information

That was a long post covering several interrelated topics at a fairly high level. Hopefully you found it useful. Check out the references below for more information. Leave any comments and questions below. I'll be happy to answer questions. Thanks for reading!

• Docker for Gazebo-ROS Simulations
• Analyzing ROS Data Using Jupyter
• Bobble-Bot Sim Validation
• Introduction to CI with GitLab
• ROS-test

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

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