I am a deputy sheriff and EOD/HDS technician. We have a M.A.T.I.L.D.A. eod robot. During a search mission for injured civilians after a tornado our robot contacted a down powerline and the power supply caught fire after that nothing has worked. It appears the motor control board and the power supply are fried. We want to save this robot if possible. I’m just an EOD Tech and robot operator not an electronic specialist so we need some help. Is this doable?matilda_specyfikacja.pdf (1.2 MB)
It is always a little sad to see a good robot down. Not to be too discouraging, but in general, robotics systems can be pretty complicated and without detailed documentation of how the subsystems of your robot work and communicate, repairing your robot might be a difficult task. Also, integrating a lot of systems (like the actuators I mention below) together from scratch with a simplified user interface is a pretty involved project.
To give you an idea of the type of problems you might have to solve for a rebuild I’ll go into depth on one of the subsystems for the robot I can see and know a little bit about. There are linear actuators that change the position of the arm and (at a glance) they look similar to the linear actuators we carry. However, without solid, in depth documentation (or a good deal of careful poking around in place of that) it is difficult to know if they use simple limit switches (like some of our actuators) to signal to the motor controller to stop the motor when the actuator reaches the end of its travel range, a potentiometer (like some of our actuators) that sends a voltage to the controller so that it is aware what position the actuator is in, or some other feedback system to determine the position of the arm. Furthermore, if it is determined that the actuator uses a potentiometer feedback system (which is somewhat common and that one of our Jrk motor controllers can use to control the actuator’s position), it is still necessary to determine how the actuator’s controller communicates with the robot’s control system. If we want to replace the existing actuator motor controller with different one like the Jrk and the communication method uses a digital control protocol like serial control, it is still pretty unlikely that the existing controller would use the exact same communication protocol system as the somewhat arbitrary one we devised for our controller. In such a case, there are workarounds that could be explored, like using a microcontroller with a custom firmware written to read commands sent in the protocol for the old controller and translate them into commands that make sense for the new one, but that is not very straight-forward and can be especially difficult without good documentation or even a working system to reverse engineer.