Week 1, Sep 21
We are still debating between using the cartesian gantry/robot or an omnidirectional robot for our receiving system. This is a big decision for the project as a big portion of the design rests on which type of robot we choose, so we took some more time to look into the pros and cons of both but this time on a more technical level. We thought through exactly what we would need for the gantry and the omnidirectional robot, looking up numerous guides online for how other people used both systems. Despite our research, we still could not make the big decision of committing to either one. We’re trying to make a decision soon, and build a small prototype of whichever model we choose and verify the feasibility.Â
For the cartesian gantry, there are a number of existing guides available online, some more detailed than others, that detail hobbyist implementations of cartesian robots. However, when reducing the scope by affordability and complexity, a couple guides remain, which are both XY plotting/drawing robots. Assuming the bill of materials are correct for these guides and assembly doesn’t turn out to be horribly difficult, we would need to modify the existing arduino code for our purposes, which is heavily reliant on GRBL. Alternatively, if we can manually generate a g-code file that instructs the machine to move to position (X,Y), we can use the code as is.
For the omniwheel robot, there are two especially intriguing guides that show the construction of a 4 and 3 wheeled drawing robot respectively, both by the same creator. A cursory look at the attached arduino code suggests it would require less re-tooling than the XY drawing robot’s, as there are already functions for GOTO XY position written. This would involve interfacing the Kria so that it can communicate the landing position of the robot to the arduino, and then it can run this GOTO. To return the robot, run GOTO 0,0. This also begs the question of whether the robot can be controlled directly by the kria, or if we have to add an arduino to control the robotics.
In any case, I think it should be feasible to pursue one method, determine if it’s promising, and if not, return to the other robot. Both are within the budget.
Another avenue that we are considering to take for the robotics side of things is to obtain our microcontroller first (probably arduino) and mess around with that to ensure that the latency of integration will not be a huge issue. Getting our hands on the microcontroller portion of the receiving system early could be good, as if any unforeseen problems pop up we can solve sooner. It’s also important to check the latency requirements so we can make adjustments to other parts of our system if needed, and it’s easier to make adjustments earlier in the design process.Â
Regarding the camera / CV system, we are deciding between the exact camera to use. The most significant risk in this part is that the camera system cannot accurately calculate the landing coordinate of the ball, therefore this week we are spending time to design and choose a system that can achieve this using the most appropriate array of sensors. A close second risk is regarding latency of getting the calculations out in real time. Therefore, more research was also done this week regarding the exact sensor requirements, the sensor output information we can acquire (e.g depth, velocity measurements) and combine that with the appropriate system of algorithms and CV models so we can actually calculate the ball’s landing coordinate position. Further considerations are made to reduce the total amount of latency of the algorithm portion so that we can optimize for anything computationally expensive to be offloaded to be implemented on the Kria board.Â
We haven’t made any changes to the design of the system. However we did change our schedule, as our original gantt schedule did not include fall break and thanksgiving break.