SAD CHILD <--- Help Battery issue


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.

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 ( 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.


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

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.


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.


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).


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.


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.


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?


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


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.


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:


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.


The IMUs, ADC, compass, voltage/amps are available in 1.10 FW accessible via usb debug. Will need to check if they have been exposed in the special 2.99 FW.

I’ve tested Mekas on 2.18 and they are the ones that responds to rpi ROS via USB HID.
I didn’t have 2.99 then since I reflashed that to 2.18.

The IR states do appear once connection is established with the app. But I haven’t found the commands to query their state on demand.

More testing required…


Correction, the leg armour uses a 1 wire bus so it can’t be I2C.

I got curious too.

The closest I can find is PIC10F220 or as Knelf said an Attiny.

The pin-out matches the input and the other 3 outputs that can drive LEDs.

The standard V1 Berserkers like mine have unpopulated LEDs.
Unfortunately I don’t have SMD LEDs to test.


USB Debug Commands on 1.10 FW


What is the ADC measuring?

edit: ah I see FL:278,FR:279,BL:280,BR:258,motor:5.9,battery:11.3,current: 1025mA
Looks life front left/right, back left/right “something” and motor… wonder which? all? presuming current is total being drawn. Worth knowing when selecting batteries. Need a discharge rating of at least 1C

Good to know there is a compass too, I’ve used a non-magnetometered accel/gyro before and the drift on the Z axis was quite the irritation.

Good find on the other alt chip for the peripherals. The reason I think it’s likely to be Atmel though is that RR’s hardware guy mentioned using Atmel studio in his interview video on youtube. Unless there are any other atmel chips in the meka (possibly in the legs?) I’d guess they are using them in the peripherals. There is a way to check though, I know a way to dump the firmware off them. If it doesn’t work, we know it isn’t ATtiny. Quite far down on the list for me though I’m afraid but I’ll put it down anyhow.

@Benerator great to know that the LEDs (or perhaps other - who knows what was in planning for the weapons, or other addons) can be dynamically controlled. That is what I was hoping, even though it isn’t so useful for us… unless control mechanisms for them are already in the firmware… in which case the signals sent to the LEDs could be re-purposed for “other”… where “other” = “whatever we can think up” :smiley: .

It might be possible to discover the 1 wire protocol for data exchange they use but I don’t have any gear that would help me analyse that. One for down the line… the only protocols I know for chip comms are SPI and I2C which indeed use too many wires, but there might be a common one for 1 wire. If there is, I bet RR are using it. If if could be determined, and there is a way to use it via BLE or the ROS API, then that means there is scope for building anything at all and connecting to/communicating with it via the meka ports. I wonder if this one maybe…

@rave76 great discovery that the current firmware works with ROS! Also well done on mapping out the debug commants for the stock firmware. Going to go have a read!

edit: ah that lot looks great! (and now we know what MPU it has). I think that “on BLE connect” stuff might be super usefull too with regard to decoding the initialisation messages


Returning to the subject of batteries for a moment and @ckalkhof might be interested. My battery from Banggood arrived this weekend. The one you said you’d been trying order but kept not arriving.

The sad news is that they’ve sent me completely the wrong one. The one they have sent me is so thick that it wouldn’t even slide in the meka, let alone go in the battery pack. Rough estimate it’s about 24mm thick.

I’ll of course try and talk to Banggood about it and see if anything can be done but I’m not holding much hope, likely best I’ll get is a refund. My suspicion is that an earlier version of these batteries might have been thinner (I saw someone measure one on youtube) but they’ve maybe been surpassed by a thicker narrower version.

Getting someone to actually check dimensions before mailing is probably too much to ask for. You could get a specialist dealer to do that but from the Chinese version of amazon… forget it.

Anyway, might be time to try plan B (resuscitation). But I’ll keep you posted on the outcome of liaisons with Banggood. If nothing else, what I can at least do with this one (that I couldn’t with my tethered battery) is rubber band it on top of the meka, which at least gets me maneuverable.

Ah well… the saga continues.



I sympathized with you. It’s the reason why I avoid buying goods shipped from China directly. I always choose local sellers (goods are already here). They do costs more but at least you’ll get it quick. Generally, when local sellers make a mistake, they make good to correct it.

Experimentation is a gamble. I also lost some money trying to find cheaper substitute cells.

On the subject of resuscitation, or what I prefer to call the “awakening”, did yours came out of box discharged? If so, there’s a high chance you could succeed.

Confession, I bought another 2 Mekas for 28 USD each. So I have 8 now. My limit is 10. :smiley:

My goal was to experiment on a faster way to “awaken” the battery packs. I’m using a regulated power supply with adjustable constant current and constant voltage.

I made a mistake on 1 and had it charged way too fast and too much. It had swollen so I lost one pack. The other I took my time – slow, low and steady Voltages and Amps and kept monitoring the temps for any increase. When I felt its getting hotter, I would stop and let the pack rest for a few hours. Then I continued to charge at low Voltage (9V) and lower Amps ( < 200 mA) and monitor temps. I would increase the Voltage slightly when the pack would no longer accept the charge (Amps goes down to 50 mA or less). I would not charged at more than 200 mA. When I got the pack charged at close to 11 V. I would switch to the OEM charger. I continue to monitor the temps.
With this method I got the pack revived and usable under less than 24 hours as opposed to using the OEM charger plugged for 3 days or more. That allowed the cells to get small charge overtime – very slow charging. After 3 days or so, removing them and re-plugging them back in allowed the OEM charger to recognized the pack and begin to charge it normally. I would monitor the temps still and give them rests when they feel warmer. The latter is how I revived 5/6 packs. Only 1/5 pack has 75% capacity. The rests were at 82% and up. With 1 reaching 95% to full capacity.

Hopefully, if I can get at least a year of use, I’m already happy. By that time I would have 3D printed a custom case to fit the protection board and 3 x 18650s - battery mod v2.
That’s my long term plan.