#muribot

[moarobotics-blog]

PICxie, Erzielboard, and the future!

So we’ve been hard at work polishing up PICxie for you guys. We’ve ordered everything and now it’s just a matter of waiting until the stuff gets to our building and we can assemble the very first PICxie! The funny thing is the very first thing we’re going to do to it is send it up in a model rocket and make a video out of the process :D.

We also have a bunch of neat demos that will not only be interesting but educational!

Things PICxie can be used for:

Magnetic Field and Gravometric Field surveying

Model Rocket blackbox (Orientation tracking and Altitude logging)

Wireless Server when combined with an ESP8266

Position logging when combined with a GPS module

Autonomous vehicle and UAV controller (Robots anyone?)

and MOAR!

If you like PICxie stay tuned to our blog and twitter tomorrow for a special opportunity to beta test a PICxie of your very own!

This weekend our CEO did another 48hr challenge, that man is a literal monster when it comes to driving himself and just like with PICxie he produced another great product for us to polish up for you to enjoy.

Erzielboard

Erzielen + Breadboard = Erzielboard!

Erzielboard is a business card sized breadboard/development kit combo that allows you to test your ideas where you are!. It’s small 85mmx55mm form factor fits easily on the palm of your hand. The module comes preloaded (as usual!) with Microchips USB bootloader software and you can program it on any OS using Microchips cross-platform MPLabX software. 

There is a breadboard with over 170 tie points, 20 pins from a powerful PIC18F65F94 are provided nearby; as well as 3.3v power and ground rails.

 Main features:

PIC18F65F94 @ 48Mhz

USB Programmable and charged

PCB mounted breadboard for easy prototyping

20 remappable pins for use in your projects!

128x16 pixel LCD screen.

MEMS Speaker and Microphone

Infrared Proximity and Ambient Light detector

Infrared Transmitter & Receiver

4 Super Bright LEDs and a RGB Led

2 Resistive Touch Buttons

MicroSD Card Slot

We don’t have any plans to release Erzielboard anytime soon, but if you’re interested we’d love to know. If there’s enough demand we may devote resources to it.

Thanks for reading!

[moarobotics-blog]

48 Hour Challenge Rules

I’m doing it again this weekend! I’m going to do another 48hr Make It challenge. Last weekend I completed the project in 37 hrs, let’s see if I can beat my record ^_^

I CHALLENGE YOU!!!

This weekend I don’t want to be the only one pushing myself to improve my maker skills. I challenge anyone who reads this to the 48hr Make It challenge!!!

​Project creators must describe the final state of the project prior to starting the challenge. Processes which will take much longer than 48 hours (I.E. 3D printing and PCB services), should noted as well

Projects must achieve this final state within 48 hours

Research can be done up to two hours prior to starting the project, no actual work may take place

After the project starts, the project creator is NOT allowed to change the final description under ANY circumstances.

A project completes the challenge only if the project matches the final state as described by the project creator. In Rule 1. And fails if it breaks any of the rules or is not complete by the 48 hour mark.

[moarobotics-blog]

Kickstarter Cancellation

So this morning we all got together, and we decided it was for the best that we cancel the Muribot Kickstarter. This certainly doesn't mean that the Kickstarter is a failure! We've generated a lot of interest, and we've connected with so many people, and by canceling the Kickstarter we can focus more on generating the kind of PR we need to really launch it.

What happened?!

We gained almost 400 new followers within two weeks averaging 28 new followers per day! However we really should have started gaining a PR following PRIOR to the launch of the Kickstarter, when you have a Muribot in your hands and have actually programmed on it's easy to see just how powerful it can be but we simply were not able to present that to you in a way that gave you guys the confidence that it was a dependable and robust product and we apologize for that.

Another factor that lead to low interest seemed to be our choice to not offer unique rewards up until the higher echelons of the reward system. We really should have offered something, but we were so concerned about ensuring we could actually reward people who chose Muribots, if we'd known they would be in the minority we would have offered a lot of different kinds of rewards. We won't make that mistake again!

What's next? $60 MURIBOTS!

The biggest reason we're canceling the Kickstarter is because of all the amazing feedback we've gotten from everyone! We've gotten feedback from over 200 unique individuals and we really know what you guys want out of a kid friendly platform now. If you read our last post we talk about Muribot 2.0, compared to the $250 Muribot v1.0, costs only $60!! We haven't started that design, but we'll be putting the project up on HackADay.io so you'll be able to follow it's creation from start to finish. 

Too Long; Didn’t Read;

In short, we’re really compelled to cancel because from the feedback we received it’s OBVIOUS that we can make Muribot an even better product, and we simply can’t continue a Kickstarter that would deliver a less than quality product. Once we’ve spent some time making our improvements, we can come back with an even better product!!

Stay tuned for our next post around noon today about something we've been working on we think you'll all like.

[moarobotics-blog]

Muribot 2.0 - The Ultimate Robotics Kit for Kids!

So our project isn’t doing so well, things really aren’t looking good for our Kickstarter. This isn’t a failure though! We’ve learned a lot about the market we’re trying to appeal, and we’ve gotten a lot of amazing feedback and support from you all thank you!

We have tons and tons of interest across the globe. We have a school in Pakistan that is looking to buy a bunch of Muribots, as well as one in the Ukraine. It would be so much easier to actually get these guys their robots if we were successfully funded, but if not it’ll just take a lot longer to fullfill the order for them.

We really want to see Muribot be successful, we really don’t want to cancel our funding goal. We have a lot of enthusiasm but enthusiasm doesn't secure a pledge for you or anyone else.

It’s very doubtful we’ll be able to market Muribot to universities anytime soon, without the ability to freely refine our design, and the equipment to produce those refined versions; which we needed the Kickstarter to acquire. It’s very doubtful we’ll successfully market it in that direction.

However we have kids, and we know what kids are looking for. We already have a great API, and we know its easy for kids to program (https://www.youtube.com/watch?v=u0hnHvp6fsg), so after a lot of brainstorming we’ve refined our design, including what our users really wanted, and improved the design overall to gear it towards kids

Our Kickstarter may not be successful, but that doesn’t mean Muribot won’t be :D it’s a great platform that really can stand on it’s own and we do sell them on our website, so even after the Kickstarter you can still get one if your interested.

Muribot 2.0 - The Ultimate Robotics Kit for Kids!

Infinitely expandable!

If your preferred processor supports I2C you can interface it to Muribot v2.0.

Even longer battery life!

Sensors

3 IR Proximity Detectors

Possible to add up to 5 more!

3 Ambient Light Detectors

2 Line Sensors

6-axis IMU

Infrared Transmitter/Receiver

Muribot is still:

Still USB programmable and rechargeable!

Still crossplatfrom using MPLabX and our software!

This kit only costs ~$60 bucks! 1/4 the price of Muribot currently! If we’d known before what we know now about what our users and the people interested in it want we would have redesigned it prior to our Kickstarter.

So what do you think of Muribot 2.0? Would you buy one for your kids? Use the poll below to let us know

What do you think of Muribot 2.0?

I love it!!

I like it!

$60 is too expensive

Doesn't use ARM/Arduino/etc

Lacking in features

 pollcode.com free polls

[moarobotics-blog]

The 48hr Challenge

Hi everyone, Michael Stone here, some of you MAY have noticed the sudden lack of “HEY BACK OUR KICKSTARTER!” tweets. That’s because on the weekend I run a lot of the social media stuff that I don’t have time to really do in the week. This weekend however I decided I’d put myself to a challenge:

“Take an idea, and make it a reality in no more than 48 hours”

Can I Build It? YES I CAN!

Now there are SOME limitations, I can’t 3D print anything, or get parts from digikey, within 48 hours. So that wasn’t part of the challenge. The main goal was to get a Bill-of-Materials, a set of Gerber files, and a set of STL files for a case.

I decided to take this challenge for a few reasons. Last week if you were watching my Twitter, you may have noticed we were offering to give you a alpha version of a small development module. While this failed to entice any backers to our cause, we actually got a lot of positive response about our PICxie, one person actually said he would back a Kickstarter for PICxie but not Muribot! 

We found that very humours, because PICxie Alpha was simply a disembodied Muribot brain :)

We actually got so much e-mail about it (over 230 e-mals and messages!)...that at the end of the day on friday we decided that if we could very quickly shift that into something resembling a real product we could totally Kickstart, we never got that sort of response with Muribot

Not a single e-mail about Muribot...maybe we should have Kickstarted PICxie instead!!!

So if you have any questions, comments, feature requests, etc for PICxie or Muribot please send them to [email protected] and we’ll get back to you ASAP.

[moarobotics-blog]

BIG NEWS! - Muribot - Now ARM/Raspi/Arduino/etc compatible!

So after a lot of testing, we’re proud to announce tha Muribot is 100% compatible with ARM, Raspbery Pi, Arduino, and many more! Basically if your hardware’s got I2C, you can connect and run our platform with it.

We have a 3D printed bracket that we will be making available for you to download and print, and we will sell them for <$10-15 (not sure on the price quite yet but we think that’s a good estimate). You can use this bracket to secure an Arduino shield to our platform, and connect I2C and power (3.3v and 5v available!)

This is REALLY BIG news in our opinion, it opens up our platform to a whole slew new range of possibilities, we’re honestly surprised it took our backers to point out that this was possible! We’ve been marketing this all wrong!! :D

[moarobotics-blog]

Muribot API - Concurrency, Reenterancy, and Semi-Non-Blocking!

So we were asked an AWESOME question about our API on Reddit, we though it was so good and had so much fun answering it we thought we’d post it!

Q.  Can you share more details about the embedded software API, and especially how does it deal with complex stuff like concurrency, reentrancy, and non-blocking , while keeping everything simple ?

Wow this is a nice technical question! When we were writing the API we actually thought a lot about this, the PIC is a single threaded platform by nature, but it's possible to implement a sort of pseudo-multithreading on the architecture very easily. We actually implement a very simple block multithreading model. On the PIC18F hardware we actually have 2 interrupt priority levels, so you can almost think of it as being 3 threads.

The thread 0 is the main loop being clocked from the 48MHz system clock. Thread 1 runs is the low priority interrupt and it runs at 10Hz. A human normally responds to stimuli within 200-250mS, so we wanted an update speed that was similar, as our CEO does a lot of research into AI and autonomous navigation. Thread 2 is the high priority interrupt and runs at 1000Hz. It simply updates a counter we use to track the passage of time (in mS).

Thread 0 - User Thread Thread 1 - Sensor Thread Thread 2 - Clocking Thread

The ReadRam and WriteRam commands are the only commands that completely block the execution of the platform , simply because it hogs the I2C bus and we don't want to be writing spurious data. When other commands that need to block execution are issued, they block execution of the user code only. e.g. Move will only block when a distance or delay is given otherwise it returns immediately, and Turn will block until it turns the given angle. When a block occurs thread control is passed to Thread 1, so that the sensor data can be continuously monitored until the set time, distance, or angle has been reached.

The clocking thread doesn't affect code execution in any way, so doesn't block anything.

So lets take the following code for run through!:

if(GetDist(0) > 200) // If we get a value > 200 (about 3") from proximity sensor 0      Turn(15, 100, 0); // Turn 15 degrees at 100% full speed, with no wheel bias (turn in place)   else      Move(50, 50); // Move forward at 50% full speed  

First, GetDist(0), which simply returns the value read from the sensor during the last sensor update

Turn(15, 100, 0) will block, but during that time the sensors thread is still running, so once the robot

detect is has turned >= 15 degrees it will stop and return.

Move(50, 50) will return immediately however because it doesn't have a delay or distance specified.

The user code then loops until the robot is turned of our an EndProg() command is issued which would halt execution of the platform. The code above results in a robot that drives forward at 50% speed until something is within 3" of proximity sensor 0 and then rotate until it is out of sight before proceeding (ignoring blind spots in the sensor view).

The following code was actually written by our CEOs 8 year old daughter Sabrina, IR Line Following Demo by Sabrina S., who discovered you can follow lines using nothing but the proximity sensors.

I hope this answers your questions! Let me know if I missed anything or if you have any questions. There are plenty of little tricks to using the API to get around what might seem like a limitation, so if I can expand on any you might see, let me know!

TLDR;

Concurrency - We use a simple block multithreading model where the user thread passes control to the sensor thread.

Reentrancy - The PIC hardware stack is designed with two priority interrupts that perform context saving by default, so reentrancy was automatic.

Non-blocking - Sensor updates are never blocked, and user code is only blocked when you'd be waiting for something to finish anyway.

[moarobotics-blog]

WOW! Microchip Technology loves us!

So this is happening!!

Holy expletives! This is so awesome, I’ve always love their company and to see them get behind my project makes me incredibly happy! But WAIT! There’s MOAR!

Muribot is going to be featured in the June edition of Microchip’s MicroSolutions magazine!!!!

http://www.microchip.com/pagehandler/en-us/microsolutions

I’m so happy and humbled they support Muribot, I spent a lot of time choosing between Atmel (too similar to really justify the switch), and ARM (a sledge-hammer to crack a peanut) and Microchip to figure out which one would give me the capacities I needed. Microchip proved to me again that they’re the real leaders with microprocessors because the PIC18F46J50 is a perfect fit.

So if you didn't already have enough of a reason before a Fortune 500 company got behind our project (And backed it!) now is the time! Come grab a slice of the robotics revolution, and you can receive your own Muribot to boot!

http://kck.st/1c1V3Bu

Also!

Today until 5pm, we're having a special offer. The first 5 people to pledge $50-99 and everybody that pledges $100 or more gets one of our currently unreleased PICxies!

Free early release hardware, robotics, and you get to help kids learn about coding and robotics? How could this not sound like a great thing to get behind. Join Microchip Technology and MOARobotics in making an impact in STEM education.