ETA on next driver/SDK?

edited July 17 in Developers
@hettylool I've taken the current driver/SDK as far as possible, and I'm not happy enough with the results to release any software supporting NoloVR yet (currently I have iVRy SteamVR driver for iOS/Android mobile headsets and controller-only driver for SteamVR headsets that do their own tracking eg. Oculus DK2).

I'm going to put this on hold until the issues I've raised in the Windows SDK Github are resolved/addressed. Please let me know when you have something for me to test.

Best regards.

Comments

  • It has been a bad month for nolo, with people complaining about not getting tracking numbers, cos of their own ignorance for not reading that their phone number was needed, lots of feedback etc.

    But I agree, I was expecting updates to be a little faster.
    But they are still a small startup atm.
    And communication has been rather lacking since shipments started. Maybe too many repeated emails from people demanding tracking numbers and sending 10 emails each day for 3 weeks.
  • iVRy don't stop. Your doing such a good job. We need you to get this working :(
  • Keep it up! I believe in u.
  • Thanks, but I've hit bugs/limitations in the driver/SDK that I can't work around. Got other fish to fry, will come back to this when some bugs are fixed. AFAIK the driver developer is traveling ATM, so I expect there will be some action soon again.
  • All of those are a little bit deeper; they require firmware updates at least, unless you're willing to make do with extrapolated velocity values from 60Hz reports (which will require working around the current double and corrupt reports, which are firmware bugs). I haven't taken a controller apart to see if it even has the hardware for analog trigger. As firmware changes go, reporting the orientation state (whether it's zeroed, flipped, whatever) shouldn't be hard. 
  • @LoneTech Thanks for the insight, and yes they probably do require firmware updates, but are necessary nonetheless. I'm already dealing with the double reports, but am interested to know how one could detect the corrupt reports. I am extrapolating velocity and acceleration from the position values, but even with a Kalman filter they are very noisy (and the Kalman filter removes the possibility to do far/quick throwing actions). The trigger (if supported by hardware) is a nice-to-have, not a deal-breaker.
  • edited July 18
    I don't know if the first party driver passes the corrupt reports (or more accurately, how often). The corruption happens when the firmware overwrites a report while encrypting it (which itself is a complete waste), and isn't detected by the checksum which is USB layer (that detects cable errors, and unfortunately the long cable included with the Nolo is somewhat unreliable). In my OSVR driver, the corrupt frames are unlikely to lead to reports because the risk they'll still match the hardware and firmware version numbers is very small (about 2**-31 per corrupt frame, and those themselves only occur every 15s or so). Corrupt reports are complete noise (due to the encryption), so might well report positions the hardware physically can't, like large X/Y with small Z (the field of view is roughly conic). 

    The good news in all this would be that most of Nolo's smarts actually is in firmware. If we do get these fixes they should apply easily for all platforms. 
  • @LoneTech Thanks, so it appears that you are bypassing the Nolo runtime and dealing with the USB communications yourself. Is there any particular reason, apart from the obvious of not dealing with an extra layer of, at this stage, quite buggy and cumbersome software? If so, are you reverse-engineering or is there some other info available on the Nolo hardware?
  • @LoneTech Nevermind, found your repo, so it appears you're developing for Linux. So, are you having much success in getting that working? And yes, what exactly is the point of the encryption? To force you to use their software? Why would they even care?
  • edited July 18
    My first target is indeed Linux, but a major point of a free software driver is that it is portable. Other platforms can use it as well, and I'm hoping at some point to bring up both OSVR on Android and WebVR with this stuff. It has been tested on Windows also, and the driver works. I haven't tried other orientation modes than base station in front. 

    I did reverse engineer to create this driver, by both protocol decoding and analysis of a driver blob. The ironic part of it is, even under restrictive law like DMCA, by implementing this encryption layer LYRobotix have made it more legal to do so, not less, because it is now required for interoperability. Also, the data they're obscuring isn't theirs even if it is copyrightable. 

    My best guess about the encryption is some executive decided LYRobotix could put their tech in a consumer device on the condition that the device wasn't too flexible, so industrial customers would need to buy directly. They then tried to achieve this by working against themselves as well as their customers. It's similar to the Kinect's ties to Xbox, but less directly evident as the Kinect could be subsidized by game sales. 

  • edited July 18
    [deleted]
  • @LoneTech Thanks for your input, and for fighting the good fight :wink: 
  • It's a translation issue; many don't see the difference between a tech demo binary hack and a robust portable driver. At this point, I'm glad Nolo shipped, because there's some solid functionality already. As you've noted, a firmware update exposing a few more variables could improve it drastically. The driver and software side might be best served by reimplementation, but we're now at a point that's at least an option; compare Sixense that just never ship. 
  • edited July 18
    @LoneTech The hardware seems good, and as you say, could be useful with a few fixes/additions to the firmware. To be clear, I don't see it as being a marketable product in its current form, merely a proof of concept. I can't support a product like this (in its current form) in my (software) product, because the lack of quality ultimately reflects on me, not the company selling the (hardware) product (like for example, if the user has to double-click the system button on both controllers to get the orientation working correctly in some instances that my software has no knowledge about, it appears to the user that my product is faulty, not the hardware).

    Unfortunately, companies like LYRobotix and Pimax have good hardware let down by poor software, but are not willing/able to provide enough information for anybody to reimplement anything. In the case of Pimax, they reached out and offered to employ me to do that exact job, but weren't willing/able to give me the source code/information to actually do it (even under NDA). One wonders how they hoped I would do it, reverse-engineer their product like you have done?!

    Same goes with LYRobotix (I already asked for details on their protocol, and was refused, as is their right). What these companies fail to realise is that in order to market their products world-wide, they need to provide a quality solution from the hardware all the way up (including a well documented API with good examples), and failure to do that will leave the market open to someone else who does, and expose them to bad press.

    They really need to understand that when they have experienced developers willing to help them improve their product, they should be welcoming them with open arms and doing whatever is necessary to support them (within the limits of what their policies allow), because the less they do that the less opportunity they will have for external review.

    The impression I get, hopefully incorrectly, is that it's all about getting the customer to buy the product, and not about what happens after that, so all that is necessary is a tech demo, and there's little interest (or perhaps ability) in making a robust product. Obviously that kind of business plan falls flat if you ever want to retail your product in the US, as customers will return products they are not happy with, which will ultimately lose you more than just a missed sale.
  • I feel like it could be an Asian thing. I know many Japanese game devs refuse to use existing game engines simply because it's not "theirs", though that seems to be changing a bit lately. I hope LYRobotix will change their ways too. Just because you have some outside guys to help your work doesn't mean it's shameful or something.
  • edited July 18
    @ben I don't believe it has as much to do with race/culture, as the lack of intellectual property rights in some countries (I can't speak for the reasons behind use of or not of gaming engines), where effectively you don't have any (enforceable) copyright, so any trade secrets (are perceived to) need to be heavily guarded or someone else will steal your idea and possibly your manufacturer and undersell you based on the fact that they don't need to pay for the R&D. But really, who knows (or cares)? The end result is a less than optimal end product based on interesting technology that noone outside of a few very dedicated hobbyists can use, fix or tolerate. I do wonder where these kind of things end up, unused in a drawer, or maybe the bar for "good enough" is lower for some people. It's certainly a lost opportunity for those companies to break out of their local markets, and I would be extremely hesitant of purchasing any of these relatively cheap, "seems too good to be true" products, as the lack of ability to fix issues (or even have them fixed) is a major put off.

    I'm not walking away from Nolo quite yet, because the developers have shown a willingness to incorporate suggestions that improve their product and these are early days still. I guess I'm overly sensitive to this as this is by far not the first promising product that I've invested time into as a developer that was eventually shelved or otherwise made irrelevant before it got to the point of being what it was originally intended to be, or even in fact that usable.

  • edited July 18
    Coming from somebody who works in an software IT startup: They should simply open source (even under a license which only allows contributing but not using the code for your own software) the whole runtime - you can not use that anways without having bought the product. That would help Lyrobotix immensly on getting a more stable software without the need to dedicate a lot of workforce onto it.
  • @iVRy I see what you mean there with them somewhat responsive, but it declined SO much after initial release, and they seem to take forever to do anything 
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!