#moar robotics

[moarobotics-blog]

GitHub

In an effort to contribute our hard work back to the community, we'll be posting all the software we can on our GitHub. Today we posted our first repository, which is the firmware loaded onto the encoder module and handles the dual quadrature encoders present on the robot. Take a look at it (if you're interested that is) here:

https://github.com/MOARobotics/MuribotEncoderFW

[moarobotics-blog]

The BIG UPDATE!

Man have I been busy! It's been about a month, and it's almost time for me to start with the endless video posts! This weekend I will be posting videos of Muribot, you guys will get a first hand glance at programming it, the library, and a few applications I've made.

The prototype has really done me well even with its silly little bugs. The latest PCB revision is just waiting to be sent to the manufacturer, and I'm just waiting to have enough disposable income to send it in. Bills before bots, as I always say (or at least I do now). As for our current bugs in case you're interested:

PWM - Unable to use Full-Bridge mode because the lack of pull-up and pull-down resistors on the bridge lets shoot through occur. Honestly this was just pure laziness on my part since I knew it was a possibility but wanted to keep part counts low. $1 worth of parts is all it would have took, a mistake I won't be making in the future.

Electrical Noise - Lack of filter capacitors, this wasn't really a bug per se, I allowed this one so that I could gauge the noise levels with my oscilloscope. A couple of surface mount electrolytic capacitors will be sufficient. Its actually fun to watch the sensors be all noisy and then add the capacitor and watch it clear right up.

Encoder Firmware - I wrote the encoder firmware in a different IDE than MPLab, when I initially tested it it seems to work fine, but hangs up the I2C line in application. I plan to rewrite that firmware in MPLab which should allow me to cross this one off the list.

The case is getting a redesign. We're going to ditch the trim pieces since the RGB LEDs light up the white case beautifully. The new design will also conform around the IR/Light sensors so they see as little of the case as possible. I'm also thinking about trading the laser cut mylar sheet that covers the bottom for an actual bottom mating piece for the case. That mylar sheet costs $12-15 and it would be cheaper to go with the 3D printed piece, especially since a couple 3D printers are what your donations willl be helping us get in our kickstarter.

The library for Muribot has been so fun to write. You simply drag and drop the library files into your project folder. Edit Program.c with your own code, and watch Muribot do the rest. My girls don't know how to program, but they can describe what they want the robot to do, and with commands we have a lot of fun; even though they're a bit younger than the age range I'm targeting.

I've been initially doing software PWM but recently discovered how to properly remap the PWM pins. The only problem? 2 outputs for the left motor, are not part of that remapping feature. The new PCB revision switches the line sensors and those two outputs. The new design will allow extremely fine control of the wheel speed.

Battery life has exceeded ALL expectations...if you remember from this post I estimated the Muribot to have approximately 2 hours of run time. Well this turns out to be more like 6-7 hours. This is really awesome, now for a 2 hour charge you get a lot of use out of the thing. The charging circuitry has proven to be the most robust part in my personal opinion. I've always used external chargers for my batteries, being able to build that into my application adds a lot of freedom. This also opens up the possibility for further miniaturization. I'm always looking to pack more punch into a tinier package, and currently battery size is the biggest determining factor for size, second only to the motors. 

The Kickstarter draft is being reviewed by some early bird backers! I want to make sure that my plan sounds good and right up front you know EXACTLY what you get out of the project and EXACTLY what your money will be used for. To this end I've spoken with a accountant and my bank about manufacturing costs, distribution, etc; and so far it's been nothing but "if you have a plan like this why not just get a business loan?". I would rather work directly with my customers and cut out the interest laden middle man, 

That's it for now, be sure to check back this weekend for some videos, once we have those we can create the Kickstarter video and finally launch this candle! Have any ideas for a demo YOU would like to see? Click the "Ask a Robot" button to the right and let me know ASAP! I'll include your demo in the video if it's a neat idea and I have the time to write the code.

[moarobotics-blog]

Spinning in Place

I feel kind of stuck on the kickstarter project since I need a video before I make the project, and I can't get funding until I make the project. Work is definitely kicking my but, we started with 5 technicians and now we're down to 2, so if we can't get any more technicians the project is going to be put on hold. Luckily I'm Post Support so I've been able to put in a couple of full weeks, once I get enough for a decent digital camcorder, there will be some decent videos of MINIMouse V1.0 appearing on here.

While I wait to get paid, I've been sampling different gyroscopes, I still like the ADXRS613 the best thus far. The 150°/s resolution is my only real complaint since the GM8 Gearmotors on V1 easily can send it off-scale high. V2.0 I plan to use the GM2 Gearmotors and a gyro with 300°/s resolution to keep it within scale.

ADRXS613 Sensor Data on a Graph

This ADXRS613 has an angular drift of 6°/hr and a bias of 2°/s or so. To correct for these factors, we initially take a running average to determine a suitable bias. Then after we have the bias we subtract that from our sensor readings, these readings are also put through a running average to reduce noise. The final value we get is still just a raw value and must be converted to °/s.

To find the conversion factor, we simply take half of our ADC range (511) and divide it by our sensors resolution (150), this gives us 3.41. You can then take the ADC result, and divide it by 3.41 and subtract 150 to get the value in °/s.

(0 / 3.41) - 150 = -150°/s (511 / 3.41) - 150 = 0°/s (1023 / 3.41) - 150 = 150°/s

With microcontrollers it can be useful to convert this math into integer math. This is easily done by scaling the conversion factor and ADC result by a value that makes the conversion factor an integer. To make things simpler we can also round the conversion factor down to 3.4, this gives us a scaling factor of 10. Our conversion factor is now 34:

((0 * 10)/34) - 150 = -150°/s ((511 * 10)/34) - 150 = 0.29°/s ((1023 * 10)/34) - 150 = 150.88°/s

While not perfect, this allows us to completely avoid nasty floating point math which hogs CPU time and program memory.