Machine 

This week we have been working with integration of every sub-system to the actual system. This means that a lot of the work has been done by all of us together across the different disciplines, as you can see from the picture below. 

This has resulted in us needing to adjust all the components so that it all works together seamlessly.  So, in machine we have adjusted and created some new parts, some of which can be seen in below: 

When it comes to the parts that we hadn’t got yet last time, we can finally announce that the timing belt has come. Now the most critical part that is missing is the fans so we can get the airflow working. We have got one fan as mentioned in an earlier post, but we are uncertain if this will be enough to make any kind of effect on the game. This is not critical for showing that all the functions work, but as you can see from a video later in this blog the disc stops very fast because of friction. This is also caused by the plexy glass getting a lot of edges from the cut holes, so we also need to sand and smoothen it. 

Electro 

This week, in addition to aiding the other disciplines with integration, we have continued developing the code that controls all the actuators in the system; this time we have focused on implementing one function that is able to receive one coordinate through the serial port and move the stick to that position as fast as possible, coordinating both motors to generate smooth movement.  

As we are using two different systems with two different reference systems (Arduino for the electrical and mechanical parts and Raspberry pi for the computer science part) we need to convert the information received from the one to the other. Once the system knows the exact coordinate it has to move it, calculates the number of steps and the speed at which it has to perform them to realize as smooth movement as possible. 

The biggest problem we found is how to implement the movement of the motors while the program is still running and controlling other things. The easiest idea that came to our minds was to use timer interruptions with variable timings to be able to change the frequency of the pull signal for the steppers motors, likewise managing to control the speed of the motors. But when we implemented it we realized that it was not as easy as we thought because the timer interrupts are not compatible with the serial communication in the way that we have implemented. To solve that issue we are trying to implement the serial communication in another way, but for the moment we have solved the problem of the motors using “our own designed timers” using the internal clock of the Arduino.  

Computer 

This week the computer engineering students have been working on implementing the theory from last week (where we calculate the deltas, find the slope, and use point-slope formula), as well as aiding with integration of the system, graphic design, and project management. We have implemented the new theory with a calculateTrajectory() function that takes care of the math, and a conditional statement to check whether the resulting coordinate lies within the boundaries of the goal (which are two variables that are pre-defined).

With some input from the electrical students, we realized that we could re-orient the camera to better fit the board, allowing us to shorten the bridge. This, however, meant we had to change a few things in the program (such as fitting the coordinate system to account for this change). Furthermore, we’ve determined the camera orientation as well as the corresponding coordinate system that will best work with the Arduino (which has a coordinate system of its own).  In the Youtube video below, we show a demonstration of our system so far, after we had shortened the bridge and adjusted our program to this. Note we have not completely implemented the computer opponent yet, but we’re getting close.

One thing we’ve discovered is that we were perhaps too early with defining what we thought we would need for our system, rather than what we actually need. For this basic defense implementation, we ultimately had no need for the angle and velocity calculations, two functionalities we spent a fair amount of time developing. It would have been wiser to agree earlier on exactly how we wanted the basic defense to be implemented, and focused on that only, rather than implement functionality that we foresaw to be useful for advanced defense, as well as attack. That being said, implementing the angle and velocity functionality was very rich in learning, so we do not consider it a waste of time, and in the event we want to progress our program beyond basic defense, we have these functionalities prepared. 

We have also implemented trackbars for the HSV color space to better define our mask, now that we are approaching true implementation and lighting conditions. This has been done in the same way as when we did the BGR trackbars, only this time for the Hue, Saturation, and Value. 

Furthermore, we have been working on graphic design for the logo, presentation and such. We want to keep it as a surprise for the final presentation so it will not be published here.

We spent a lot of time on administrational stuff such acquiring equipment, finding a place to work and moving the prototype (it is getting big and heavy) and more. There is always some administrational stuff to be done, but it is especially much as we get closer and closer to the delivery day. And then there always touch-ups and details such as painting more parts and so on. We also help each other across disciplines when needed.    

An important thing that haven’t been mentioned in the blog as often as it maybe should have been, but is still a big and important part of the project is the project management. One may not think of it as a big job but underneath it really is what keeps it all together. The importance of having an overview of the project and coordinating the resources is specially clear now as we getting closer to the final presentation and we encounter obsticles like needed equipment not arriving on time. 

Our team uses Agile methodology approach and has weekly Scrum-meetings. We use a project management tool called Trello where we divided project’s timeline into Sprints using boards. Every board include Sprint’s tasks. The tasks are then assigned to different team members and have deadlines as well as detailed task descriptions with attachments, comments, checklists etc.  

Trello boards get reviewed in the beginning and the end of every sprint where tasks are added, edited, assigned or moved to “In progress” or “Completed”. Every team member is encouraged to update ongoing work by marking, commenting and moving the assigned tasks to keep track of the progress.

This aspect of the project is also time consuming and takes some of our resources but it is well worth it! Good planning, intermediate goals and a big-picture-view is the key to success!