MOARbots Path Visualizations

A MOARbots volunteer (Scott) made some python visualizations for the data stored from the multiple waypoint navigation competition.

Each path comes from a different (completely or slightly) piece of code running on the robot. The waypoints are the large gray circles, and are always in these same pattern, though sometimes the board was rotated (the tags were physically taped to it).

You can see the curve of the path segments in robots that did not account for the differences in output wheel speed relative to PWM (pulse-width modulation) value between the left and right motors. The actual physical robots were not the same between all these runs (the number at the top is just the robot ID tag which is removable). They all curve left because the right hand wheel motor is in the bias direction when moving forward, but the left hand wheel motor is in the anti-bias direction.

The target is considered reached if the robot's tag center point is within 20 units (pixels, but our camera never moves) of the goal point tag center. The score is computed as such:

Score = 120 - t + 25*n
t: time elapsed in seconds since trial started
n: number of waypoints visited
Total number of waypoints: 5
Trial ends if the score reaches zero

The maximum score is therefore 245, for a theoretical 'teleporting' robot.

The competition can be summed up by the two key challenges: (1) Figuring out how to drive quickly towards a single waypoint without overshooting the goal, and (2) Computing the shortest path given the locations of the goals and the robot start position.

 The robot in the above visualization did a little too much zig zagging. It also didn't compute the best path.

The robot in the above visualization correctly figured out the minimum length path given the tag locations and robot start position.

MOARbots update

MOARbots is now on github: https://github.com/MOARbots/

Here's a video of one of the waypoint navigation routines that have come out of the UW independent study.

What's next? Yet another revision to the parts list. The new MOARbots will be based around the Teensy and the ESP8266. Using the ESP8266 by itself (with something like this board) is still on the table but will have to wait a bit. Using the Teensy has the advantage of being able to make them into Teensyduinos. The Arduino programming language/environment is easy to use compared to writing in C. And, if I'm willing to wait a bit, the hobbyist community will develop the tools I need for the ESP8266. Take a look at this project, for example: https://github.com/nodemcu/nodemcu-firmware/

One of the most important things that has happened to MOARbots recently is the expansion of the team of volunteers working on it. Thanks to the Sector 67 community and the University of Wisconsin community, MOARbots is now more than just my own personal project.

Lastly, here's a teaser of one more cool direction MOARbots might take:

This $50 quadcopter...
http://www.amazon.com/Hero-RC-Matrix-Quadcopter-Battery/dp/9269802574

...plus this $40 3-axis gyroscope, 3-axis accelerometer, and on-board processor...
https://www.sparkfun.com/products/11028

...plus this github project to help free that device from the small-mindedness of the company that made it and then decided to make their code closed-source...
https://github.com/jrowberg/i2cdevlib/tree/master/Arduino/MPU6050

...plus April Tags and MOARbots.

A swarm of Wi-Fi connected autonomous self-stabilizing quadcopter at under $150 per quadcopter? I'm hoping it's possible, anyway!

Regear successful

Last post I realized that I needed to redesign the gearbox for my most recent set of robots. I added a compound gear. This brought the overall ratio of the gear system to 30:1. I also switched batteries, to reduce weight, going from a 113 gram battery down to a 46 gram one. I got rid of a few other parts too (acrylic panel and standoffs that created a battery bay which was not needed for the smaller battery).

The motors don't overheat now. Since the motor output shaft moves faster, there was more electrical noise on the system, and I had to add the ferrite chokes (otherwise, the Wixel locks up).

Here's a video demonstrating the new design in a simple mechanical/electrical test.

Below is another video, showing a simple pre-determined routine (no sensors). This was coded by some of the people participating in the independent study.

More MOARbots

The 5 'models' of MOARbot that I've made so far. MOARbots doesn't really come in 'models' so I put that word in quotes. Overall the above robots represent my exploration of a bunch of different design elements. MOARbots as a project is just the framework/resources/suggestions one might need to pick and choose their own elements and make their own set.

When I have a need to create a set of robots though (for AI control, remote control games, whatever else), I do tend to want them to all be identical. So then I'll refine one design, and print out n  many more. In that sense it has become convenient to refer to the designs as 'models.'

"Big Cart"
Above is the very first MOARbot. I sourced parts to make a full set of seven identical robots like this one. The motors are the very beefy RS-385SH by Mabuchi. These are geared with just a 3:1 ratio (I tried a 2:1 but with the battery weight, the thing stalled too easily). As a result it is very zippy. Notice the black marks on the rubber band tire--some Sector 67 members had fun driving this thing around quite a bit. Heat sink is definitely necessary. The stall current of each motor is 4 amps, which means that at full stall they will burn out the motor driver, which is spec'd at 4 amps total for both motor channels. The proper solution would be to use the current sensing pins to stop the motors when they draw too much current. The quick-fix solution I implemented at the time was to remind all the drivers that they should hit the brake key every time the robot ran into something.

"Omni Prototype 1"
This is the first omniwheel MOARbot prototype. It used 4 unknown motors pulled out of a bin. The omniwheel black and red 'beads' were spray coated with some products to make them more tacky, but that ultimately did not provide enough traction. A quick test showed moving a pair of motors took about 4 amps continuous current draw. The wheels slipped a lot on most surfaces as well. I came up with a much better design right after, but haven't yet finished work on that project (very very close though).

"Small Cart"
This is the smallest design so far. The motors were pulled from a bin, and only one worked. The robot was successfully able to drive in circles with 2 AA batteries (alkaline). This convinced me to try some smaller motors for similarly sized robots. If I were to go smaller than this, I'd switch away from 3D printed gears altogether and use rubber belts (like this robot that uses them with little CD drive motors). A robot like that could be built without any 3d printed parts, which would be appealing those who don't have access to 3d printing. A MOARbots project to source the parts for and build a set of those will happen most likely this year.

"Bumper Cart"
This is part of a set of 4 robots built around the FK-180SH. They are meant for playing remote controlled bumper cars, MarioKart style. The green pair of switches on the left are the target, and the acrylic panel on the left is the front of the robot. Robots race around the arena trying to hit the other robots' targets. After n hits to your target, your robot is out of the game (stops in its tracks) until the game is over and the players all agree to hit the reset button on their controllers. A pair of LEDs can be used to indicate robot 'health.' Why only 2? There are only 2 'high current' (20mA) output pins on the Wixel, and that breadboard was getting too crowded for me to start adding in some transistors.
Unfortunately the bumper carts did have one minor issue--for reasons not yet determined, the cart couldn't actually move under its own weight with the full circuit hooked up, but could move when the batteries were connected directly to the motor terminals instead. I will have to do some science to it, but I bet putting a nicer battery (2 or 3 cell lithium polymers) will fix the problem.

One cool but not completely necessary feature of the bot above and the bot below is a disconnect-able breadboard. The breadboard sits on top of three standoffs, and is held in place by magnets. The motor and battery leads are long enough to allow the breadboard to be moved around. I like this system because it means I can work on the circuit without risking pushing down too hard on the robot frame (this is mostly a fear because the diodes I bought have very thick leads and the required force to insert them into the breadboard is high).

"Independent Study Cart"
This is the cart I just finished for an independent study I'm leading at the university. The key point of this design is to use the small, cheap, and ubiquitous "130" sized motors, like this one, though you can get them cheaper on eBay if you buy in bulk from China. Knowing that these motors would be a lot less powerful than the previous ones I had used, I needed to stick as many teeth as possible on the wheel. To do that without pushing my luck on 3D printer resolution and gear alignment issues, I made the gear ring as large as possible, so now the spokes are actually on the inside of the gear. The results are good, in terms of having big safety margins on gear alignment and robot pushing force. I put a very heavy 2,200 mAh  battery pack on it and it moved quite well. I will probably source significantly lighter batteries for next week's order of remaining parts.

Now I just have to source the parts for 9 more, and work out nicer battery compartments, wiring harnesses, and ID tag standoffs for this bot. Then there is also some code I need to clean up and finish up. I'm pretty excited to see this project move to the next step finally! Though I will be playing around with new omniwheel and belt-driven robots eventually, for the next window of time my focus will be entirely on the robot brains (code and algorithms) side of things.

MOARbots Bumper cars

I didn't quite get around to finishing the setup for four of the bot pictured above plus code. I had planned to get them done before I left town but holiday gift season got in the way of that. I ran into some issues at 4 AM and then realized it is 4AM and I have not a lot of time left before I have to be packed and headed to the airport. Until 'next year' then.

First set of MOARbots

The first set of MOARbots are coming together. Pictured above are the 4 cart bodies in this set. I will be assembling them before I leave for the holidays, so that Sector 67 can bring them to Saturday Science. They won't be doing anything fancy; the game is human-controlled bumper cars. The setup:

• 4 USB game controllers
• 1 transmitter wixel
• 1 receiver wixel per robot
• 6 or so red LED 'damage' indicators per robot
• Some limit switches and wire bumpers
• A modular set of acrylic arena walls, hinged with duct tape, and with holes for snapping the supports into it (to keep the robots from ramming down the wall)

The game works as follows: Control (joystick) data gets sent out from each controller to each robot (if the controllers don't switch USB slots, it ought to be possible to color code the controllers to the corresponding robots). Each robot starts with full health, so no damage indicators are on. Each time the rear bumper gets hit (note the rear is the side with the marble) all the LEDs flash and the robot is in "invulnerable" mode. After "invulnerable" mode the LEDs light up to reflect how much total damage the robot has suffered since the round started. If all the LEDs light up, the robot enters a slow blink mode and stops moving, regardless of controller input. The supervisor (the person sitting at the computer that ties this all together) can hit a key at the Python script to reset the game. This sends a reset signal to all robots, who reset their damage indicators and start anew.

This game was designed specifically to allow one way communication only (controller computer to robots only), and to not involve the webcam.

Upcoming posts are expected to be MOARbots and holiday season related. Happy Hannukah and so on.

Mini Cart / Build Madison

Build Madison is almost over, so I get to sleep soon. I found a helper for the mini cart project, a design which will also be part of the MOARbots framework. The mini cart has immediate appeal--it can use cheaper motors and batteries, and more can fit in the arena for large multi-robot events.

Here is the mini cart alongside the regular cart.

The mini cart motors were pulled from a misc. motors bin, so they aren't exactly the same. Also, one
of them had been previously used and wasn't in good condition, so this prototype really only can turn one wheel on. The point however was to prove that it is possible to use el-cheapo small toy motors, with 3d printed gears, to move a cart.

I spent most of my time though working on an omni wheel design. I found some tackier heat shrink in large diameters that works very well for tires. Other than the tires and axles (small finishing nails), everything else is 3d printed. The triangular shape allows for two halves to fit together snugly to form the final wheel assembly. This design has very little room for error, which especially problematic given the variance on prints. A redesign should be coming soon.

One more thing: the MOARbots project has a wiki now. It is minimally populated but it will be growing A LOT especially as I get ready for a set of UW students who will be working on this project for independent study credits. I'll link it often in the future as well. https://sites.google.com/site/moarbots/home

MOARbots, the ESP8266, and more omniwheels

This project finally has a title.

MOARbots: Modular, Open-Source, Affordable Robots.

Progress on MOARbots is as follows:

I learned about the ESP8266 through Hackaday and decided to purchase a few. It is a $5 WiFi chip and programmable microcontroller to boot. I haven't been through the recently translated datasheet yet, but it seems to clock at 80MHz and have 16 GPIO pins, 2 of which are broken out on the boards I purchased. It will require tons of development to be usable for MOARbots but the community is very interested in it to make Internet of Things happen at a low cost point, so I won't be alone.

I decided to make a micromini version of my omniwheel bot, based around three Pololu motors I got for free. The motors are far too expensive at $15 to be part of the framework's suggested bill of materials, but for now this is a good project to test out my designs for small 3d printed omniwheels. I'm working through some designs, and here's a render of iteration #1.

Hand forming steel wire made sense for circles, but not squares. I didn't want to take the better part of a month to build a CNC wireformer type machine, or to bother making simpler hand jigs for preset sizes or shapes, so I've rethought the design and will aim to use small finishing nails, which are cheap and widely available and don't need to be formed.

After the monthly Sector 67 meeting, a few people test drove the 2-wheeled cart. Despite the very simplistic control scheme (pre-programmed forward, left, right, stop routines), users were able to drive the cart pretty smoothly, even getting interesting drifting action at top speeds. The battery was barely drained even after a solid 20 minutes of driving, and with the addition of a heat sink the L298 motor driver was doing just fine (the heat sink is very necessary though). So this iteration of the cart is a success I think, and I will just need to buy some more L298s before I have everything I need to assemble 6 more.