SAD CHILD <--- Help Battery issue


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


#73

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…


#74

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.


#75

USB Debug Commands on 1.10 FW

https://drive.google.com/file/d/1nN8Zq7V6QBk1h5zCdAe2AH8xV7zSBk1T/view?usp=drivesdk


#76

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… https://en.wikipedia.org/wiki/SDI-12

@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


#77

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.

Knelf


#78

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.


#79

Sounds good, and interesting to hear your method. Yeh mine was/is utterly flat as a pancake. I’m going a slightly different route. Will post a report if it works. Suffice to say I’ll be being careful and keeping a very close eye on temp. Even if I do manage revival I’m planning on doing some extra checking before installing in the meka.

Re. the battery purchase I was honestly not even expecting it to arrive, and I thought there was a reasonable chance to have fitting issues even if they sent me one with the correct dimensions. I’d have happily and preferentially brought from anyone else but quite simply Banggood was the only place on the planet both me and @ckalkhof could find any 3cell packs that would fit. The only other option is the 1 cell jobs on adafruit (and other places). [note I appreciate the barrel cell route is an option too of course but with customisation - wanted to go the minimum disruption route first].

I sometimes wonder if anyone from RR is still reading this forum and following along with this and, if so, what they’d make of our machinations. :rofl:

Knelf

PS congratulations on your Robot Army!!! Some people had to do a Kickstarter for that! https://www.kickstarter.com/projects/1984252088/robot-army-starter-kit


#80

Showing as flat is what I had all of the packs initially. It’s a cell cut-off protection mechanism to prevent further discharge.

Btw, I figured out why the 2.18 FW ( latest firmware) responds to HID commands like the 2.99 special FW. Apparently it’s also labeled ‘debug’. Also checking all the revisions, 2.99 FW was likely based on 2.15+ FW but with the HID debug option.
Another thing, for some reason, you cannot upgrade from 2.18 to 2.99. The app will push the FW but it will get stuck with no progress(I waited for more than 30 mins till I gave up). This is using the special app that can upgrade to 2.99.
All my Mekas with 2.18 FW show the same behavior. So only 1.10 can be upgraded to either 2.18 or 2.99. Anyhow, I haven’t seen any difference in terms of compatibility with Raspbian Kinetic-ROS on both 2.18 and 2.99. While 2.99 has compatibility issue (stumping behavior when the app/BLE is connected) on using the latest Mekamon 2.30 app and Reach Edu app. So it might be best to just use the latest 2.18 FW with the latest apps.

I’ve been studying ROS lately and I will likely play with it more. I will defer on the Esp32-cam explorations for now. ROS was designed for distributed computing and has a lot of packages that will be useful to build my Meka-drone army. :slight_smile:


#81

Ah… when I say flat I mean flat individual cells measure something like 100mV (might be higher once I get them completely disconnected). However I have a paper on the results of restoring from such low voltages so I have some hope that it can be done. I was going to start last night but I decided I needed to do something about the poor state of my soldering iron’s tip before attempting that one. In present state I think the job would be akin to the trying to cut chocolate bars while wearing oven mittens. I could use the gas one but… flames and lipos… what could POSSIBLY go wrong?!? :joy: Did some work on my own robot’s circuit diagram in the end instead which is starting to look a bit like the London Underground in Fritzing :sweat_smile:

Odd that the upgrade hack didn’t work on the 2.18 FW but equally good news that it seems there is little difference/benefit to the 2.99 firmware. Quite looking forward to trying out the ROS stuff without needing a firmware update in due course.

Once again thanks so much for all your investigative work. You are putting your army to a great use that the rest of us can’t (because we’d likely be too scared of bricking our one and only Meka).

Knelf


#82

We likely have the same battery states when we got them. I got mine from 3 different sellers so if I had high success, chances are very high that the other packs can be awaken/revived too.
High hopes! :smile:

“look a bit like the London Underground in Fritzing” – that’s how all circuits starts. :slight_smile:

Btw, for the upgrade to 2.99 FW from 2.18, I wasn’t using the OBB firmware version hack. I was using the special APK from their documentation. The one they designed to officially push the 2.99 FW. So technically it should work. It’s probably some additional checks making the upgrade from 2.18 to 2.99 incompatible. Anyhow, it’s for the better. As the latest 2.18 FW offers the best compatibility for supported features.

For research, I will keep 1 on stock 1.10, 1 on 2.99, and the rest on 2.18(latest).

As I see it, we do have these upgrade/downgrade paths tested:

  • 1.10 > 2.18 (normal)
  • 1.10 > 2.99 (with special APK)
  • 2.99 > 2.18 (OBB FW version hack)

#83

Perfect. And a nice summary. While I think of it, were you able to confirm that the hashes I posted for the APKs I extracted were the same as the ones you generated from yours? If so we can likely rule out any dodgyness in extraction programs used.

I’ve yet to find out how to extract an OBB though from the phone.


#84

For the SHA1, I think they were different. But that could be for a lot of reasons: timetstamp, some local files, etc. Could you share your APKs so I can make a detailed comparison?

BTW, yesterday, I did some comparisons on 2.18 and 2.99 FW on ROS compatibility. I have 2 Mekas on 2.99 FW so I can get consistent results. I will post the results later.
But one of the major difference sad to say is the transform (linear and angular, for forward, backward, left, right, strafe, rotate) controls only work on 2.99. It seems they modified the BLE protocol so the 2.18 Meka returns unrecognized command upon receiving the same. So, it doesn’t move at all. The rest of the controls work the same or with some slight differences.
The ROS base_controller binary they provided will need to be patched to correct the incompatibility. That’s one option. It may not be that easy though because they didn’t open-source the code. It will be a low-level patch.
The other option is to make a custom ROS node using the latest known BLE commands to provide the transform controls. That should be much better I think.

Worth mentioning is that their base_controller uses USB HID and/or BLE to communicate with the Meka so it’s not pure a USB HID as I originally thought. I think they exposed some functions in USB HID that were not available in BLE to provide the additional controls.