The student lounge blog focuses on student success stories. Winning student teams share their knowledge and the MathWorks student programs team shares best practices and workflows using MATLAB and Simulink.
Building a robot is not a simple task. One needs to create various prototypes to validate various parameters. However, manufacturing and testing different prototypes is a time-consuming and expensive task. This is where simulations save a robot builder’s life. One can simulate various mechanisms and get an idea of the feasibility of the design. Along with this, a designer gets the flexibility to design various mechanisms. Team DJS Robocon 2021’s Simulations Division used MathWorks Tools to create simulations of the various mechanisms for the National DD-Robocon 2021 robotics competition.
The theme of ABU Robocon 2021 challenges teams to play the game of throwing arrows into pots by using the robots equipped with the modern technology. To summarize the game, each team has 2 robots – a throwing robot and a defensive robot. The throwing robot throws the arrows into the pots and the defensive robot can defend to avoid an arrow throw from the opponent team to reach the pot.
In this blog, we are going to share how we have designed and built our solution to address the challenging problem statement. For designing our systems, we used various MathWorks tools which helped us in testing various prototypes to eventually finalize our design.
Designing the Throwing Robot
There are multiple ways in which a robot designer can design an arrow throwing robot. It could be design inspired from a cross bow, a catapult or just using a direct piston. We had our limitation in terms of our financial budget and the dimension constraint to design our robots. We tried various mechanisms using Simscape to ensure to meet our requirements before we put our robot into production.
1. Crossbow Design
In the first mechanism we attempted was a crossbow base. The mechanism was shaped like a bow, complete with a base and string. The arrow is resting on a base with a string stretched across it. The string was stretched with a servo and a pneumatic piston, and then the servo rotated 90 degrees to release the string and shoot the arrow.
The issue we faced with this mechanism was that because there were pots at various distances for aiming at, each pot string had to be calibrated at various distances. The loading mechanism, which used a piston, became bulky, making it difficult to change the angle precisely with the servo. And, hence we switched to a different approach due to this mechanisms accuracy issues.
For arrow throwing and varying piston angle, the mechanism employs a double acting pneumatic piston.The piston is positioned and mounted on the base so that the piston rod strikes the centre of the arrow tail. To hit the arrow, we tried blocks of various sizes and cross sections on the piston rod head as well as tested it for various pressure values.
To change the throwing distance, we needed to change the inclination angle which meant changing the pressure. But we had a limited storage where we could not increase the pressure further. Another reason to reject this mechanism was if our loading mechanism loads the arrow at a small angle change, the arrow would take an inclined path, decreasing the chances of the arrow landing in the pot.
A catapult was mounted on a fixed length of arm, with one end hinged to a planetary geared DC motor. We tested catapult arms of various lengths, forks of various shape and various initial resting angle of the catapult to decide our design. Each of these were designed to throw an arrow into a pot located at a specific distance.
Since, our object of interest was an arrow with an arrowhead, we designed a fork on the catapult to place the arrowhead precisely in the fork. Due to the accuracy needed, we used a servo motor as the means to precisely load the arrow on the catapult. However, the servo could move only 180 degrees. The issue was because arrows and the catapult mechanism were located at specific initial angles and the 180 degrees range became constricted for us since there was no sufficient contact between the fork and the arrowhead during the arrow throwing.
We then checked for the DC motor. The limitation with DC motors was that if we wanted to get the required force, the arm had to rotate twice, or we needed a high torque motor to throw the arrow (which crossed our allocated budget). So, we decided to eliminate the two issues by using a simple catapult and using a pneumatic piston.
4. Catapult with Pneumatic Piston Actuation
A pneumatic piston is linked to a rotating hinged arm, and an arrow is attached to the arm. It was discovered that small changes in parameters such as the distance between the piston’s hinge point and the hinge of the rotating arm, the length of the rotating arm, and the distance between the rotating arm and the base plate had a large impact on the outcome.
Using this mechanism, the pressure required to achieve a perfect landing of an arrow in a pot has been reduced when compared to the previous mechanism. Additionally, due to the curve arm, small arrow angle displacement is avoided, and the consistency of a perfect throw has been increased comparatively. As a result, we finalised this mechanism.
All the observations which we observed in simulations were the one which we saw on the real robot.
We did not know the parameters of our actual system but wanted them to work on our model to have a realistic simulation. There were a lot of parameters we wanted to know the values for – like the force on the tail of the arrow to go for a specific projectile path or to find piston and friction parameters. We did not know these parameters, but we certainly knew the inputs and the outputs to our plant. So, we used the optimization approach to obtain the parameters we needed.
Determine the Force for Arrow Throw
We assumed the shooting angles, time to destination, maximum height, and maximum range to obtain a projectile equation.
Our input was a reference signal which we generated from this projectile equation and our output were the X and Z coordinate of the location of the arrow (output of our plant). Using parameter estimation, we found the force to land the arrow to the required location.
Determine Piston and Friction Parameters
For this, we attached a barrel to a surface with zero degrees of freedom with a weight of 3 Kgs. We attached a green-colored paper to the weight. We then used color thresholding to find the position of the stroke and saved the positions in a time-series format.
We used this saved data as the input to the piston plant through Signal Builder to eventually calculate the friction parameters, internal spring stiffness, and damping of a simple pneumatic piston.
Controlling Virtual Robots using Joystick
For the competition, an important part of the performance of the robots is the manual control of the robot using a joystick. Since the robot needs to perform certain tasks, we ensured that we tested the robot motions and joystick control in simulations. Our tasks had to be completed in a span of 3 minutes and that is where implementing the logic in Stateflow helped us tremendously. We could keep a track of the tasks that it was performing and how much time it would spend in each state.
We also used the joystick controls to pick the arrows. And these were simulated using the physical parameters of our mechanism to make it as close to the hardware as possible.
Apart from providing control with joystick, we also used the signal builder to see the movement of the robot frame with respect to the signal that is given to the robot and simulated the entire gameplay to pick and throw the arrow in the pots.
You all just saw how we utilized MathWorks tools to simulate multiple designs before building the final prototype. Continuing the same approach/workflow, in the following year, we intend to develop a more precise method for identifying missing parameters to improve the accuracy of our mechanical simulation model. We plan use automatic code generation on our controlling platform as well as performing co-simulation between proteus and ROS to make our model more realistic.
We started to work with ROS this year to communicate between our system and a robot spawned in an arena co-simulated Gazebo. We used a Simulink model to subscribe to camera data on the robot. We used this camera data to understand the color to be detected using the interactive Colour Thresholder app. These threshold values were published from the model that were subscribed by the robot to detect an arrow of the specified color. For the coming years, we are investing in deploying ROS nodes using MATLAB and Simulink since we are developing our controller algorithms in Simulink.
We are also opting for a sensor fusion technique will make our robot more precise to make decisions in autonomous mode. We also intend to utilise a distance sensor and an image sensor to create a 3D object that can be used to detect objects and determine their distances. We are also planning of working on object detection using deep learning on simulated environments with different backgrounds.
Our Learning Journey
We extensively used the MATLAB, Simulink and Simscape Onramps to get started with the tools. We then followed videos from MATLAB and Simulink Robotics Arena(especially the ones on Physical Modelling). These helped us a lot to get an idea on to get started with the design of our robots. Even though our robot is manually controlled this year, we are adding our efforts to make our robot do the task autonomously in the coming years. And the MathWorks tools would play a major part in our journey.
We would like to thank MathWorks for creating tools that helped us proceed with the design of our robots even though we could not always be in proximity to our hardware.