Embodied Is Actually Trying To Release ‘Moxie’ Robots To The Open Source Community
from the actually-doing-it dept
A couple of weeks back, we discussed the implosion of startup company Embodied and the resulting bricking of its $800 “emotional support” robots designed for children. Like many other stories about IoT-type products, the post focused on how these robots would cease functioning as designed once the backend support infrastructure for the shuttered business was shut down. As often happens with stories like this, there were several comments pointing out that the company could publish its source code and allow an open source community to pick up the slack here, so that at least these robots wouldn’t become $800 paperweights.
But what doesn’t typically happen in these stories is seeing a company actually make the effort to do exactly that. But that seems to be what Embodied is planning, with the company announcing an update and a plan to all the open source community to build its own backend software for the devices.
Embodied CEO Paolo Pirjanian shared a document via a LinkedIn blog post today saying that people who used to be part of Embodied’s technical team are developing a “potential” and open source way to keep Moxies running. The document reads:
“This initiative involves developing a local server application (‘OpenMoxie’) that you can run on your own computer. Once available, this community-driven option will enable you (or technically inclined individuals) to maintain Moxie’s basic functionality, develop new features, and modify her capabilities to better suit your needs—without reliance on Embodied’s cloud servers.”
The notice says that after releasing OpenMoxie, Embodied plans to release “all necessary code and documentation” for developers and users.
The company is also pushing a final update to the devices that will allow them to support the OpenMoxie setup.
Now, all of this certainly isn’t a perfect solution. If people miss getting the update, their robots will still end being bricks. There is no committment from anyone at all that the open-sourced code and OpenMoxie are going to be dutifully maintained. And who knows what the quality of OpenMoxie will be compared with what the company itself had been providing.
Still, this isn’t an ideal solution for parents who invested in an emotional support toy for their kid and may not have the know-how or time to keep it alive after Embodied closes. While Embodied is doing better than other firms that have bricked or otherwise changed smart device capabilities after release, it remains a disappointing and possibly illegal trend among tech companies pushing products only to alter their functionality or stop supporting their software after taking people’s money.
But at least Embodied is trying to do something about all of this. As the quote above notes, that’s a far cry from what has happened in plenty of other cases, where customers simply get cut off from the functionality of the thing they thought they bought, without any real concern from the companies doing the cutting.
As I said in the previous post, the better solution in the long run would be some sort of consumer protection laws. While we wait for that to probably never come to be, however, this is at least a good step in the right direction by the folks at Embodied.
Filed Under: autism, moxie, open source, robots
Companies: embodied
Comments on “Embodied Is Actually Trying To Release ‘Moxie’ Robots To The Open Source Community”
Better solution
The better solution would be to stop putting everything in the cloud, and run it locally. Yes, for the moment it’s sometimes too expensive to put sufficient computing power in every device, but that will change soon.
Re: Bollocks
So instead of one cloud service configured to handle them all you have a server per robot.
Tell me you don’t work in IT without telling me you don’t work in IT.
Re: Re:
No, they’re saying that there needn’t be any servers at all. Just put the hardware in the robot to begin with.
“One server per robot” is the solution the company is proposing.
Re: Re: Re:
If you remove “Internet” from an “Internet of Thing” thing, you’ve got a $40 Furby, not a $800 toy.
Re: Re: Re:
We’ve come full circle to ” Tell me you don’t work in IT without telling me you don’t work in IT.”
Re: Re: Re:2
In what way?
Setting up your systems as server-client has value in some scenarios, but this doesn’t strongly speak to any of them. Potential advantages lie in areas where:
Local hardware would, of course, have increased the price they charged for their product. But the whole reason this is being talked about is that they’re bankrupt, so we know for a fact a higher price was always necessary. Perhaps there is an intermediate price point that would have sustained a server-based model at a cheaper rate, or perhaps not. None of us know, regardless of how much you brag about your IT chops.
Re: Re: Re:
You do know the robots in this case are software, right? Where in software do you propose hardware be put?
Re: Re: Re:2
No, the robots are robots. They’re a torso about 2 feet tall, come in bright colors, have movable arms and head, and a face screen which displays a pretty standard “cute” face (big eyes, exagerated eyebows, no nose) which can show variable expressions and some basic lip-sync when speaking.
Re: Re: Re:3
Yeah, AC clearly skim-read the post, if they read it at all.
Re: Re:
I’m sure that many ignorant newbies think that cloud computing is the answer to every distributed computing problem. My dear child, those of us who were building this network while you were shitting in your diaper know better, and perhaps, if you read copiously and study extensively, you’ll be able to learn from us.
Re: Re: Re:
Most of what I’ve learned from the old-timers is that they’re stuck in their ways and will work tirelessly on something that will never work because it’s how they did things back in the day.
Re: Re: Re:2 You'll be an old-timer one day
One day you’ll suddenly realise you’ve become an old-timer when you recognise that whatever the current trend on the client/server vs local rainbow is, that you’ve seen it all before.
IT infrastructure has been cruising back and forth on this rainbow or pendulum swing for decades. And at every stage you’ll have people claiming the ‘other end of the swing’ is the right solution. It never is.
You want the local power & flexibility of smart devices, sure, but you also want the flexibility of shared services & data migratability. (Commercially, you want a bit of control & subscription-based goodness too, but let’s keep that bit quiet for now).
You might even be able to leverage having some of the more difficult computing work (let’s say, AI language processing for the current trendiness) done on a large remote server. Next generation will move that back to the local device… but there’ll always be the next-next-gen need to push something central again.
Yes, old-timers know what they know, and they often like to stick to what they know, but that’s often because they’ve seen everything else and know what they know is better for the problems they are trying to solve. (Though they may be wrong about the problems you are trying to solve)
Re:
It’s not too expensive to put sufficient computing power in consumer devices. They already have sufficient computing power. The problem is that everybody writes code as if it’s going to run on a cloud server, so they stopped caring about speed, memory or disk usage.
When the problem is devs not targeting for the performance of the hardware, that’s not going to be solved by better hardware – it’s just going to kick the can a bit further down the road.
Re: Re:
Some things are actually too complex to run that way. The cutting edge of humanity’s best attempts at AI are one of those things.
So IF they can do that, that’s awesome. However it is fairly likely some of the ICs, ASICs, etc[0] used in their product has critical docs under NDA. And the reality is: attempting to maintain a piece of hardware without detailed and correct documentation is orders of magnitude harder than if you have access to the docs.
Hopefully that’s not the case, but in my experience building a product like that without using parts that require NDAs requires careful planning and intent.
[0] I have no specific knowledge of what hardware they used.
Re:
They also have to convince their (other) creditors that the consumer liability risk of not open-sourcing the robots is greater than the likely value of selling the IP at auction.
Re: Re:
All they really have to do is prepare some wanted posters for their creditors’ CEOs.
Re: Re:
They also have to convince their (other) creditors that the consumer liability risk of not open-sourcing the robots is greater than the likely value of selling the IP at auction.
What value? They’re already on really shaky ground as is with the original announcement that a product that parents got for their kids to help them was going to be bricked, if they tried to just ignore that and sell the thing off it would be the equivalent of selling toxic waste, no-one sane would want to touch it and good luck getting parents to buy in a second time after such a disastrous first launch.
Re: Re: Re:
Mostly good points, however this overlooks that the “worthless/bricked” thing is what the customers have, while the “IP” to be sold would be the source code, design files and w/e FOR that hardware.
Any even if we consider it “bunk” (because it can not, currently, survived without an active tethered to the parent company) IP holder ALWAYS believe their IP is valuable. And there will a always be someone out there willing to pay for an IP that’s being sold.
Well, credit where it’s due I suppose, they are trying to make this right rather than just dumping a bricked product on the screwed customers with an ‘Oops, guess it’s your problem now.’
No normal “consumer protection law” is going to help you. If the company the law makes responsible for operating the system is bankrupt, the system isn’t going to get run, period. Are you going to enslave the staff?
An effective law would have to require a huge trust fund or something. Which would mean that kind of cloud dependent product would never exist in the first place. Which may actually be the right outcome, but probably isn’t the outcome you have in mind.
The bottom line is that things on somebody else’s computer just aren’t reliable, period.