Inspiration
Our team has long had a passion for mixing the hardware, software and crypto worlds. We were often looking for creative applications for our work, and wanted to find new ways to innovate and build. The idea for G.U.R.T struck when we were having a conversation about ads we had seen on social media. We all noted the monotony, especially among games, with every ad virtually displaying the same game- of complete random chance, and poorly made. We felt like we needed something that would break this monotony. Seeing a new wave of strong projects in other hackathons inspired us to do something rather than wait for someone else to. We wanted to produce something unique- something that no one had seen before. And we believe that we have!
What it does
G.U.R.T. is a robotic tank that virtually plays a game virtually shooting at virtual enemies controlled by a player on a website. Players enter a queue together to fight with the same robot, attempting to get a higher score than other players within 60 seconds. Before a fight, they may wager SOL if they want a more challenging queue and potentially earn more SOL for winning in the process.
How we built it
We built one instance of GURT, with a QNX8 Raspberry Pi 4, PI camera, 3D printing and lots of wires…. Then to program the hardware we utilized google anti-gravity, to create a server and a client side (the Pi 4). Once the Pi4 QNX was configured, then we started getting it to work with precompiled binary since QNX did not have “cmake” or “make” built-in. We also managed to get some custom files compiled, which allowed us to heavily streamline the image transfer process.
Challenges we ran into
A ton of road blocks hit this project that we had to slog through: Solana wallet setup- Transferring funds between a “host” account and various user accounts How to efficiently detect QR codes without lagging the “streaming” system on the web server QNX Initial Setup QNX library accessibility Pi5 build of QNX 8 (at least without manually compiling all of OpenCV in docker) QNX figuring out a work flow for cross compilation QNX SDP licensing QNX qcc compiling on Windows 10 niche issue with name restrictions not allowing space in a forced install path to a user username containing a space. Serial IO with QNX PI camera not functioning and troubleshooting. Efficient image transfer with PI camera, to allow streaming to web server at high fps
Accomplishments that we're proud of
We are proud of a number of accomplishments within the project. Firstly, managing to get the client code working correctly, and able to transfer images from QNX was a big challenge, and a huge bottleneck. Achieving this was incredibly difficult, and required a lot of setup, but the code working allowed for efficient transfer, and allowed us to gain a much better understanding of the QNX OS overall. Additionally, building an application that contained Solana was a challenging task, as no one on our team had done any blockchain or crypto-related projects before. Our product being able to link with phantom wallets, and allowing individuals to potentially win or lose coins was a big step. Finally, getting an end-to-end working product. This was a very challenging project for both software and hardware, and getting compatibility was a huge step that we were very proud to achieve.
What we learned
QNX. We learned that there are a fair amount of restrictions compared to the common conveniences of Linux. But through trial and error and a whole great amount of help from the people at QNX we learned how we would get our programs to run on QNX and genuinely have QNX perform important client side functions. Functionally QNX seems like it would be very intriguing to work with in more integrated long term environments, but at least initially it comes with its frustrations regarding documentation and methods to perform what would seem like “normal actions” but otherwise end up being a large rabbit hole of try this or this doesn’t work. We also learned a lot more about Solana- how to create crypto accounts, wallets, how we can transfer funds, and how to mint currency (though we did not use this feature). We had never worked with Crypto before, so this was a very interesting experience, and getting the various components working together taught us a lot!
What's next for Ground Unit Response Tank (G.U.R.T)
We’d like to implement Player vs Player, with multiple remote move able G.U.R.T’s in an area fighting each other. Thus making the enemy interaction be more dynamic since we have other players live controlling the tanks. This produces expandability for more game modes and potentially a battle royale with the entry cost of SOL and a prize for top 3 placements being a division of the total funds. We were also initially discussing using a second camera and a google cardboard to add a FPV view for the robot, and also the option to choose and vary the types of cars, drones, tanks etc. through the use of software logic to control the possibilities provided by using a holonomic drive train for the robot.

Log in or sign up for Devpost to join the conversation.