{"id":12091,"date":"2025-10-27T21:05:09","date_gmt":"2025-10-27T20:05:09","guid":{"rendered":"https:\/\/dronesonen.usn.no\/?p=12091"},"modified":"2025-11-07T12:44:25","modified_gmt":"2025-11-07T11:44:25","slug":"minimuck-week-10","status":"publish","type":"post","link":"https:\/\/dronesonen.usn.no\/?p=12091","title":{"rendered":"MiniMuck \u2013 Week 10"},"content":{"rendered":"\n

Hello W\u00f8rld!<\/p>\n\n\n\n

This week from MiniMuck! The team has been in debugging hell. While producing parts, parts, and more parts. Now the whole team has full focus on the final MiniMuck robot.<\/p>\n\n\n\n

\n\n\n\n

Leon<\/h2>\n\n\n\n

The transition:<\/strong><\/p>\n\n\n\n

When moving from the MVP to the MiniMuck (final product) the complexity of the controller gets higher. Here is a diagram showing the stack for the MVP compared to the final product.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The biggest difference between the two is the fact that the MiniMuck needs two controllers. One for steering and driving the robot, and one for the arms\/legs of the robot. The MVP used one differential drive controller (DDC), while in the MiniMuck we are trying to get it working using an ackermann steering controller (ASC) and a joint trajectory controller (JTC). The JTC is a basic controller where the developer has to define all components. So it is basically a framework for building custom controllers, while the DDC and ASC are controllers that have parameters they expect, so they are more rigid to work with.<\/p>\n\n\n\n

Introduction:<\/strong><\/p>\n\n\n\n

This week I have mainly worked on getting to a point where we can test the minimuck in Rviz with mock components. I spent most of monday on making the urdf and getting the right mesurements from the real minimuck. Later in the week I shifted focus to the launch file and minimuck_controllers.yaml file.  the yaml file is basically a parameters file that lists all controllers with related parameters as well as the hardware used. I typically call this file the controller manager.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Challenges:<\/strong><\/p>\n\n\n\n

When trying to get the minimuck working in Rviz the biggest challenge I have met and still not resolved is the fact that the odomotry is not working alongside that the robot never recives the controller input from the keyboard. I assume that this is related. To start with the ASC did not even load because my parameters did not satisfy the controller. I changed and added some parameters to see if I could get it working. That fixed the loading issue, however the odomotry issue came up and is there still.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Moving Forward:<\/strong><\/p>\n\n\n\n

I have an idea of switching out the ackermann steering controller for a setup with a diffdrive controller, alongside some custom code for turning. I plan on lifting this idea on next weeks monday standup meeting so that we can discuss how to move forward. Moreover next week my plan is to get the robot running in rviz and be ready for testing with the real physical minimuck. That means that I have to resolve the challenges I have been facing as well as making a new custom hardware interface and launch file.<\/p>\n\n\n\n

https:\/\/gitlab.com\/mini-muck\/mm_software_2025\/-\/tree\/control_branch?ref_type=heads<\/a><\/p>\n\n\n\n

\n\n\n\n

Herman<\/h2>\n\n\n\n

This week I have mainly worked on the PCB. The components were finally received, and I assembled the PCB with help and equipment from Timo (special thanks is in order). After assembly, I tested some of the functionality and solved issues with the design.<\/p>\n\n\n\n

The Actuator and Power Supply Board (APM)<\/strong><\/p>\n\n\n\n

Our system uses Raspberry Pi 5<\/a> with ROS to control robotics, interpret LIDAR data and compute navigation. The Pi requires a 5V power supply, has some IO, but expansion cards are needed to control servos and motors. We are also using the Dynamixel XM<\/a> servos supplied by the university with the OpenCM 9.04 microcontroller and servo driver card. By integrating this card with the Pi, we can control the servos, but external motor drivers are still needed. By integrating the OpenCM 9.04<\/a>, Texas Instruments DRV8231A<\/a> H-Bridge Driver, Texas Instruments TPS40303<\/a> based Buck Converter from three cell LiPo to 5V, a USB-C power connector and voltage sensing for battery monitoring, we integrate the vehicle with the Raspberry Pi on one circuit board. The block diagram of the circuit board is shown below.<\/p>\n\n\n\n

\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
MiniMuck APM Board Electrical Block Diagram<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
MiniMuck Electrical Block Diagram<\/figcaption><\/figure>\n\n\n\n

Assembly<\/strong><\/p>\n\n\n\n

When assembling the PCB, I started with all components in bags, and the PCB and stencil for solder paste. When I ordered the components, I used the entered the reference designator (U1, R1-R4, C2, etc.) into the \u201ccustomer reference\u201d field on all lines to ease the assembly process.<\/p>\n\n\n\n

The stencil was used to apply soldering paste. The stencil design uses cutouts on pads to avoid excessive paste which can cause bridging.<\/p>\n\n\n\n

A heat-bed and hot-air was used to solder the surface mounted (SMD) components. Because I stitched the copper planes, and did not use thermal reliefs, some components were quite difficult to solder. Especially the electrolytic capacitors because of the plastic melting. Because of this, a soldering iron was used on the more fragile components in addition to the through-hole (THT) components.<\/p>\n\n\n\n

\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Packages received from JLCPCB and DigiKey<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Stencil for solder paste application<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
The Pick and Place machine is used to place SMD components<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Handsoldering of THT components<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
First power on test<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Driving servos with the board<\/figcaption><\/figure>\n<\/figure>\n\n\n\n

During the assembly, I checked if the OpenCM 9.04 fit, and it did not. The microcontroller does not have pin spacing in the datasheet and by counting wrong, the header was offset by one row (2.54mm). This issue occurred due to limited measurements available on the layout of the OpenCM, and I used the breadboard for measuring. To resolve this issue, the pins of the socket header were bent outwards 90 degrees like the SMD version and soldered only on top of the pads. This is sufficient for our use but is unfortunate and should not have happened.<\/p>\n\n\n\n

Testing Motor Driver<\/strong><\/p>\n\n\n\n

When the PCB was assembled, I did some measurements with the digital multimeter to ensure no shorts on power rails and the most critical nets were not shorted either. When no shorts were found, the power was turned on and the LEDs lit up. The power supply supplied 5V and the motor drivers amplified the PWM correctly, but there was a catch.<\/p>\n\n\n\n

\n
\n
\n
<\/div>\n\n\n\n
\n