Downgrading to Escape Pod 1.0.x: a nightmare

Because I finally found the time to play with Cyb3rvector and am highly amazed by what it can do, I wanted to connect it to Escape Pod. Something like this should have been created by Digital Dream Labs, but they were not able to do that in two years. Instead Cyb3dog did it in mere weeks.

I am especially interested in the Cyb3rvector Escape Pod Extension Proxy, since it would actually enable me to create new functions for Vectors.

But all my tries to connect Cyb3rvector to Escape Pod failed. I was able to push the proxy files to Escape Pod 1.8.2, but after that starting of services only reported failure.

I then after quite some time-consuming tinkering had to learn that Digital Dream Labs changed Escape Pod so much that the proxy will no longer work with it. Sigh. More about what I think about this later, but at least they could have revealed details on what they did, so I could have known these problems and not waste hours of time …

But I really wanted to try out the extension proxy, so I decided to buy an new SD card and install the latest Escape Pod 1.0.x onto it. That was easy enough, but I was not able to connect my designated Escape Pod Vector to it, I always only got “authorization failed”. I then suspected that this does not work because the robot was on Escape Pod firmware 1.8.1.xxxx and that does no longer work with Escape Pod 1.0.x, because that only offers me EP 1.7.x OTAs to install. This incompatibility was later confirmed by Zecred in the Vector Discord. Connection of EP to robot was changed so much, that 1.8 robots cannot connect to EP 1.0.x.

Sigh.

I tried to write the EP 1.7 firmware to that Vector from Escape Pod, but it failed, the error message was something like “downgrade not possible”.

Sigh.

I then decided to do a recovery boot. That resets the robot firmware to an old Anki version, 0.9.0. From there on I reconnected Vector via Bluetooth to Escape Pod (and despite the very old version that worked way better than with the newer DDL firmwares). I then selected the Escape Pod 1.7.x  OTA to install onto the robot. That installation was VERY slow, and I found that curious. After Escape Pod gave me another cryptic error message, I rebooted the robot and again tried to reconnect. And you cannot image my surprise when not EP 1.7.x was installed, but the firmware was shown as latest 1.8.x PROD instead. So Escape Pod actually did NOT install the firmware I wanted, but instead the current production one. What? The? Hell?

At that point it was close to midnight and I was so frustrated by all this senseless wasting of time that I gave up on it. I will probably try to deny internet access for that Vector (suspecting that the update came over the internet before EP had time o install 1.7.x EP) and then again recovery boot him to 0.9.0 and then again try to install EP 1.7.x. But I fear again 1.8 PROD will still find a way to creep onto that robot.

But here are again some words about and to Digital Dream Labs:

1. Provide meaningful changelogs that acually contain information on what you changed in new Escape Pod versions. And I will stress the next one:
2. If you provide an extension engine and encourage people to use it on multiple occasions to create functionality that you are not able to implement, make AT LEAST sure applications that use it are not broken with an Escape Pod update, for heaven’s sake. 
3. If you change someting that breaks said extension engine (which is a very stupid thing to do in the first place), release documentation with the new Escape Pod version, that makes it possible to adapt external applications to work again.
4. Or, even better, either update Escape Pod in a way that does not lead to external applications breaking, OR make the extension engine so stable that it still works despite the changes you make to Escape Pod.
5. Sigh.

I hate to say it, but this “update”, breaking extension engine functions and not providing any meaningful informations and changelogs on Escape Pods is typical for Digital Dream Labs unprofessional project management. If you provide an interface to someting, you do not break it without real reason or informations on how to fix external applications. DDL wants third parties to implement functions that they are not able to create, as they stated multiple times, they even said “okay, we are not able to implement knowledge base and weather, so just do it yourself with the extension engine”. But if you frustrate coders enough with stupid, negligent acts like those outlined above, they will stop to develop the things DDL should.

Because no one likes their time stolen.

p.s.: Sigh!

Update: I was asked if I think Digital Dream Labs intentionally tried to block third party software. That thought also occured to me, but after some thinking I came to the conclusion that the reason “incompetence” is way more probable in my opinion.