You are not alone. It’s no longer in the Android playstore. Yes, only the reachedu app is there. I’ll be keeping a backup too just in case.
I’ll try and install onto my old/spare phone from the apk file to check it works. If so will post the file online somewhere and write a quick “how to”.
While I think of it, just in case anything happens to this forum (likely a case of “when” not “if” really - I think bits of the site are already having certificate expiration issues) you can find me on twitter with the same handle. We can sort out some sort of “alternative/self help/public mekamon info archive” when needed.
For now, I’ve got all 3 “current” apk’s backed up, plus the educational module documentation, and associated repositories and the swift playgrounds archive. Have also got the docs from the FCC site saved.
I don’t know anything about backing apple apps up (or if, with the walled garden, even doing so would help anyone out if they vanish?). Might be worth having a backup of the earlier version(s?) of the main app too (if it was ever released?) I see a different app (dark themed UI) in a lot of the mekamon promo videos - but that one had gone already before I was on the scene.
Something else worth a ponder is how to preserve all the community developed animations… guessing the app talks to a web site somewhere to fetch them. But this would need figuring out.
I can attest to ckalkhof’s eBay battery replacement service. I received 2 batteries that were fixed through the service and both are working. One Mekamon (v1) still flashes red when the battery is fully charged, but that appears to be an issue with the Mekamon himself. The batteries last well over 30 minutes. I haven’t yet tested how long they will work but do plan to do a video showing both the v1 and v2 with the new working batteries.
Rather than do it yourself, I feel like the money spent to get working batteries for these great robots was worth it. I want to thank ckalkhof for providing this service to people.
Yes, while I’m going the DIY route myself (because I’m fairly “up” on batteries), I’d say based even on the effort to get into the packs, it is worth going with ckalkhof’s service.
On the flashing on full charge. I think that might be a V1 vs V2 difference. My friend got a V2 and I don’t think his flashes. But put the same battery in my V1 and it flashes.
I’m not convinced though that the flashing on the V1 is anything to do with battery level. I note that it only flashes when the app isn’t connected. As soon as you make a connection the rear lights are on steady, then return to flashing when you disconnect.
Note that there is a battery indicator on the app in the top right.
IMO, with regards to DIY or availing a service to fix them depends on a few factors:
- can you afford it?
- how many Mekas?
- short-term and long-term
- the main purpose of buying these robots
These factors vary for individuals, so I can only speak for mine.
For convenience, I would go for ckalkhof’s eBay battery replacement service, no question about it.
Consider also if its just a “fad” for you and/or the kids.
If it is, then its only for short-term, please read no further and go with the fix/replacement service.
It will save you time and frustration.
In terms of budget, personally I already over-spent last December. It’s not only for the 6 Mekas but other things in general.
When I bought them, they were priced at $50 (with shipping) and $35 (free shipping).
Now they are going as low as $28 (free shipping). Even with defective batteries, that’s a catch.
I’m pretty tempted still.
So on the practical side, they will cost substantially more for me to get the battery fixed.
On an added note, I also considered the long-term. As I mentioned earlier, li-ion based batteries (li-pos included) will eventually expire (self-discharge, charge cycles) and lose their capacity over time. This is inevitable.
If you happen to be still interested (not a “fad”) on Mekas when the batteries fail, whatever route you take (DIY/fix), you will have to do it again.
I have already considered that in my battery-mod.
Hence I opted to include a battery holder to make it easy for me to swap the batteries.
18650’s are a commodity that makes them cheap and widely available as opposed to the original li-pos used here.
I’m considering 3d printing a custom case in the future to improve the over-all design.
But that’s way down in my to-do list if I somehow get to it.
For knowledge/skill, I’m not an expert, but I’m fairly capable.
I also understand the dangers involved and I take precautions.
This is just another adventure for me.
Understanding everyone is different, it’s not for everybody.
Now for my main purpose of buying these robots, having to play with them is just a cool bonus, I look at them as parts that fit a bigger system/vision.
That’s why I purchased a lot.
The money I saved, makes up for the parts that I need to purchase later.
Anyway, that is just me.
Btw, there is a 3rd option, but I would admonish anybody else to do it.
I have 5/5 of the original batteries revived without opening them.
These were the new but DOA Mekas. IMO, their battery succumbed to self-discharged.
There is a 6th that I didn’t count because this is the I one opened when I studied my battery-mod options.
1/5 likely has a defective BMS since I cannot charge from the OEM charger directly.
But 4/5 so far, I have not any other problems.
Though I know, they will likely have reduced Capacity.
It’s just their nature.
About the battery indicator, I would second or third that the red lights on the rear of the V1 are not an indicator of battery charge. That got me too at first.
I would also check the Mekamon app or the Reach Edu app for it.
On a related note, 5/5 revived batteries are showing full capacity on the app.
This is compared to my battery-mod, where they are only showing about 70-80%.
Note, those are used 18650s too.
The BLE protocol actually advertises the battery charge in terms of millivolts and milliamps.
The battery indicator is computed in percentage based on these values and the difference to the minimum battery level.
The app indicator is not that accurate too though as per other threads in this forum and my experience as well.
New to Mekamon - Amazon Special
Knelf, you read my mind. When I confirmed that the app is missing in the Android Play Store, I was thinking what would be next? the app in the Apple App Store? this forum?
I think it’s another Elephant in the room that we need to address.
I’m all in for your suggestion to have an alternate site and/or sort of semi-archive of this forum.
Btw, about the SSL certificate, unless they renew, this forum’s SSL cert will expire on 3/12/2020. As of now, we have about 38 days until the browser starts to complain it’s validity and depending on your browser may refuse to load any of the site’s content.
For the APKs, thanks for raising the alarm to keep backups. I have mine as well.
Apkpure keeps versions of the old apps (and their own XAPK).
I did some checking for version MekaMon_v2.3.0:
MekaMon v2.3.0 Official OBB (extracted from my Android)
Size: 141100647 bytes (134 MB)
Size: 141100647 bytes (134 MB)
XAPK apparently is just a ZIP archive.
I just used 7-zip to extract the contents.
The hash do match for the original OBB file.
The APK file per se, I will be checking later.
It’s possible to modify APKs file to add malicious code so I’m reluctant to use them as-is until I have analyzed them.
oh well done rave on thinking about the forum cert expirey. TBH I was thinking the digital preservation clock was ticking from the moment I realised the company had died but I will admit to dragging my feat a bit.
On those APKs I’m a little confused. For my own (extracted from my phone) backups I have:
Reach Edu_com.reachrobotics.reachedu.apk Version: 1.1.0 Date: 02/02/2020 Size: 60.5MB SHA1 Hash: dc9243bff4f74c1b8a4168b66adef2cf81efaf4d
MekaMon_com.reachrobotics.mekamon.apk Version: 2.3.0 Date: 02/02/2020 Size: 31.5MB SHA1 Hash: 59958ddad8015c2ea7f2e6313b3fcffdbf610e11
SHA1 Hash calculated using this tool: https://emn178.github.io/online-tools/sha1_checksum.html
edit, on the extraction thing and the potential for malware… I was working on the principle that if the app I used was on the play store… then hopefully google will have checked it isn’t up to any funny business…
Maybe I’m being too optimistic there though!
The one I posted are the related OBB files, not APK. OBBs are application-specific DATA files.
Normally OBB gets re-downloaded when the app detects its missing, however, given that the Mekamon APK installer is already missing in the Play Store, we can’t guarantee that it will still be available for download.
They could remove it as well.
I’m still working on obtaining the original APK files. Android made changes over the years such that the original APK is no longer easily extractable. I have to use an APK Extractor app but I don’t trust that yet.
Can you obtain the SHA1 hashes of your APK files for comparison?
Btw, with regards to my malware comment, yes Google does remove malicious apps, but its always a cat and mouse game. Same case with iOS. No OS is perfect.
Some malicious apps are evasive (a Dr. Jekyl and Mr. Hyde case) such that it takes months for them to be classified as one and eventually be removed. Hopefully, that’s not the case for the Mekamon app.
So far, it’s not being flagged yet so hopefully, that stays.
Btw, I have downloaded all the community/public Mekamotions via the app before. Those are just json files containing base64 encoded blobs of the saved custom motions (joint state control mode).
I will be backing them up just in case.
Thank you very much Miraenda. I’m very glad the batteries worked out for you!
I’ll find out how to do a SHA hash on those files and let you know. EDIT: Added hash to above post
Good work on backing up the community submitted mekamotions (joint state control mode - I see someone else has been busy reading the manual :D). With regard to backup I wonder about restore too? i.e. if “where they came from” goes, how would one go about installing your backed up JSON files? I’ve not actually fetched them all into the app yet… I should do that ASAP really.
About the DATA (OBB) files, so what I’m understanding here is that there is some extra data that gets downloaded after .apk install? In which case yeh, we need that backed up too, and a way to restore.
Fair points on cat and mouse. Ideally they’d detect a nasty apk extractor before they put it on the play store but I guess maybe investigations are retrospective after reports of foul play.
It’s actually not in the manual.
Buried in the OBB are the firmware and the custom animations/mekamotions.
They are no longer retrieved online as I originally thought.
They are extracted from the OBB by the app.
Good thinking of RR. They thought of the customers and remove the web dependencies. This justifies backing up the APK and OBB.
Page 2 of the educational one 1st line.
With the custom OBB containing the animations… does that mean we can no longer create and share animations via the app? So if I went home and made one now, I can’t share it with you? (sorry have to admit I’ve not checked the functionality around making/sharing animations yet - sorta waiting till I have an “on board” battery before having a proper play).
With the APK extraction, was thinking if you use a different extractor to me, and we compare the SHA1 hashes and they are the same. Would it be fair to conclude they are “nasty free”? OK I admit there is a chance that both extractor apps use the same nasty code but I think we are getting into unlikeliness at that stage?
About the firmware in the current app (standard and educational) is it possible to determine what version the firmware is? I’m sort of hoping it is “the same” as the custom firmware embedded in the special apk that turns on the debug mode/USB port. This would be handy.
What I’m thinking is… if, down the line, I try out the USB control, it would be nice if this doesn’t then cause the standard app or the educational app, to keep telling me I have the wrong firmware and wanting to re-flash. This would mean I could experiment with USB stuff but also use the usual games and things in the normal apps (of couse, it could be the special apk has those games too - not tried it yet).
Would be ideal, but I’m not thinking this is likely. I have a feeling the most recent app releases likely have a more up to date version of the firmware than the special apk anyhow.
That said, it might be, the more recent versions of the apps/firmware enable the USB anyhow. The impression I get is that everything was a bit “work in progress” when the special apk was released. To my mind it would have made sense to consolidate everything to work with a single firmware.
I was going to send that info out today with a warning.
The special FW has a version of 2.99 while the standard firmware is 2.18.
The app does check which FW version the connected Meka has. It will only offer upgrade when the version is lower. This means that you cannot revert back to standard once you upgrade. Also, there is some compatibility issue when you use the special FW with the standard app. The Meka would always seem to initialize its leg when idle - a stomping motion.
When the FW and app are matched, it’s back to its normal behavior.
I was looking before on how to cheat the app to downgrade but I stopped since I seem to be the only one with this use-case. Also, I have 6 Mekas so I really intend to have 1 or 2 on the special FW/app.
I have no programming experience, but maybe something in this older post might be helpful-- the post was about refreshing old Beta units so they’d be compatible with a firmware update, but maybe some of the info provided might apply to what you’re doing…
On the special FW and app, they do have the games still.
The one difference I noticed is that there is a setting that allows you to change the head color on the standard while on the special, its replaced with the type of floor(carpet, tile, etc.). These makes some adjustments on the height, speed, etc.
It’s possible too that they enabled usb debug mode on the latest standard FW. I wished they did but I have yet to confirm that.
Cool! This is useful to study.
Ooops, looks like I have downloaded the tool before last December. I completely forgotten about this. Thanks Benerator!!!
Thanks @Benerator that was a really interesting read about the manual way to update the firmware. Useful info there about the tool and the process to update. Also intriguing that the firmware was so small. Given I remember it took about 15 mins to do my original firmware update, this did surprise me.
Some thoughts I had while reading that. We should bear in mind the firmware provided in the thread is for nerfed beta bots. So we should probably avoid using that particular file for production bots (not that anyone would never hurts to put it in writing). I also wonder if the firmware is for the Bluetooth module, or for the robot “brain” so to speak? Call me paranoid, but thought I should at least ask that question.
edit: inside the download file are 2 files with nrf51422 in their titles. This makes me think the issue with the beta bots wasn’t that “the brain” needed updating but the BLE module needed updating. If you search for nrf51422 you’ll see what I mean. e.g. https://infocenter.nordicsemi.com/pdf/nRF51422_PS_v3.1.pdf?cp=4_6_0_3
So probs this next para is wrong:
Anyhow, assuming it is for “the brain” so to speak, I’d suspect that the method could be utilised to “downgrade” firmware in Rave’s case where he has put the USB/debug firmware on one of his meks. We’ll have to see if he fancies trying it.
Rave thanks for the info on the USB firmware. That’s really interesting to know that it is actually a later version than the one packaged with the standard apps. Interesting too about the app changes. I guess they were working on adjustments to deal better with carpets and so forth. I’d bet this was in an attempt to combat the clicking some. I’ve noticed more click on carpet than lino. I don’t think this is a fault (more a design intention). I’d hazard that the clicking is a clutch of some sort disengaging slightly. So yeh, adjusting for stuff like how much “up” happens before lateral movement would probably help. Just a guess though.
A thought on the USB functionality. It might be there is “some” functionality on the USB port out of the box, it just might not be the “right” USB functionality for the educational module (meaning maybe they changed it). During manufacturing testing, they used the USB port to check stuff was working. I’d hazard that it wouldn’t have been sensible to do the testing THEN re-flash the firmware (as in theory there is then something new to test) but they might have done if they thought the chance of introducing issues after a re-flash was minimal… to be fair, it probably was.
Regarding the USB port, when I first received one of my Beta units, I was having issues using the AR functionality, and they had run a diagnostic test (which at the time revealed that the problem was a defective IMU). At any rate, maybe these troubleshooting steps will help someone (keep in mind this was for a Beta unit, don’t know if anything changed with the implementation for the V1 or V2):
Do you have access to a PC?
Can you install TeraTerm ( https://osdn.net/projects/ttssh2/releases/1) or do you have access to a serial coms terminal?
If have answered yes to the top two can you remove the USB cover on the back of the robot near the back button and plug the robot (leg attached or not) into the computer.
You will need to find the COM port the robot is attached to (will change depending on USB location and computer)
The default COM settings are
Baud Rate = 9600 Data = 8bit Parity = none Stop = 1bit Flow control = none
The Mekamon should begin streaming basic debug information to your screen now.
DIS Motor: 5.7V, Battery: 11.6V, Power: G Peak: 439mA Motor: -117mA Seq: 2 DIS Motor: 5.8V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 3 DIS Motor: 5.7V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 4 DIS Motor: 5.8V, Battery: 11.6V, Power: G Peak: 468mA Motor: -117mA Seq: 5
Give the robot a few cycles and type “di” into the terminal. The robot should now give you IMU debug information. Let the robot sit still for a few seconds then move it around.
Please take a log of the terminal out (or copy and paste) back here to me.
If the unit reads back all 0s or all 1s on the IMU debug then it is highly likely your robot is defective.