Good morning everyone,
Myself and one of the other engineers at my company have been investigating DriveWorks for the purposes of improving on our current autonomy solutions for industrial material handling vehicles (forklifts). Some of this was inspired by ZF’s CES press release ( https://blogs.nvidia.com/blog/2017/01/04/zf-ces/ ) which mentions (for the first time) that NVIDIA and/or ZF may be interested in supporting material handling vehicle applications in addition to automotive applications.
We were granted DriveWorks SDK access through the developer program application system in late January. So far, our effort has led to more questions than answers.
First - while it is understandable that DriveWorks is heavily biased towards running with DRIVE PX 2 hardware, this makes it difficult for companies who are “testing the water” for evaluating DriveWorks’ suitability. The PX 2 is a significant investment (I’ve heard a number around $15k) into an unknown technology. Given the question posed at https://devtalk.nvidia.com/default/topic/991426/drive-platforms/how-to-record-h264-compatible-with-drivenet-lanenet-object-tracker-from-a-usb-camera/ we’re not the only ones that are looking to do an initial evaluation on more “commodity” hardware (such as a laptop) prior to moving to a more robust embedded solution. In addition, NVIDIA is relatively unresponsive when it comes to questions regarding the PX 2. (I’m getting the impression that, despite ZF’s press release, NVIDIA is not actually particularly interested in material handling applications, given how hard it has been to obtain further information.)
Second - why are sensor drivers baked in to the monolithic DriveWorks library, as opposed to being handled by some sort of plugin system? This makes it impossible for any potential DriveWorks user to add support for additional sensors without NVIDIA’s involvement. As we’re an application that is not in NVIDIA’s core target market for this technology, this is a showstopper for us that makes DriveWorks too risky to investigate further. Specifically - Laser scanners from SICK such as the S300 series are dominant in our industry, but DriveWorks has no support for anything in SICK’s product lines (such as the RS-422 output from an S300 Professional - https://www.sick.com/us/en/product-portfolio/opto-electronic-protective-devices/safety-laser-scanners/s300-professional/c/g187237 ) and there’s no way for us to add the support ourselves.
Third - In our application, we requested Linux SDK access as we anticipated that most of our work would be done on Linux systems. However, occasionally being able to run the demo samples on a Windows machine would be beneficial. The DriveWorks developer page states to contact our account manager for other variants of the SDK - however anyone who applied via the developer program route does not have an account manager (Enless you have an account manager named noreply? I find this highly unlikely…). Access to these forums is the first time in nearly a month that we’ve had anything resembling a human we might be able to talk to.