SAD CHILD <--- Help Battery issue


#53

It’s actually not in the manual. :smile:

Good news!
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.


#54

Page 2 of the educational one 1st line. :wink:

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?


#55

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.


#56

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.


#57

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…


#58

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.


#59

Cool! This is useful to study.
Thanks!


#60

Ooops, looks like I have downloaded the tool before last December. I completely forgotten about this. Thanks Benerator!!!


#61

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.


#62

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.

Example

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.


#63

Thanks Benerator!

I tested the USB debug mode on Mekas with firmware (FW) versions 2.18(latest), 2.99(special/edu) and 1.10(out of the box).

Both 2.18 and 2.99 when connected to a PC are recognized as USB HID devices but not as USB Serial COM port. Fortunately, I have one Meka that I haven’t updated and was still on 1.10. This had USB Serial enabled. Probably this FW was part of the Beta.
Once connected, it echoes debug messages similar to Benerator’s example.
I tried the ‘di’ command and it did show IMU infos.

I cannot find any documentation on the supported commands so I brute-forced by iterating every character from A to Z, numbers and symbols. It’s case-insensitive fortunately. When the first character is recognized, it outputs the available commands that begins with that character. I captured the output for later documentation. I will share them on my next post. It’s very interesting. Commands can query and set values, some can do playbacks of system animations, set modes - linear, gyrate, mimic, sit, stand, etc.
I haven’t found how to set the head color yet or set the leg, thighs, etc. More research is necessary.
I hope I can find out from the firmware.

Btw, with regards to the possibility of downgrading the FW from 2.99 (special/edu) to the official 2.18, short answer is YES.

I also have concerns about the DFU process. The more I researched and from comparing the firmware in the OBB and DFU firmware from the old thread, I believe the DFU firmware may have only been used to update the BLE bootloader. It might be too risky to even attempt to use the same process and DFU FW as it could brick the Meka. I think it’s possible though to use the same process but we need to have the correct DFU package in order to do so. The FW in the OBB is in a different format. It was stored in a JSON blob as a b64 string. Decoding the b64 to hopefully get the binary and it appears to be encrypted still.

Anyhow, I tried another method. I mentioned that I was thinking to cheat the app so that it will force the FW update.

My first attempt was to see if I can cheat the app into seeing that the OBB firmware version is higher.
I patched the OBB file and changed the FW minor version from .18 to .19.
I uploaded the patched OBB and started the Mekamon app (restored from backup). Btw, I can confirm that installing the APK is not enough. The app just hangs without the OBB. I copied the OBB from backup and the app loads fine again.

Going back… to my surprise, once I connected the Meka, it prompted to update the FW to 2.19.

Other than patching the minor version, basically a 1 byte change, I’m thinking it should be safe since basically I’m pushing the same FW (2.18).
After 18 mins of wait, it took a little bit longer but once it rebooted and reconnected to the app, the updated FW version still showed 2.18. This was expected since I never changed anything else and it should apply the internal FW version. It prompted me to upgrade to 2.19 again.
I then reverted the OBB to see if the Meka is still working like before. I didn’t see any issue. This was a good sign.

So the moment of truth was to see if I can donwgrade a Meka on 2.99 back to 2.18. I made a new OBB by patching this time the major version from 2 to 3. So the app would see that it had the higher 3.18 FW and force it.

It did and I proceeded with the ‘fake’ upgrade – but really its was downgrade. This time it took like 30 mins to finish. So I was a bit worried that it failed. However once the Meka rebooted and reconnected, it showed 2.18 FW - a success!!!
I reverted to the original OBB (2.18), it no longer prompted to upgrade since the versions are the same.
I did the basic tests and didn’t find any issue. Also the compatibility issue I mentioned when using a Meka with 2.99 FW with the latest app, where it continuously stumped its legs when connected, is no longer there; proving further the successful downgrade. It is now fully compatible. :smiley:


New to Mekamon - Amazon Special
#64

Btw, about the special firmware, I think they made it so it only works on their custom RPi, Ubuntu with ROS or with a special driver.
That requires some setup so I’m postponing that for another day.


#65

I mentioned the upgraded versions (2.19 and the special 2.99) shows up as USB HID and not as Serial COM ports.
On the 2.99 FW, the documentation did mention about using a USB HID library.
Thus to use it, ROS interfaces with the Mekamon Base Controller module that translates the ROS commands to Meka commands.


#66

Rave you are doing an absolute legend there in experimentation! (and thanks too to Benerator for sharing the info about the legacy USB control).

Glad we are of the same thinking on the Bluetooth radio’s firmware update.

My guesses are that the older text/command based USB protocol got ditched for something a bit more swish. It makes sense. You start with text (everyone starts with text) and then when you have your own software or library to control things with binary, you switch to that.

Probably something can be figured out about the USB HID driver from the raspi pi image down the line when one of us gets to that (I’ve not even read any more of the manual since last week). I did note though it said something about a bit of the ROS interface being supplied as a binary only though, so knowledge of exactly how the USB protocol works might be won harder than one might like. Still, a job for another day.

Really fantastic news to know that we can flip Firmwares at will though. A superb step forward. I guess I’ll need to find out how to extract this OBB you talk of rave. I’ll add that one to the learning list.

Just a note that I’m holding fire (for the most part) on my mekamon experimentations for now while I concentrate on building my own robot for a bit. That said, I am planning on having a go at resuscitating the stock battery and am, gradually, reading the educational manual… and of course all the fantastic updates on this forum!

Incidentally, quick question about the 2.99 firmware and the “stomp”. Would you say it looks like something has “gone wrong”? or is it simply a (perhaps poor) choice of “idle” movement from RR for that release? i.e. is it the modern equivalent of the standard “looking around then going to sleep” action it does these days.

I have to say, at first, I was disappointed that, after the standard firmware update, the meka lost its “when idle” penchant for random violent emotes (which were fun if a little scary!). After a while though, I got used to the more calmer “when idle” emotes, and in some ways I was kinda glad it wasn’t jerking around in an unpredictable way any more (especially with my somewhat delicate “tether” solution for power).


#67

Thanks to Benerator for providing good leads!

For the OBB, it’s basically just a ZIP archive. I can start a thread later in case somebody needs instructions on how to install the already missing Mekamon app from backup, or wanted to revert from the special 2.99 FW to the official 2.18 FW.

BTW, the stomping motion only happens when an older FW(1.10 and special 2.99) is connected to the app either the Mekamon(2.30 app version for the 2.18 FW) or Reach Edu app. It can be characterized as a continous “walking on the spot” motion. Degree of control varies:

  • 2.99 supports all app touch control and mekamotions
  • 1.10 supports directional controls, no rotational control or Mekamotions.

Note that as I have mentioned, it doesn’t happen when connected to the matching app. E.g. 2.99 FW on the special app. It’s appears to be protocol related. I cheated the latest 2.30 app and downgraded the OBB FW version tag from 2.18 to 1.0. This way I can still use the latest app to control a Meka on 1.10 FW and still play with the USB Serial debug commands.
It also had the stomping motion when connected to BLE. So perhaps, the newer app was sending some unsupported commands that gets translated to the stomping motion. While on the 1.10 FW, sending the Mekamotions doesn’t work but what’s cool is the debug is streaming BLE commands as the Mekamotion plays.

On the Mekamon Base Controller in the special Raspbian image, I can confirm that its their middleware between ROS and USB serial. This module contains these functionalities in the code. It seems to be limited though based on what’s described on the documentation. I think the Firmware holds the key still to understanding all the supported commands. However if it’s only for kinematics and joint control, it should suffice.


#68

I got the integration with Mekamon, Raspberry PI with ROS Kinetic, and Ubuntu ROS working as per their edu documentation. There are some outdated instructions that doesn’t work. Fortunately I was able to find a fix.

Will post pics/vids next time.


#69

Wow rave you really are racing ahead! Great work! and thanks for the further explanations on the different combos of firmware and app WRT working functionality and manifestation of bugs. I almost feel I want to write that lot up in a table of some sort.

Super useful to know that the older firmware spits out debug info in response to receiving BLE commands. I was pondering your proposition that the firmware is the true key to knowing what might be possible. You are right. Both the app and the API exposed in ROS might be using a subset of what is available (although I think we might reaching the limit of what is available/useful with the things already found). That being the case I wouldn’t know where to start trying to get info out of it. One might have more luck with the android app and hope there is a full API buried in there, of which maybe only a subset of functions are used.

I’m guessing/hoping that both the 4 IR sensors/actuators, and the IMU rotational data are available in ROS (and possibly via BLE too) oh and something relating to controlling/talking to/reading the little ATtinys** that are in the peripherals might have benefits down the line. I still not got far with my reading though.

About the peripherals (shields/guns) incidentally… and this is probably a question for @Benerator, does anyone know if the shields with lights in were “controllable”? i.e. did the lights turn on/off or change colour say during combat?

Knelf

** likely this is what they are, I think they are probably 4’s or 5’s


#70

About the peripherals (shields/guns) incidentally… and this is probably a question for @Benerator, does anyone know if the shields with lights in were “controllable”? i.e. did the lights turn on/off or change colour say during combat?

I only ever noticed the shield lights being controllable in the Beta version, I don’t recall them activating during gameplay. At the time they seemed to have limited functionality, like something they planned to implement at a later date… I figured they phased them out with the V1 iteration, but never actually checked.


#71

RE: The shield lights, there was a forum post in the Beta forum about them back in the day…

R9000 said:

So I had a bit of a peek inside one of the armour pieces for my Meka’s leg - noticed it has a pretty simple PCB with three LEDs and a little microchip, plus the three contacts it uses to interface with the robot. Three pins usually means some sort of data wire, so I’m guessing maybe the chip tells the Mekamon what kind of armour is attached, as well as driving the LEDs, but I’m not 100% sure since the app doesn’t tell you yet.
Regardless, what are the LEDs in the leg armour for? I’ve noticed they flash in different patterns when I adjust the kinematic stance (very cool by the way), but they seem to freeze in whatever configuration they were in whenever I change it back to ‘Kinematic’.

and Silas replied:

They are both for aesthetic purposes and for presenting information in different (future) game modes e.g. a damaged leg during a battle or twitch reaction game.
You can never have too many LEDS :wink: :grin:


#72

I think it uses I2C.
In debug mode, I can query the add-ons - e.g. weapons attached. Each have s/n.
I don’t have any armour LEDs to test though. But it should be the same with the shields since the weapons uses the same 3-wire connection. I haven’t checked if they are attiny.