Hardware & Sofware: design and Hardware & Sofware: design and implementatonimplementaton

Andrea RanieriAndrea Ranieri

HardwareHardwarePart 1Part 1

HardwareHardware

● What's the purpose of designing and developing new hardware components for UMVs?

● Each component basically has to solve one (well, sometimes more than one) specific problems:

● engines and controllers provide propulsion● sensors provide data● computing boards provide processing capacity to coordinate everything

HardwareHardware● Design of new non-trivial components is essential● It allows to carefully plan and somehow “simulate” the purchase/development process:

1. formalize the requirements2. do a make-or-buy decision3. design an “alpha-prototype” on paper4. see if everything fits mechanically and electrically into the UMV (and maybe into the other UMVs)

● simulate unit tests and integration tests5. goto step 1 and refine until error < ε

HardwareHardware● Use case:

● build a high performance Computer Vision system to be mounted on a UMV.

● Step 1: requirements● what does it mean “high performance”?● in the context of UMVs, where hardware is usually close to industrial-grade specifications, “high performance” may be everything >= to a decent desktop computer

● able to do advanced processing on HD stereo images at high FPS.

HardwareHardware

● Step 1.01: rule out impossible requirements● no LIDAR underwater

● underwater LIDAR systems exist but are way too expensive

● no Kinect (no IR underwater)

HardwareHardware

HardwareHardware● Step 2: make or buy? It largely depends on the underlying technology.

● BuyBuy:● the process is “fast & easy” if the technology is reliable enough

● usually costs less money than R&D + parts● sometimes the software is already available, working and tested

● if the component is backed by a big open-source community -> 90% of work is already done

HardwareHardware

● Step 2: make or buy? It largely depends on the underlying technology.

● MakeMake:● the process is slow and usually expensive (both in parts and in effort)

● if the technology is bleeding-edge, “disruptive” or niche market, it may yield substantial savings or even a profit

● both hardware and software will be “taylor-made” for the application.

HardwareHardware

● Step 2: make or buy the stereo camera?● definitely buybuy (and go mainstream)

● Bumblebee XB3 is relatively inexpensive● lot of software and functionalities already available

● a large community of users● tech specs may be better● firewire is a pain in the ass

HardwareHardware

● Step 2: make or buy the high performance mini-pc?

● Raspberry Pi 3, ODROID-C2/XU3 are not enough

● Intel NUC CPUs are fine but NUCs can't be upgraded and their GPUs are not so fast

● Best long-term solution: makemake a high performance mini-pc

HardwareHardware

● Step 3: “alpha-prototype” on paper

Firewire underwater cable

Powerful i7 mini-pc, with room for additional GPU

Bumblebee XB3 (very compact)

HardwareHardware

● Step 3: “alpha-prototype” on paper● Mini-pc i7 specs:

1. Intel Core I7-6700K2. ASRock Z170 Gaming-ITX/ac3. 2x8GB DDR4 3733MHz LPX4. Samsung 256GB SSD SM951 M.25. StarTech Mini PCI-Express to FireWire adapter

6. [Leave room for an additional GPU]

HardwareHardware● Step 3: “alpha-prototype” on paper

● Mini-pc i7

HardwareHardware● Step 4: see if everything fits mechanically and electrically (and thermically?)

● the PCI-Ex 16x slot is completely on the edge of the board -> the cylinder will be considerably bigger than the motherboard form factor

● or it won't be a cylinder at all?● or we could try another PCI-Ex extender

● when the cylinder is sealed, the system will probably produce enough heat to become unstable in air

● circuit partitioning and power on via SW

HardwareHardware

● What's next?

HardwareHardware● GPS● Laser scanners

● dense 3D point cloud “colored” as seen by the laser: intensity of echoed infrared laser beams

● Radar● small radar arrays mounted around the side of the vehicle

● Odometry● wheel encoders

● Inertial data● accelerometers● gyroscopes

● Acoustic data● proximity

● Visual data● cameras

HardwareHardware

● Obviously, we can't compete with Google, if only for the budget

● But we can try to copy● Google cars has about 150k€ in equipment and uses 70k€ Velodyne HDL-64E as LIDAR system

● On the sea surface and in air, we could use Velodyne VLP-16 ~= 10k€ overall

Google LIDAR Navigaton System

HardwareHardware

● Questions?Questions?

HardwareHardware

● Questions?Questions?

SofwareSofwarePart 2Part 2

SofwareSofware

● What are the differences with hardware?

1. Software is intangible● It's hard to understand its development effort

2. Software is easy to reproduce● Cost is only in its development● In other engineering products, costs are in manufacturing

3. Software is labor-intensive● Hard to automate● Only prototyping and testing can be successfully automated

SofwareSofware

● What are the differences with hardware?

4. Software requires highly specialized workforce● Untrained people can hack something together● Quality and performance bugs are hard to catch

5. Software is easy to modify● Developers often make changes without full and detailed

knowledge of the code● PROs: abstraction and encapsulation (information hiding)● CONs: unexpected behaviors

6. Software does not “wear out”● It deteriorates mainly by having its design changed:

● erroneously● in ways that were not anticipated

SofwareSofware

● Much software has poor design and it will get worse if not rewritten from scratch

● Demand for software is always high and rising

● We are in a perpetual “software crisis”● We still have to fully learn to “engineer” software

● We still have to fully learn how to package and distribute software

● Linux software packages and ROS packages are good examples, but there is margin for improvement

SofwareSofware

● Today software has become way too complex to fit entirely in one head

● or to be written by one or a few people● At the end, the process of engineering software is just a matter of:

● recycling other's work● “trusting” libraries and frameworks you're using

● (optional, but highly recommended) - repackage and make open-source for others to improve your work

SofwareSofware

● Focusing on C++, there are only a few major portable SW components

● Standard Template Library (STL): part of the C++ ISO Standard itself, almost bugfree

● Boost Libraries: free peer-reviewed portable C++ libraries, very few bugs. Cyclically, Boost features are ported into STL (smart pointers, threads, lambdas, etc.)

● Qt: cross-platform framework (UI, networking, DB, etc.), the graphical part is in continuous development (= a little bit buggy)

● OpenCV: imaging and computer vision● Crypto++: cryptography and security● ROS: middleware framework for communication,

visualization, packaging and many other tools/libraries for C++/Python development

SofwareSofware

● For anything else not covered by these libraries, one has to:

● search for smaller, less actively developed/maintained libraries

● write the code himself

SofwareSofware

● Enter ROS!● ROS opens the way to a huge amount of very well written (and tested) software packages

● The shortest term advantage is on sensors

● GPS, camera, LIDAR, multibeam, IMU, Kinect, Leap Motion, etc. etc. etc.

● The long term advantage is to have a distro-like packaging and distribution system that speeds up the software production

SofwareSofware

● Let's see a few examples:

● Example 1 - Mono odometer - used with an old analog camera acquired @ 720x576 - compared with Teledyne DVL (Doppler Velocity Log).

● OpenCV with SURF feature detection and extraction

● PROs: detection and extraction is ready to use, easily portable on GPU

● CONs: rotation-invariant - (need to move to ORB?)

SofwareSofware

● Let's see a few examples:

● Example 2 - ROS Leap Motion driver + OGRE-based libHand

● ROS Leap Motion driver is ready to use● Needed to repackage and made libHand compile● Leap Motion data is very noisy -> kalman filter● No physics of the hand or constraints on the joints