[Unitree Go1] Robot not answering after changing the MCU

Hello!

My GO1 Edu is the first version of the GO1 Edu, and its MCU was not compatible with the new software, so Unitree shipped a new one for me. Now, after changing it and making sure that all cables are correctly plugged in, the robot won’t answer to the commands. Or rather, it answers to SOME commands, SOMETIMES: L2+A, and L2+B are the only commands it answers to.

This is the process I did:
Changed the MCU
Turned on the robot. It takes a long time to boot, and doesn’t stand up alone after booting. When I push L2+A several times (generally 4 to 5 times) it finally responds and stands up. So it stood up, but it clearly had wrong estimation of the joints because it was in a position that reminded more a stick insect than a dog. So I recalibrated the legs, and now it stands up in a dog-like manner.

The problem is: it still doesn’t stand up alone, it responds to L2+A randomly, and responds to L2+B, but doesn’t answer to any other command. Joysticks, start, select, etc, nothing makes it move. Then the Unitree support told me to try to update the unitree_legged_sdk on the RPi. So I put the sdk version 3.8.0 there, built it, rebooted. Still nothing is solved. I also tried the example_walk and the example_position directly from the RPi (it worked before) and it doesn’t move.

Now I found that after double-clicking L2 + A, it starts to move, but in a shaky manner, like if the controller was unstable. It even falls often because of so much instability.

Last problem: when I connect with the app, I can see the cameras’ images, but absolutely no information on the joints states, or the battery. The robot also doesn’t answer to commands from the phone.

Any idea how to solve all these problems? I feel like they are all related to a single source, probably some software to update somewhere, but I cannot know.

Thank you!

Hi Rob,

We’ve contacted the manufacturers, we will get back you as soon as they reply!

Also, in the mean time, have you tried updating the firmware of the GO1. The procedure is in the DOCs

Thank you for your answer!
No I haven’t tried to update the firmware, the manufacturer told me that the new board came with the latest. I haven’t verified though

SOLVED!
Update for someone meeting this error. The Unitree support came back to me and told me to update the software, as in https://www.unitree.com/en/download/ (only the software, not firmware). I did that, and now it works well!

1 Like

SOLVED!
Update for someone meeting this error. The Unitree support came back to me and told me to update the software, as in Download Center - Unitree (only the software, not firmware). I did that, and now it works well!

Glad to hear that!

I’m in need of an older MCU for some research, are you or anyone else willing to sell your after the swap?

I’m just curious, what are you exactly trying to find out?

Exactly how much MIT cheetah logic is within, and why I had to practically force them to acknowledge that they use it.

per:

Legged_sport is clearly referencing the MIT Cheetah HardwareBridge for example.

https://mit-biomimetics.github.io/d9/da0/_hardware_bridge_8cpp_source.html
https://mit-biomimetics.github.io/d5/d90/_control_parameters_8cpp.html

Their support is over all pretty awful, and it would be nice to liberate the Unitree dog brain a bit, and be able to just work with pure MIT Cheetah logic.

1 Like

Hi @d0tslash,

thanks for this post.

Do you have already a Go1? How about using the Go1 Air (closed source version) and replace the controller with an UPBoard etc. on which you can run your Cheetah code? I would say that’s a bit more efficient instead of “hacking” the old Unitree MCU - Or what you are hoping to find out? :slight_smile:

Happy to read your thoughts! :robot:

1 Like

I have both a Pro, and a MAX, and access to several EDU models. Air is no more or less “closed source” than the other versions. Their entire design is based on a partially closed model. The SDK is not really “open” as it is composed of binary objects that you won’t obtain the source code for, nor can you see their internal logic bits.

MCU security, work is something I specialize in. I need to see what the existing platform is based on before work on a replacement brain can begin proper. The brain is already utilizing the double STM32 design as expected, repurposing the hardware should also be on deck. No need to scrap usable things, short of in this specific case, to dump the RDP1 protected STM32 MCU contents via known glitching errata. https://eprint.iacr.org/2022/903.pdf. From here further work can be done in Ghidra, identifying exactly what they did. Sure, I could also try to just sniff LCM messages, and bolt on a new Cheetah brain, but both of these paths go hand in hand for success.

I’ve you’ve read the Cheetah design doc, the overlap is pretty clear, very quickly. Just look at the base detail of the spine.



I did at least get them to acknowledge it, eventually. They actually tried to hide it at first, and deleted my GitHub request asking about it.
PastedGraphic-4

They actually directly asked me how to hide this fact before hand.
PastedGraphic-3

I suggested they not hide it, because it was obvious:

$ grep Cheetah . -ri
Binary file ./raspi/Unitree/autostart/02sportMode/bin/Legged_sport matches
$ strings ./raspi/Unitree/autostart/02sportMode/bin/Legged_sport | grep -i Cheetah | sort | uniq
22PeriodicMemberFunctionI25MiniCheetahHardwareBridgeE
CHEETAH_3
CHEETAH_3_ZERO_OFFSET
Cheetah3.h
MINI_CHEETAH
MiniCheetah.h
PeriodicMemberFunction<MiniCheetahHardwareBridge>
[Backflip DataReader] Setup for mini cheetah
[Cheetah Test] Test initialization is done
[Front Jump DataReader] Setup for mini cheetah
[Offline Motion DataReader] Setup for mini cheetah
_Z13buildCheetah3IfE9QuadrupedIT_Ev
_Z16buildMiniCheetahIdE9QuadrupedIT_Ev
_Z16buildMiniCheetahIfE9QuadrupedIT_Ev
_ZL21CHEETAH_3_ZERO_OFFSET
...
_mainCheetahVisualization
buildCheetah3<float>
buildMiniCheetah<double>
buildMiniCheetah<float>
cheetah
cheetahMainVisualization
cheetah_visualization_lcmt
cheetah_visualization_lcmt.hpp
setMaxTorqueCheetah3
~MiniCheetahHardwareBridge

Go1_2022_09_06_cdc41f89.zip which is not widely distributed contains the official license from MIT, that should have been included at sale, and was technically illegal to fail to include / disclose.

As I know one of the main contributors of the Mini Cheetah project, or may the most important person (in my opinion) is Ben Katz which is a great engineer but had some design issues in his BLDC motor design. As I know the ground layer wasn’t done properly, therefore at some time, the high current part has tried to get the power from the CAN Bus which blows away, or am I wrong? Seems you are much more familar with it :wink:

From the project itself I just know the Github repo and the dozens alibaba kits, which sadly aren’t working properly. I have already bought one of it in the past as well and the pulsing rate of the motors are quite slower than Unitree. Do you think this is just due to modern uC Chipsets / Architecture or do they have changed something substantially?