Moorebot Scout – Promises and Facts

It is a known fact that you need to take Kickstarter promises with a grain of salt, as it may come to changes during the production. However, if there is a campaign that promised features not only on Kickstarter, but also on multiple more occasions, as for example the CES (see here, here or here), the backer should be able to assume, that the design is sound and was tested with prototypes. There also are rules on Kickstarter that prototype videos need to show an actual, working prototype and not some kind of renders or staged scenes – and the project video on the Kickstarter campaign shows features working that absolutely do not (that is another example of Kickstarter ignoring their own rules, to get their share of campaign money, especially with promising and/or popular campaigns that ere expected to generate a lot of income).

But if we have a look at the Moorebot Scout campaign it becomes obvious that the finished product underperforms in a lot of ways – and almost all of the promised features are missing. Colin Campbell was so kind to collect a list of promises and what was actually delivered – and it does no look good:

That is not only single features missing, that is almost all of them missing.

I was contacted by the Moorebot Scout people and they offered me a refund, which I so far refused. One reason was that they promised to solve some of the problems with further development and software.

However:

Regarding the missing SLAM: They are not even working on that anymore, as they wrote in an email to another backer, they want “the community” to create that. Which I find very bold, since it is one of the features promised in the Kickstarter – and documentation to do that is nearly nonexistent (and you would need to be able to code in C++).

They also wrote in an email to me they have concerns that the SLAM will generate too much heat. The robot at this time only runs on two of the four cores of the CPU because of these heat problems and  they have concerns because of that heat generation when it comes to some backers letting their kids playing with the Scout. So we are running a robot that only uses half of his promised CPU capabilities. From their emails:

It has a full SVO SLAM that can run on this platform. Just not qualified for the product yet. A lot of backers let their kids play with Scout. We are very concerned about the heat issue.

From another subsequent mail:

The heat. The current firmware uses a little more than 2 CPU cores. The heat is within the acceptable range. However, if running to close to 4 CPUs, it can get quite hot, especially if some backers let the kids play with it. That was the concern.

I suggested to create two firmwares. One for people that only use the Scout as a toy for their kids and one version for developers or more tech-inclined people. It is not acceptable that they switch off functionality for all users because a few of them let their kids play with Scout, discriminating all the other backers. I did not get any answer on that obvious solution.

You can buy the Scout on the shop website, there and on Amazon they have removed almost every feature from the product description, well knowing that the Scout cannot do most of the things promised on the Kickstarter. But without these features the Scout is only an overglorified, overpriced rolling camera you can control via a cell phone – and that only if the WiFi connection does not break, which it still does quite often, even with stable and strong local WiFi.

And be aware of the fact that the “patrol” feature does not work at all. Scout rolls off his charger and immediately looses track of where he is and starts bumping into obstacles. He does not follow the programmed course and he is not able to get back to his charger, because he immediately gets completely lost. I see no way this can be solved without at least some kind of mapping, because the main reason seem to be the Mecanum Omniwheels, which may look cool, but lead to a rather inaccurate direction finding.

So if you consider buying one, there may be cheaper products that are actually able to do better than the Scout, you can for example have a look at the Ebo range of robots. Those at least find back to their charger more or less reliable 80% of the time (which is way better than Vector on post 1.6 firmwares, but that is another story).

Update: Aside from the multiple firmwares mentioned above, Moorebot needs an open API and devkits with actually existing documentations to be expanded. A Python SDK should be easy to to, since it already is codeable in Scratch. And also it needs to be able reroute its endpoints to a local server. These are short term goals if Moorebot/Pilot Labs wants third parties to create functionality they are not able to.

Thanks again to Colin for the comparison chart.