As you may know, at JOYA Team we specialize in AR optical systems design.
We have worked on many VR and MR systems in the past, but every project has its specifics, and we always apply our creative minds to extract what’s needed and put our experience to use for the current customer, the use-case we’re trying to cover, the scope of work, the ideas that our customers want to explore. So, every project is a journey.
VR System in Medical Application
Here is a project story of a VR system for medical use, especially concentrating in the ophthalmic world.
It’s very common that in the beginning of a new project, we learn the application field, we have many in-depth technical sessions with the entrepreneurs or project technology lead to learn the connection between their expertise niche knowledge and the application, which is our knowledge in the optical field. Many times, the exact engineering terms are language has gaps and we try to close these gaps in order to create a common basis on which the project stands. The medical application details need to be translated to the corresponding terms in the engineering field. This stage is crucial for the project and product development.
Project Starting Point
Often a customer comes to us with a plan in mind, a system architecture or a prototype that they already have, or even several prototypes that they made during the first stages. When we start working, we question all the assumption, just to be able to optimize and propose most efficient ideas. We have our vast experience in hand, and we want to utilize it, to make it work for our customers. Sometimes, we suggest changing the architecture, adding or switching elements or technologies that are used, and not just following the plan for its sake. So, the customers that are open to challenge their concept, ideas and assumptions can gain something that can upgrade their solution using our mind boost.
Dead Valley: How to Build a VR Spec
We often face a bottleneck in a project of optical system development to be engineering spec formation. In every case, it’s a different use, application, innovative idea – since we primarily work with startups it’s always something that have never been done before, so often the spec is not clear at the beginning. It’s only the basic guidelines that we understand by asking questions. So, our job is the translation of the story, the functions that this product has to provide and writing down an engineering spec, with the correct optical terms, and numbers. We know that most of the numbers are arbitrary in the beginning, but we can help to understand when and in what order the numbers have to be validated.
Tools for Spec Validation
In the first stage, we have a guideline spec, where we address all the parameters that need to appear in a spec, need to be considered in the system design and engineering process, but we don’t have all the numbers figured out.
Then, we define the key design parameters that have the most crucial impact on the design. Some of these parameters we can quantify using our experience. So, we cover those first.
Then, we can suggest a validation testing using some simple setups that can help validate and quantify the key parameters. We use our expertise to create the validation setup or an optical POC with minimal investment: using our assets, some components that we have in our lab, some purchased products, off-the-shelf products and elements, whatever can be put to use with minimal effort.
In our experience, calculations and white board drawings can take you only that far, having something you can see and use in the lab – is so much more valuable.
Iterative Design Process
The engineering spec is an important deliverable, and many companies use it as an asset. When the initial spec is ready, though, there are a lot of question marks still open (the TBDs [To Be Defined] and TBRs [To Be Reviewed] can hang there for a while...)
We see the spec as a design tool, that lives together with the design and is updated, changed, and finalized along with the design maturity. There are many design decisions in the process, trade-offs between different parameters, some constrains coming in, some compromises, cutting functionalities to meet deadlines and milestones... The development process is a living organism and so is the spec.
Optical Design Tools
The design trade-offs are often done using some conceptual design of several options in Optical Design tools such as a Synopsys CodeV software that we use in our work. This conceptual design helps to see how certain parameters affect the performances and helps to visualize the concept, see the size, evaluate different options and communicate them to the team and to the decision makers.
Deliverable: Working POC in Surprising Time Frame
Spec document is a valuable deliverable, but nothing compared to a working POC that can be evaluated, tested, some parameters can be measured and used in spec requirements validations, some use-case tests can be examined, concepts evaluated and tested. Closing a loop of design iteration and learning from it is extremely important in the spiral of the development process.
The value of a POC is evident not only in the development process, but also as an asset that can be used for investors to reduce risk and communicate the project functionalities and as deliverable in investors milestones.
So, our proposition to build a POC was met with enthusiasm and the results exceeded every expectation: we were able to build a POC based on what we had in our optical lab that proved the design idea and the use case could be tested within unprecedented time frame.
Concept Verification
In this project, we proposed a certain technological solution, a short-cut that was based on our experience in the field. This solution allowed to eliminate a sub-system that was defined and the most high-risk component. We proposed a different way to cover the required functionality. We also provided the tools to test this concept using the POC setup and validate the idea.
Based on this experience, we also opened a door and possibility to review other concepts and components of the systems.
Most important, we created a value of cooperation and trust, working tools to examine new ideas and a basis for iterative development process.
Startups Reminder: Time is Money
Every startup that is short in funds, namely each startup, tries to save money by cutting down spending it. This is a common mistake that we see all the time...
Actually, when you spend money on the right team of experts, you’re able to get results and valuable deliverables, meet milestones in shorter time. This means, that you save money, because the expenses to keep startup running always exceed that, and the most common problem of a startup is running out of funds before they manage to raise the next round.
When working with team of experts that have the expertise that you lack, that push your startup forward, and work only on what’s needed and when needed – that’s how you survive and keep going.
Boost Your Design Team with Experts
JOYA Team is here for the startups that think fast, decide smart, take risks and believe in teamwork and cooperation.
Comentários