Posted on

Joseph’s Status Report 4/29

This week I spent time trying out different methods of how exactly anchor points are set during the game. I tried having the anchor point set at the start by the user when tapping the screen and not changing and having the anchor point set whenever the user taps the screen. From user testing, the latter method seemed more user friendly, as the extra flexibility in placing the object seemed to outweigh the accidental screen taps. I also changed and tested various different parameters I coded into the line algorithm (# of corner and end vertices in the line, distance between each point in the line, line width, etc.), in order to see which parameters produced to best formed line. This testing gave me a good idea of the good range of values, but further testing will have to be done with this once the data sent over by the hardware is perfected.

Due to the revamp of the multiplayer aspect, the pure software side I’ve been working on is on schedule. But as a whole, our project is a little behind schedule, only due to some of the data being sent over from the hardware being a little off. No changes to our schedule are happening, we are simply trying to get the hardware data to be completely fine by demo day so we have a functional game.

This week, most of our time will be spent on the final assignments, those being the final report, poster, and video. Other than that, once my teammates are done stabilizing the hardware data sent over to the software, I will further finetune all the separate software parameters in the line algorithm renderer.

Posted on

Sophia’s Status Report 04/29

This week, I spent a lot of time trying to refine our pen data so drawing lines would be more refined. Unfortunately, while there seems to be some semblance of direction being derived, we cannot seem to make the z-coordinates stop changing (due to under or over compensation of the force of gravity). Aside from trying different approaches of calculating position such as taking the average of acceleration rather than an instantaneous point of acceleration, none seem to work any better than the initial method of a Kalman filter with quaternion rotation and double integration. Because of this, I am leaning towards sticking to this method and trying to tinker with the calibration settings. Additionally, this week, I tried to finalize our board by soldering our Arduino and components to a PCB that was given to us. Unfortunately, the one we received was a touch too small, so I will likely be trying to find a larger one or purchase a new one that will hopefully arrive soon.

As of now, I am falling a little bit behind schedule as ideally now the hardware would be completely finished. However, I just mostly need to solder everything together at this point, which ideally shouldn’t take too long.

Next week, I will spend some more time writing our final report, creating our poster, and creating our video for demos. There will also be some time spent on soldering, but that should be a quick task.

Posted on

Team Status Report 4/29

The current risks that could jeopardize our progress is if we are not able to figure out how to get cleaner data from our IMU in time for our final Demo. We are managing this by considering alternative so that our project will be able to be at least semi functional by the time we complete our assignment.

Some updates were made with regards to multiplayer and the way we will be implementing our hardware. Since there were issues with getting our game to show for multiple devices, we have updated our design to only display on one device, and screen share to a larger screen. This had to be done do to issues that came with implementing this design choice, and the little time we now have to fix them. Although it will make the experience less enjoyable, it will still be playable and fun regardless.

The main tests that were done were latency tests, which were done by adding time stamps to our code and determining how long on average it took to run that section of code. For our pen for example, we added this time stamp at the beginning of the loop and at the end of the loop and took the difference to determine how long this calculation took. After running this test for 100 iterations, an average was taken to determine the average latency for our pen. Additionally, there were line accuracy tests performed by drawing an arbitrary line on a sheet of paper and then trying to trace over it. We tried to identify the percentage of line that was covered by physically measuring the length of line was uncovered by the AR line. We also did some user testing by asking a few friends to try out our pen and rate how they felt our pen was. Overall, the results of these tests were that our latency and overall communication speed for our project is up to par. However, our positional data from our pen is severely lacking and mostly non-functional. As addressed in Sophia’s status report, there have been several attempts to try to fix this problem, but to no avail.

No changes to the schedule have occurred, we are currently just working harder to get everything done on time

Posted on

Anthony’s Status Report 4/29

This week me and my group was mainly focused initially on doing well for the presentation and giving the presentation. I was required to present this week so I spent a lot of my time practicing to make sure my presentation went smoothly. When our group was not working on the presentation, I spent my time trying to assist Sophia on the hardware pen, and try to get cleaner values sent over to the unity project. I also spent some time trying to figure out ways to clean up the data values being sent over. Even with our best efforts we were not able to make much progress, and because of this, I did some research for potential alternative implementations.

We at this point are still somewhat behind. We managed to accomplish all the tasks for the most part on our agenda, the issues is we simply have not been able to get them functioning well enough to make our game playable. To catchup to a finished product, we will simply have to put in a lot of work before demo day to make sure our final product is presentable and usable.

This week we will be working on our final report, poster, and video, and in addition to this work towards trying to get a playable game for our final demo of the project.

Posted on

Joseph’s Status Report 4/22

This week, in addition to working on the final presentation slides, I added the ability to clear all rendered lines from the screen in order to “start over” as well as added an on-screen debugging log for easier troubleshooting and game status tracking. I have also written out and finally been able to get to work the scripts that get cloud anchoring to work on one device, in a separate test game scene (not our actual game scene). What would be left would be to integrate this cloud anchoring into the previously written line algorithm scripts and main game scene, as well as use Unity’s networking package to get the cloud anchoring functional across multiple devices. After that, finetuning of the timing of API calls would be necessary.

Considering that we effectively only have 1 week left of classes before finals week and are still having a little trouble fully integrating the hardware and software (improperly formed/calibrated data is able to be sent over from the hardware and rendered by the software), I have looked into backup options of viewing our game on multiple devices. This is due to the fact that even if a fully functional multiple device cloud anchoring was able to be coded in this last week, we would have to worry about not only integrating this software with the hardware on a single device, but across multiple separate devices, which would require even more code to be written in order to separate game states, and actions between separate users.

Due to the unfeasibility of all of this given the remaining timeframe, I have instead gotten to work a way of screen sharing our game running on our host android device to another device/laptop that would be displayed on a big monitor. This was done with an application called TeamViewer, which allows one device to be used as a host and other devices to hook into this device and view what is being displayed on it. Therefore, all users would still effectively be able to see what is being drawn in the real world and guess in real-time, and the drawer would simply be changed to whoever holds the host device and pen.

This change would work towards putting our project as a whole back on track, allowing us to have a refined and functional project by final demo time. This week I plan to help the team with refinement of the line rendering algorithm that takes in the data gotten from the hardware as well as thoroughly test and refine the game as a whole into an easy-to-use and smooth experience.

Posted on

Anthony’s Status Report 4/22

Personally this last week has consisted of a lot of troubleshooting with our hardware. After switching from uduino software to bluetooth software, it required starting the whole process of trying to connect the bluetooth module and processing the data being sent in unity so it could be used effectively by our game. Initially the bluetooth module itself was refusing to connect to anything, but after some trouble shooting, it eventually was able to work. It then required some steps to figure out how to get it to connect to the unity project, and the phone application. This also required figuring out how the bluetooth unity packages functioned in order to code them in our project. This was eventually resolved, and I was able to get data to be sent, but what followed was figuring out how to strength the bluetooth hardware in order to remain connected when sending data to our application, because it would disconnect frequently when first initially synced. Eventually I was able to stabilize this by simply adjusting how much data was being transferred over, and changing the voltage supply to the bluetooth hardware.

In terms of progress, we are somewhat behind since, even though integration is for the most part completed, we have not been given the chance to do thorough testing with our game, since we have only been able to get it to work recently. In order to get caught up, we will simply have to put in extra amount of time in order to make sure we can get some tests in before our presentations for this week.

Next week I hope to be able to help Sophia figure out how to stabilize the data being sent from our pen device, since currently the data being sent is not very clean. We also have not been able to make our app UI very user friendly, it is still in the testing phases, so the next plan is to make it more intuitive for our users to navigate, and make it look more like a finished product. I may also try to help Joseph with cross platform code, so we can also get our system working on multiple devices, as originally planned.

Posted on

Team Status Report 4/22

Currently our project is at risk of, in general, not functioning to MVP due to some setbacks we have had with hardware integration and implementing cloud anchoring + networking for use with multiple devices. These risks are currently being addressed as we try our best to meet our set deadlines in the project. If needed, there are some backup implementations, where we can use other methods to achieve a similar effect, like screen sharing or sending position data using the touch screen.

One of the major changes that we made was our shift to using Arduino system and bluetooth instead of using wifi, since there was much more stability ensured with our Arduino and the bluetooth hardware we choose to use (HC-05). This also meant using different bluetooth packages with unity instead of the uduino packages we were using previously. This change was necessary since it actually had compatibility with android devices, which was where we were trying to eventually build our final product.

The other major change we have made is the replacement of cloud anchoring across multiple devices with screen sharing across multiple devices. This would be done by screen sharing our host android device to another device/laptop that would then be displayed through HDMI cord on a big monitor. This was done with an application called TeamViewer, which allows one device to be used as a host and other devices to hook into this device and view what is being displayed on it. Therefore, all users would still effectively be able to see what is being drawn in the real world and guess in real-time, and the drawer would simply be changed to whoever holds the host device and pen.

These design tradeoffs would allow us to stay on schedule towards a mostly completed and functional project, while not taking away too much from the game and user experience itself. Therefore, our remaining amount of time before the final demo could be better used refining to perfection what we have already implemented rather than attempting to implement more stuff that may or may not work properly.

In general,  this week we spent some more time working on integration and our final presentation slides. Everything is mostly integrated from end to end, but there are still some kinks that need to be flushed out that are addressed and explained in further detail in our individual status reports.

Posted on

Sophia’s Status Report 4/22

This week I spent most of the time fine tuning our position data, helping Anthony integrate the our pen with our Unity App, and working on our final presentation slides.

After trying to compensate for the drift in our IMU as well as errors in rotation, I have decided that it would be easier to use built-in quaternions to be able to get more accurate rotational data. Additionally, I have added a calibration phase to before you can actually use the pen device in order to help reduce error. This seemed to have help quite significantly, but there are still some drift issues that need to be addressed.

This week I also helped Anthony work on sending our data over via Bluetooth. As of now, our Android phones seem to be able to display our hardware data properly. There are some issues with sending the data over as data needs to be sent as a string but then we need to reparse it to a float value to use.

I also helped work on our final presentation slides that will be presented in class next week.

As of now, I am technically on schedule because everything is integrated and has been fine tuned a bit. However, our testing and validation results are not as flushed out as we would have liked so we need to spend some more time to get more concrete numbers and stats.

Next week will be spent trying to make the pen look more neat by solder it to an Arduino shield as well as writing our final report, preparing for the final demo, and making our demo video. Additionally, if there is still time, I would like to try to fine tune our IMU position more to see if we can get it a little less finicky.

Posted on

Team Status Report 4/8

Currently, the main thing that will jeopardize our project is integration, just like it has been for prior entries. Since integration through wifi packages posed some issues this week, we have backup plans to use other packages, like bluetooth, to hopefully get the hardware and software connection integrated for our final product.

In terms of changes for our design, the main changes, if troubleshooting with wifi poses an issue, will be to simply use bluetooth instead of wifi to integrate the connection between software and hardware.

The schedule has only been slightly adjusted where the integration with hardware and software has been prioritized for sooner than later, which has worked to our groups benefit since we have run into a few issues with integration through wifi using the uduino package in unity. Everything else overall is on schedule to be completed.

Posted on

Anthony’s Status Report 4/8

This week our group was mainly focused on trying to get prepared for our demos. For this week I was able to work on trying to integrate our hardware component (the prototype version of our pen) with our current application (the unity software we have currently integrated). This attempt was made with the unity package uduino. I was able to make it work, but unfortunately, it was not able to function as expected with the unity application once it was dowloaded into the application. Since it was not actually able to function as expected with the build, we have decided to pivot slightly, and consult the alternatives we had planned for communication between our application and hardware.

Since we have updated our schedule, our current progress is not currently behind, but it is hopefully on track to get our MVP finished on time for our final submission.

This week, we hope to troubleshoot a little bit more on trying to get wifi connection between our application and our hardware to work, but will also try to see if bluetooth connection will be useful as well, since wifi poses some issues when trying to connect to the universities wifi. This will be the main focus for the week since integration has become our groups priority.