Demonstration robot for learning principles of real-time control using Raspberry Pi, RT Linux, and ROS.

Similar projects worth following
Bobble-Bot is being built to help students, hobbyists, and educators learn about the fundamentals of robotics in a safe, affordable, and fun way. He's a funny looking little guy with a big heart and an ever-present focus on his time critical tasks -- upon which his entire balancing-being depends.

- Supports course work for many classes in computer science and engineering.
- Exercises tailored to a university lab environment are available upon request.
- Comes with a free open-source simulator.
- Customize your Bobble-Bot's software using a C++ or Python API.
- 3D printable parts!

Meet Bobble-Bot

Why Did We Make This Thing?

We created Bobble-Bot to empower aspiring makers, tinkerers, and creatives. The robot provides a fun and affordable way to acquire and demonstrate valuable skills in computer science and engineering.

What Problem Does it Solve?

Every day businesses around the world struggle to cope with a global shortage in technology related skills and talent. This costs the world economy hundreds of billions of dollars in unrealized revenues.

We believe that one contributor to this problem stems from a lack of accessible, high-quality, and open-source educational material. The Bobble-Bot project helps motivated individuals develop valuable cross-disciplinary technology related skills.

In particular, Bobble-Bot fills a shortage within the educational robotics space. Until now, there has not been an easily accessible open-source example of real-time control for the DIY crowd. 

What Are Our Goals?

We want educators, students, and hobbyists to get up and running with this open-source robot as quickly as possible. Our hope is that this project functions as a guide for how to develop and test robust control systems for robot prototypes. We envision this robot will be useful to professionals looking to sharpen their skills while having fun, and also to students looking for a hands-on application to the often dry engineering theory covered in courses around the world. The combination of simulation and hardware opens up many possibilities for exploration and development.

Where to Start

We recommend you start with the Bobble-Sim. That's a free way to gain some quick insight into the project.

How to Contribute

For software contributions, please read our contributing guide. We welcome support in all areas, though. If you have any ideas, leave a comment. Thanks!

Licensing Information

Bobble-Bot's simulation software licensing agreement can be found here.

The robot's software infrastructure heavily leverages the Robot Operating System (ROS). The ROS licensing agreement can be found here

The simulator also relies on Gazebo. The Gazebo licensing agreement can be found here.


Hardware components graphic (1/2)

Portable Network Graphics (PNG) - 278.67 kB - 04/16/2019 at 02:28



Hardware components graphic (2/2)

Portable Network Graphics (PNG) - 278.23 kB - 04/16/2019 at 02:28



Bobble-Bot CAD Assembly (1/5)

Portable Network Graphics (PNG) - 396.95 kB - 04/16/2019 at 02:29



Bobble-Bot CAD Assembly (2/5)

Portable Network Graphics (PNG) - 182.42 kB - 04/16/2019 at 02:29



Bobble-Bot CAD Assembly (3/5)

Portable Network Graphics (PNG) - 140.98 kB - 04/16/2019 at 02:29


View all 12 files

  • 1 × Raspberry Pi Model 3B Linux SoC. Runs our balance controller and other Bobble-Bot software
  • 2 × Tacon 96M608 BLDC motors Brushless DC motors that drive the wheels
  • 2 × Chupacabra BLDC motor driver Closed loop control of BLDC motors
  • 2 × AS5047D Position Sensor Measures motor position
  • 1 × CAN I/O Shield Raspberry Pi shield for CAN bus communications

View all 9 components

  • The Making of Bobble-Bot

    Mike Moore08/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 Moore07/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

    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 Holley06/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.


    #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
      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
    Read more »

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

    Mike Moore05/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 " 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).

    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 NameDescriptionSource Code
    No balanceBobble-Bot uncontrolledno_balance.test
    Impulse forceBalance control active, impulse appliedimpulse_force.test
    Balance controlBalance control active, drive aroundbalance_controller.test
    Drive squareBalance control active, drive in squarejs_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 Holley05/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 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.


  • Bobble Build: Part 1 - Solder on!

    James Holley05/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,


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

    JSook04/28/2019 at 16:45 0 comments

    BB2s 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.

  • Why All the Fuss About Real-Time?

    Mike Moore04/17/2019 at 04:20 3 comments

    In order to get the best possible performance out of the balance controller, great care must be taken to ensure that the control loop operates at as close to a fixed 200 Hz loop rate as possible. From a write-up Jackie Kay (Open Source Robotics Foundation) contributed on real-time computing in ROS2:

    A real-time computer system needs both an operating system that operates in real-time and user code that delivers deterministic execution. Neither deterministic user code on a non-real-time operating system or nondeterministic code on a real-time operating system will result in real-time performance.

    The whole write-up is great and can be found here. All that to say, when your system needs real-time performance, it needs it. Bobble-Bot provides a safe way to learn more about this classification of systems at low cost. This is not an easy feat because typical real-time controller implementations are heavily proprietary. The whole subject is both fascinating and practical. We are passionate about sharing our experience here with the larger open-source community, and Bobble-Bot is a great platform for doing that.

    Enough background, let's look at some examples.

    Here's What Non Real-Time Control Looks Like

    The performance is not good. If you look around on the internet you will find many examples of self-balancing hobby robots with performance that's along these lines. Keep in mind, this is the best we were able to get the non real-time Bobble-Bot to perform after many hours of tuning. The bottom line: non deterministic loop jitter (delay) kills performance in a system like this one. When you need real-time execution, you need it.

    Here's What Real-Time Control Looks Like

    In the video below, you are viewing one afternoon's worth of balance control tuning by James and Mike. The difference in performance between non real-time and real-time control is night and day. Watch to the end... it gets better and better.

    Since the day these videos were recorded, we have continued to make performance improvements that enable the Bobble-Bot to do ramps and different surfaces like a pro! This would not be possible without the switch to real-time.

    If you want real-time, why not just use a micro-controller? 

    Having a full Linux OS running ROS makes working with the robot so much easier and more accessible. Being able to wirelessly ssh into the system and poke around is what makes the learning enjoyable. Additionally, ROS has a huge ecosystem of packages that makes it very easy to extend Bobble-Bot's capabilities without having to reinvent the wheel.

  • New Bobble-Bots Coming Soon

    Mike Moore04/16/2019 at 00:27 0 comments

    Two more Bobble-Bots in development!

    These handsome guys are now ready for their electronics and software load! Changes on the CAD side were mainly geared towards improving the assembly process. Significant improvements were also made to the motor assembly. On both the mechanical and electrical side, this version will represent a significant leap forward in making Bobble-Bot plug and play.

    On the software and electronics front, we're expecting the turn-around time to be significantly reduced this time through. Looking forward to making use of our continuous integration/deployment tools to flash the entire software load directly onto the SD cards. For the balance controller, we'll be using the master branch of our open-source controller repository. Results from sim indicate we'll have no trouble with the balance controller. Just a few updates to the control gains were required.

  • Simulation Validation Update

    Mike Moore04/16/2019 at 00:26 0 comments

    Bobble-Bot Validation of Open-Source Sim

    We're wrapping up a considerable effort in the validation of the Bobble-Bot simulation. For our users, this means they can safely assume that navigation, controls, and other software development activities can continue to rely on the open-source Bobble-Bot simulation for their testing. Our software architecture and infrastructure enables rapid deployment to hardware upon success of automated test results performed within the simulation environment.

    The main point of all this is that we now have reliable data to back up the validity of the results produced by the simulation! Some of the highlights of this analysis effort are provided below. 

    Impulse Response Test

    Sample plots

    Full data sets from all validation tests are available upon request.

    We will press on and continue to rely on our simulation to develop additional navigation and guidance routines. These can all be developed and tested using the open-source simulation. We are actively seeking contributors for this effort. SLAM experience would be great. Message us if you'd like to help!

View all 10 project logs

  • 1
    Get going with the balance controller & simulation

    If you're looking to contribute to Bobble-Bot, the easiest and most affordable place to start is the sim. We use the simulator for all of our software development, and you should use it too. We've gone through great effort to validate and build confidence in our simulator. See our GitHub for instructions on how to build the sim from source

    Start with the controller config file. Mess with some of the gains to see their impact on the control performance. Next, try out changes to the mass properties by making changes to the URDF. Do whatever you's simulation...have fun!

  • 2
    Read the CONTRIBUTING guide.

    We welcome contributions to the project. If they are software changes we insist that you follow the rules outlined in our file. Following these steps creates a method to our madness when it comes to software. Most importantly, it allows us to run your changes through a suite of automated software tests that rely on our simulation. The process is key to getting your changes folded in quickly.

  • 3
    Run some test scenarios

    Now that you've got the simulation built and running, it's time to use it to generate some data. The basic steps are provided below, but you can get a whole bunch more detail by visiting here and here.

    source devel/setup.bash
    roslaunch bobble_controllers apply_impulse_force.launch impulse:=-1000 out_file:=~/bobble_workspace/src/bobble_controllers/analysis/impulse_test

     If all goes well, you should see something like this:

View all 8 instructions

Enjoy this project?



matop wrote 08/12/2019 at 19:31 point

Hello, nice project!

Is your robot attitude stable after long use?

  Are you sure? yes | no

Mike Moore wrote 08/15/2019 at 23:33 point

He'll stay continually balancing until he runs out of battery ( maybe 1.5 hrs ).

  Are you sure? yes | no

matop wrote 08/16/2019 at 13:09 point

Nice, your algo are totally robust

  Are you sure? yes | no

Vittorio Loschiavo wrote 06/05/2019 at 19:33 point

I love your project

  Are you sure? yes | no

Mike Moore wrote 06/09/2019 at 21:04 point

I'm glad you like it. Thanks!

  Are you sure? yes | no

Jan wrote 05/13/2019 at 07:36 point

Awesome project. Will follow your progress for sure!

  Are you sure? yes | no

James Holley wrote 05/08/2019 at 02:57 point

What's up @CutterSlade001?  Those are huge inductors...

Bobble Bot is still in the prototyping stage - if you notice between pictures we have different wheel sizes, circuit boards, you name it.  Early on, we were using much bigger motors.  When we started switching around which motors we wanted to use, we put the inductors in there so we didn't have to think as much about changing our motor driver configuration since they would smooth out the current.  We hope that we can finalize the design over the next few months and start optimizing - we will probably remove the inductors electrically (but they look super owesome, so maybe they'll stay on there).

  Are you sure? yes | no

CutterSlade001 wrote 05/07/2019 at 10:10 point

Please tell me, what are the 3 cylindrical objects either side above the wheels? Super caps? Huge inductors? Why? Thanks.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates