The regular Raspberry Pi line is a flexible single-board computer, but sometimes you might find yourself wishing for a form factor that was better designed for installation into a greater whole. This is why the Compute Module variants exist. Indeed, leveraging that intention, [Hans Jørgen Grimstad] has used the powerful Compute Module 5 as the heart of his “Overlord” robot controller.
The Compute Module 5 offers a powerful quad-core 64-bit ARM chip running at 2.4 GHz, along with anywhere from 2 to 16GB of RAM. You can also get it with WiFi and Bluetooth built in onboard, and it comes with a wide range of I2C, SPI, UART, and GPIO pins to serve whatever ends you envision for them. It’s a whole lot of capability, but the magic is in what you do with it.
For [Hans], he saw this as a powerful basis for a robot controller. To that end, he built a PCB to accept the Compute Module 5, and outfit it with peripherals suited to robotics use. His carrier board equips it with an MCP2515 CAN controller and a TJA1051 CAN transceiver, ideal for communicating in a timely manner with sensors or motor controllers. It also has a 9-axis BNO055 IMU on board, capable of sensor fusion and 100Hz updates for fine sensing and control. The board is intended to be easy to use with hardware like Xiaomi Cybergear motors and Dynamixels servos. As a bonus, there is power circuitry on board to enable it to run off anything from 5 to 36V. While GPIOs aren’t exposed, [Hans] notes that you can even pair it with a second Pi if you want to use GPIOs or camera ports or do any other processing offboard.
If you’re looking for a place to start for serious robot development, the Overlord board has plenty of capability. We’ve explored the value of the Compute Module 5 before, too. Meanwhile, if you’re cooking up your own carrier boards, don’t hesitate to let the tipsline know!
LOLWUT? 64-bit ARM CPU running at multiple GHz just to control a bunch of H-bridges?!?! This is so wasteful it makes my head roll in sadness.
During my time at the university we used cheap $5 Adafruit H-bridge modules to control our sumo robots. Entire robot logic would fit on ATmega 48 containing 4kB of FLASH.
The point is that you can easily run some inefficient and non-optimized computational models and heavy digital filters on the hardware, so you can prototype control algorithms without instantly running out of resources.
The CAN bus is where the potential for expansion is here. This could be used for anything for a 6-arm robot to a custom vehicle controller to a PLC.
and it will play doom too.
Have you ever tried to run a SLAM navigation system? It’s absolutely required for modern robotics. Visual camera-based navigation in any environment, no toy line following.
There is no microcontroller in the WORLD capable of that. Even the Pi can barely cut it.
yeah, for sure, but this board lacks severely in the way to connect cameras and advanced sensors…
This is intentional. The board is designed to be cheap, small and powerful enough to enable you to quickly get off the ground with a hexapod-, biped- or robot arm-project that uses dynamixels or CAN based servos. If a project requires additional sensing, the board can easily be interfaced to anything that has en ethernet connector (like an NVidia Orin, Pi etc). , or (if you can live with the latency) anything that support bluetooth or wifi.
Think less simple sumo logic and closer to something on the boston dynamics dog end of the spectrum. That definitely can’t be handled by an Arduino alone.
This isn’t exactly aimed at controlling a 5 dollar sumo ;)
I dont understand why the pins are not exposed. These are required for quadrature encoders, amongst other things.
The servos this board is designed for have built-in motor drivers, encoders and controllers (as well as dedicated power rails). Control is done by sending control packets to servos and reading status response packets (much like the process data loop in industrial controllers).
This allows the developer to focus on high level control and kinematics.
Ok, i understand that, but what happens if i have, for example, a quadrature odometer encoder to read?
Then you are in motor controller territory. This is not a motor controller :)
The MCP2515 has a very small 2 deep FIFO buffer, so on the Raspberry Pi you can’t actually achieve 100% bus utilization as it can’t read out the FIFO often enough, see https://forums.raspberrypi.com/viewtopic.php?t=336432
Changing to the MCP2517 or 2518 is worth it for the much better performance for regular CAN, even if you aren’t using CAN FD.
Thanks for the tip :)
I don’t understand the economics of a carrier board vs a zillion hats. This seems limiting…