Source: https://www.subt-explorer.com/post/fall-2020-update

This is a new series looking at the detailed design of various robots. To start with we will be looking at the design of two different robots that were used for the DARPA Subterranean Challenge. Both of these robots were designed for operating in complex subterranean environments, including Caves, Mines & Urban environments. Both of these robots presented are from the Carnegie Mellon University Explorer team. While I am writing these posts, this was a team effort that required many people to be successful. (If anyone on Team Explorer is reading this, thank you for everything, you are all awesome.)

These posts are skipping the system requirements step of the design process. See here for more details on defining system requirements.

SubT Ground UGV and DS Drone ImageTeam Explorer R1 Ground Robot and DS Drone [Source]

R3 Ground robot (UGV)

For the SubT challenge three ground vehicles were developed all of a similiar design. The ground robots were known with the moniker of R#, where # is the order we built them in. The primary difference between the three versions are

R1 – Static Chassis, so the chassis has minimal ground compliance when driving over obstacles and uneven surfaces. R1 was initially supposed to have a differencing mechanism for compliance, however due to time constraints it was left out from this first version. R1 is pictured above.

R2 – Has the differencing mechanism and was designed as initially planned.

R3 – Is almost identical to R2, but smaller. This robot was built for navigating smaller areas and also to be able to climb up and down steps. It also uses different motors for the driving the wheels.

DS drone

The original drone design used by Team Explorer called their drones D1, D2, etc.. This let a combination of UGV +Drone go by joint designations such as R2D2. Early on, the team switched to a smaller drone design that was referred to as DS1, DS2, etc.. Where DS is short for Drone Small.

The drone design post are split into two sections. The first is about the actual drone platform, and the second is about the payload that sat on top of the drone.

Mechanical & wheels

Robot size decision

After we have the list of system requirements we start with the design of the mechanical structure of the robot. In this case we decided that a wheeled robot would be best. We wanted to have the largest wheels possible to help climb over obstacles, however, we also needed to keep our sensors at the top of the vehicle above the wheels and be able to fit in openings 1 x 1 meters. These requirements set the maximum size of the robot as well as the maximum size of the wheels.

The final dimensions of the first two vehicles (R1 and R2) were around (L x W x H) 1.2 x 0.8 x 0.8 meters (3.9 x 2.6 x 2.6 ft). The third smaller vehicle was around 1 x 0.6 m (3.2 x 1.9 ft) and designed to fit through 0.7×0.7 m openings.

Steering approach

Early on we also needed to determine the method of driving. Do we want wheels or tracks? Do we want to steer with ackerman steering, rocker-bogie, skid steer, etc.?

See here for more details on steering selection.

We chose to use a skid steer four wheeled drive approach for the simplicity of control and the ability to turn in place (point turns). At the start of the competition we were not focused on stair climbing, which might have changed some of our design decisions.

Suspension

The next step was to determine the suspension type. A suspension is needed so that all four of the wheels make contact with the ground. If the robot had a static fixed frame only three of the wheels might make contact with the ground when on uneven surfaces. This would reduce our stability and traction.

We decided early on that we wanted a passive suspension for the simplicity of not having active components. With a passive suspension we were looking at different type of body averaging. We roughly had two choices, front-pivot or side-to-side.

Left image shows a front-pivot approach. Right image shows a side-to-side differencing method.

We decided to choose the front-pivot method, however we decided to make the pivot be roughly centered in the vehicle. This allowed us to put all of the electronics in the front and the batteries in the rear. The front-pivot method we felt would be better for climbing up stairs and for climbing over obstacles on level’ish terrain. Also importantly this approach made it easier to carry a drone on the ground vehicle.

Chassis design

At this point we started designing the chassis. This was an important step so that we could estimate the total weight in order to spec the drive-train. Ideas for the chassis were everything from building with 80/20 to building an aluminum frame and populating it with components, to a solid welded chassis. We selected to use a welded steel tube chassis for the strength. We needed a robot that could survive anything we did to it. This proved to be a wise decision when the robot crashed or fell over cliffs. The downside of the steel was increased mass.

For the pivot we found a large crossed roller bearing that we were able to use to attach the two steel boxes together. The large bore in the middle was useful for passing wires/cables through for batteries, motors, etc…

Part of the chassis design was also determining where all of the components should mount. Having the batteries (green boxes in image above) in the rear helps us climb obstacles. Other goals were to keep the ground clearance as high as possible while keeping the center of gravity (CG) as low as possible. Since those are competing goals, part of the design process was to develop a happy medium.

In order to maintain modularity for service, each wheel module had the motor controller, motor, gear box, and bearing block as a solid unit that could be swapped between robots if there was any issues. This also allowed most of the wiring to be part of that block. The only cables that needed to be connected to each of the modules from the robot were power, CAN communications, and the emergency stop line; all of which were connectorized.

For electronics on R1 and R2 we built an electronics box that was separate from the robot and could be removed from the robot as needed. On R3 we built the electronics into the robot itself. This modular approach was very useful when we had to do some welding to the chassis post-build for modifications. The downside of the modular approach for electronics was that working in the electronics box was more difficult then in the open R3. Also the time for fabricating and wiring the R1/R2 electronics boxes was considerably more than the open R3 electronics. We also had several failures during testing related to the connectors from the electronics boxes.

Wheel design

We debated a lot about what type of wheel to use, ultimately we used motorcycle wheels due to the simplicity of obtaining them and mounting them. The wheel diameter we desired also lined up very well with motorcycle wheels. In order to get better traction and ability to climb over obstacles we liked the wider tires.

R1 and R2 had a wheel diameter of 0.55m, R3 had a wheel diameter of 0.38m. This gave R1 and R2 a ground clearance of 0.2m, and R3 a ground clearance of 0.12m.

The wheel hubs ended up being a different story. We found solid metal rims that we had to machine large amounts of metal out of in order to balance the strength and the weight.

The R1 and R2 robots were around 180kg (400lb)*, the wheels were for a vehicle significantly heavier. As such we put a small amount of pressure in the wheels to keep them from falling off, however we tried to keep the pressure low to increase the ground compliance of the wheels. This method added a very small amount of compliance, we tried removing some of the rubber from the sidewalls, but was not able to get a happy medium between limiting the wheel deforming during point turns and increasing ground compliance.

We were also concerned how the motorcycle tires would do when point turning and if we would rip the wheels from the rims. To counter this we installed a beadlock system into each of the wheels. The beadlock was a curved segment installed in multiple places to sandwich the tire to the rim. We never had a wheel separate from the rim, so our approach definitely worked, however it was a pain to install.

*R3 was around 90 kg (200 lbs). We tried using different wheels and tracks to get R3 to climb stairs well. However that story is for another post…

The black rims were solid metal that we machined the wedges into in order to lightweight them. The 3 metal posts in those wedges are the beadlock tensioning bolts. You can also see the castle nut and pin that holds the wheel to the axle. This image is from R2, you can see the gap between the front and rear sections of the robot where the pivot is.

Drive-train selection

Now that we had a mass estimate and system requirements for speed and obstacle clearance we can start to spec the drive-train. The other piece of information that we needed and had to discuss with the electrical team was the voltage of the battery. Different bus voltages greatly affects the motors available for a given speed and torque. We decided on a 51.2v nominal bus voltage. This presented a problem since it was very hard to find the speed/torques we wanted at that voltage. We ended up selecting a 400W 1/2HP motor+gearbox from Oriental Motors with a parallel 100:1 gearbox that allows us to drive at a maximum speed of 2.5m/s.

The part numbers of the motors and gearbox on R1 and R2 were BLVM640N-GFS + GFS6G100FR.

The part numbers of the motors and gearbox on the smaller R3 were Maxon EC 90 Flat + GP81A.

Next steps

Now that we know the mechanics of the robot we can start building it. In the next post we will start looking at the electronics and motor controls. While the nature of the blog makes it seem that this design is a serial process, in reality lots of things are happening in parallel. While the mechanical team is designing the chassis, the electrical team is finding the electrical components needed in order for the mechanical person to know what needs mounted.

It is also important to work with the electrical team to figure out wire routing while the chassis is being developed.

Note of the editor: This post has been merged from the posts “Hands On Ground Robot & Drone Design Series” and “Mechanical & Wheels – Hands On Ground Robot Design“.

The Intel® RealSense D400 Depth Cameras. Credit: Intel Corporation

The Intel RealSense cameras have been gaining in popularity for the past few years for use as a 3D camera and for visual odometry. I had the chance to hear a presentation from Daniel Piro about using the Intel RealSense cameras generally and for SLAM (Simultaneous Localization and Mapping). The following post is based on his talk.

Depth Camera (D400 series)

Depth information is important since that gives us the information needed to understand shapes, sizes, and distance. This lets us (or a robot) know how far it is from items to avoid running into things and to plan path around obstacles in the image field of view. Traditionally this information has come from RADAR or LIDAR, however in some applications we can also get that from cameras. In cameras we often get depth from using 2 cameras for stereo vision.

The Intel RealSense Depth camera (D400 series) uses stereoscopic depth sensing to determine the range to an item. So essentially it has two cameras and can do triangulation from them for stereo. This sensor uses two infrared cameras for the stereo and then also has an RGB camera onboard. So you can get 4 data products from the sensor; RGB image, depth image, left infrared image, and right infrared image. Think of each image frame as a 3D snapshot of the environment, where each color (RGB) pixel also has a range value (depth) to the item that is in the image. The farther the items are from the camera the greater the range/depth error will be.

The D400 cameras have an infrared projector for getting better features on surfaces with minimal texture in the infrared camera for computing the stereo reconstruction. This projector can be turned on and off if you want. Disabling the projector is often useful for tracking applications (since the projected dots don’t move with the items being tracked).

One thing to be aware is that the infrared images are rectified (to make the images look the same in a common plane) in the camera, however the RGB camera image is not rectified. This means that if you want the depth and RGB images to line up well, you need to manually rectify the RGB image.

Pro Tip 1: The driver has a UV map to help map from the depth pixel to the RGB image to help account for the difference in image sizes. This lets you match the depth to RGB image data points better.

Pro Tip 2: If using the D435i (the IMU version), use the timestamps from the images and IMU to synchronize the two sensors. If you use system time (from your computer) there will be more error (partially due to weird USB timing).

Pro Tip 3: The cameras have Depth Presets. These are profiles that let you optimize various settings for various conditions. Such as high density, high accuracy, etc..

Pro Tip 4: Make sure your exposure is set correctly. If you are using auto exposure try changing the Mean Intensity Set Point (the setting is not where exposure is, it is under AE control, not the most obvious…).
If you want to use manual exposure you can play with are Exposure setpoint and Gain constant. Start with the exposure setpoint, then adjust the gain.

You might also want to see this whitepaper for more methods of tuning the cameras for better performance.

Visual Odometry & SLAM (T265)

Visual odometry is the generic term for figuring out how far you have moved using a camera. This is as opposed to “standard” odometry using things such as wheel encoders, or inertial odometry with a IMU.

RealSense T265 is a tracking camera that is designed to be more optimal for Visual Odometry and SLAM (wider field of view and not using infrared light). It can do SLAM onboard as well as loop closure. However, this camera is not able to return RGB images (since it does not have a RGB camera onboard) and the depth returned is not as good as the D400 series (and can be a little trickier to get).

Using both a RealSense D435i sensor and a RealSense T265 sensor can provide both the maps and the better quality visual odometry for developing a full SLAM system. The D435i used for the mapping, and the T265 for the tracking.

Software

Intel provides the RealSense SDK2.0 library for using the RealSense cameras. It is Open Source and work on Mac, Windows, Linux, and Android. There are also ROS and OpenCV wrappers.

Click here for the developers page with the SDK.

Within the SDK (software development kit) it includes a viewer to let you view images, record images, change settings, or update the firmware.

Pro Tip 5: Spend some time with the viewer looking at the camera and depth images when designing your system so you can compare various mounting angles, heights, etc.. for the cameras.

The RealSense SDK (software development kit) has a few filters that can run on your computer to try and improve the returned depth map. You can play with turning these on and off in the viewer. Some of these include:

1. Decimation Filter
2. Spatial Edge-Preserving Filter
3. Temporal Filter
4. Holes Filling Filter

Within ROS there is a realsense-ros package that provides a wrapper for working with the cameras in ROS and lets you view images and other data in RVIZ.

ROS RealSense Occupancy Map package is available as an experimental feature in a separate branch of the RealSense git repo. This uses both the D400 and T265 cameras for creating the map.

For SLAM with just the D435i sensor, see here.

Pro Tip 6: You can use multiple T265 sensors for better accuracy. For example, if one sensor is pointed forward and another backwards; you can use the confidence values from each sensor to feed into a filter.

I know this is starting to sound like a sales pitch…

Pro Tip 7: If you have multiple cameras you can connect and query for a serial number to know which cameras is which.
Also if you remove the little connector at the top of the camera you can wire and chain multiple cameras together to synchronize them. (This should work in the SDK 2.0)

See this whitepaper for working with multiple camera configurations. https://simplecore.intel.com/realsensehub/wp-content/uploads/sites/63/Multiple_Camera_WhitePaper04.pdf

Pro Tip 8: Infinite depth points (such as points to close or to far from the sensor) have a depth value of 0. This is good to know for filtering.

Here are two code snippet’s for using the cameras provided by Daniel, to share with you. The first one is for basic displaying of images using python. The second code snippet is using OpenCV to also detect blobs, also using python.

## License: Apache 2.0. See LICENSE file in root directory.
## Copyright(c) 2015-2017 Intel Corporation. All Rights Reserved.

###############################################
##      Open CV and Numpy integration        ##
###############################################

import pyrealsense2 as rs
import numpy as np
import cv2


cv2.namedWindow('RealSense', cv2.WINDOW_AUTOSIZE)

# Configure depth and color streams
pipeline = rs.pipeline()
config = rs.config()
config.enable_stream(rs.stream.depth, 640, 480, rs.format.z16, 30)
config.enable_stream(rs.stream.color, 640, 480, rs.format.bgr8, 30)

# Start streaming
pipeline.start(config)

try:
    while True:

        
        # Wait for a coherent pair of frames: depth and color
        frames = pipeline.wait_for_frames()
        depth_frame = frames.get_depth_frame()
        color_frame = frames.get_color_frame()
        if not depth_frame or not color_frame:
            continue

        # Convert images to numpy arrays
        depth_image = np.asanyarray(depth_frame.get_data())
        color_image = np.asanyarray(color_frame.get_data())

        # Apply colormap on depth image (image must be converted to 8-bit per pixel first)
        
        scaled_depth=cv2.convertScaleAbs(depth_image, alpha=0.08)
        depth_colormap = cv2.applyColorMap(scaled_depth, cv2.COLORMAP_JET)

        # Stack both images horizontally
        images = np.hstack((color_image, depth_colormap))

        # Show images
        cv2.imshow('RealSense', images)


        k = cv2.waitKey(1) & 0xFF
        if k == 27:
            break

finally:

    # Stop streaming
    pipeline.stop()

## License: Apache 2.0. See LICENSE file in root directory.
## Copyright(c) 2015-2017 Intel Corporation. All Rights Reserved.

###############################################
##      Open CV and Numpy integration        ##
###############################################

import pyrealsense2 as rs
import numpy as np
import cv2

def nothing(args):
    pass

def detectBlobs(mask):
        # Set up the SimpleBlobdetector with default parameters.
    params = cv2.SimpleBlobDetector_Params()
         
    # Change thresholds
    params.minThreshold = 1;
    params.maxThreshold = 255;
    
    # Filter by Area.
    params.filterByArea = True
    params.maxArea = 4000
    params.minArea = 300
    
    # Filter by Circularity
    params.filterByCircularity = True
    params.minCircularity = 0.1
    
    # Filter by Convexity
    params.filterByConvexity = True
    params.minConvexity = 0.5
    
    # Filter by Inertia
    params.filterByInertia = True
    params.minInertiaRatio = 0.1

         
    detector = cv2.SimpleBlobDetector_create(params)
 
    # Detect blobs.
    reversemask= mask
    keypoints = detector.detect(reversemask)
    im_with_keypoints = cv2.drawKeypoints(mask, keypoints, np.array([]),
            (0,0,255), cv2.DRAW_MATCHES_FLAGS_DRAW_RICH_KEYPOINTS)
    return im_with_keypoints

def thresholdDepth(depth):
    depth[depth==0] = 255 #set all invalid depth pixels to 255
    threshold_value = cv2.getTrackbarPos('Threshold','Truncated Depth')
    # Zero if dist>TH
    ret,truncated_depth=cv2.threshold(scaled_depth,threshold_value,255,cv2.THRESH_BINARY_INV) 
    return truncated_depth

cv2.namedWindow('RealSense', cv2.WINDOW_AUTOSIZE)
cv2.namedWindow('Truncated Depth', cv2.WINDOW_AUTOSIZE)
cv2.createTrackbar('Threshold','Truncated Depth',30,255,nothing)

# Configure depth and color streams
pipeline = rs.pipeline()
config = rs.config()
config.enable_stream(rs.stream.depth, 640, 480, rs.format.z16, 30)
config.enable_stream(rs.stream.color, 640, 480, rs.format.bgr8, 30)

# Start streaming
pipeline.start(config)

try:
    while True:

        
        # Wait for a coherent pair of frames: depth and color
        frames = pipeline.wait_for_frames()
        depth_frame = frames.get_depth_frame()
        color_frame = frames.get_color_frame()
        if not depth_frame or not color_frame:
            continue

        # Convert images to numpy arrays
        depth_image = np.asanyarray(depth_frame.get_data())
        color_image = np.asanyarray(color_frame.get_data())

        # Apply colormap on depth image (image must be converted to 8-bit per pixel first)
        scaled_depth=cv2.convertScaleAbs(depth_image, alpha=0.08)
        depth_colormap = cv2.applyColorMap(scaled_depth, cv2.COLORMAP_JET)

        # Stack both images horizontally
        images = np.hstack((color_image, depth_colormap))

        # Show images
        cv2.imshow('RealSense', images)
        truncated_depth=thresholdDepth(scaled_depth)
        truncated_depth=detectBlobs(truncated_depth)
        cv2.imshow('Truncated Depth', truncated_depth)

        k = cv2.waitKey(1) & 0xFF
        if k == 27:
            break

finally:

    # Stop streaming
    pipeline.stop()

I hope you found this informative and can make use of the Pro Tips.

Thank you to Daniel for presenting this information and allowing me to share it. This content is based on his talk. Daniel has also provided the full slide set that can be accessed by clicking here.

Disclaimer: I have not received any funding or free items from Intel.

Liked this article? Take a second to support me on Patreon! This post appeared first on Robots For Roboticists.

From the Reservoir the fluid goes to the Pump where there are three connections. 1. Accumulator(top) 2. Relief Valve(bottom) & 3. Control Valve. The Control Valve goes to the Cylinder which returns to a filter and then back to the Reservoir.

Hydraulics are sometimes looked at as an alternative to electric motors.

Some of the primary reasons for this include:

• Linear motion
• Very high torque applications
• Small package for a given torque
• Large number of motors that can share the reservoir/pump can increase volume efficiency
• You can add dampening for shock absorption

However there are also some downsides to using hydraulics including:

• More parts are required (however they can be separated from the robot in some applications)
• Less precise control (unless you use a proportional valve)
• Hydraulic fluid (mess, leaks, mess, and more mess)

Hydraulic systems use an incompressible liquid (as opposed to pneumatics that use a compressible gas) to transfer force from one place to another. Since the hydraulic system will be a closed system (ignore relief valves for now) when you apply a force to one end of the system that force is transferred to another part of that system. By manipulating the volume of fluid in different parts of the system you can change the forces in different parts of the system (Remember Pascal’s Law from high school??).

So here are some of the basic components used (or needed) to develop a hydraulic system.

Pump

The pump is the heart of your hydraulic system. The pump controls the flow and pressure of the hydraulic fluid in your system that is used for moving the actuators.

The size and speed of the pump determines the flow rate and the load at the actuator determines the pressure. For those familiar with electric motors the pressure in the system is like the voltage, and the flow rate is like the electrical current.

Pump Motor

We know what the pump is, but you need a way to “power” the pump so that it can pump the hydraulic fluid. Generally the way you power the pump is by connecting it to an electric motor or gas/diesel engine.

Hydraulic Fluid

Continuing the analogy where the pump is the heart, the hydraulic fluid is the blood of the system. The fluid is what is used to transfer the pressure from the pump to the motor.

Hydraulic Hoses (and fittings to connect things)

These are the arteries and veins of the system that allows for the transfer of hydraulic fluid.

Hydraulic Actuators – Motor/Cylinder

The actuator is generally the reason we are designing this hydraulic system. The motor is essentially the same as the pump; however instead of going from a mechanical input to generating the pressure, the motor converts the pressure into mechanical motion.

Actuators can come in the form of linear motion (referred to as a hydraulic cylinder) or rotary motion motors.

For cylinders, you generally apply a force and the cylinder end extends, and then if you release the force and the cylinder gets pushed back in (think of a car lift). This is the classic and most common use of hydraulics.

For rotary motors there are generally 3 connections on the motor.

• A – Hydraulic fluid input/output line
• B – Hydraulic fluid input/output line
• Drain – Hydraulic fluid output line (generally only on motors, not cylinders)

Depending on the motor you can either only use A as the fluid input and B as the fluid output and the motor only spins in one direction. Or some motors can spin in either direction based on if A or B is used as the input or output of the hydraulic fluid.

The drain line is used so when the system is turned off, the fluid has a way to get out of the motor (to deal with internal leakage and to not blow out seals). In some motors the drain line is connected to one of the A or B lines. Also their are sometimes multiple drain lines so that you can route the hydraulic hoses from different locations.

Note: While the pump and motor are basically the same component. You usually can not switch their role due to how they are designed to handle pressure and the pumps usually not being backdrivable.

There are some actuators that are designed to be leakless and hold the fluid and pressure (using valves) so that the force from the actuator is held even without the pump. For example these are used in things like automobile carrying trucks that need to stack cars for transport.

Reservoir

This is essentially a bucket that holds the fluid. They are usually a little fancier so that they have over pressure relief valves, lids, filters, etc..

The reservoir is also often a place where the hydraulic fluid can cool down if it is getting hot within the system. As the fluid gets hotter it can get thinner which can result in increased wear of your motor and pump.

Filter

Keeps your hydraulic fluid clean before going back to the reservoir. Kind of like a persons kidneys.

Valves (and Solenoids)

Valves are things that open and close to allow the control of fluid. These can be controlled by hand (ie. manual), or more often my some other means.

One common method is to use a solenoid which is a device that when you apply a voltage can be used to open a valve. Some solenoids are latching, which means you quickly apply a voltage and it opens the valves, and then you apply a voltage again (usually switching polarity) to close the valve.

There are many types of valves, I will detail a few below.

Check Valves (One Way Valve)

These are a type of valve that can be inline to allow the flow of hydraulic fluid in only one direction.

Relief Valve

These are a type of valve that automatically opens (And lets fluid out) when the pressure gets to high. This is a safety feature so you don’t damage other components and/or cause an explosion.

Pilot Valve

These are another special class of valve that can use a small pressure to control a much larger pressure valve.

Pressure & Flow-rate Sensors/Gauges 

You need to have sensors (with a gauge or computer output) to measure the pressure and/or flow-rate so you know how the system is operating and if it is operating how you expect it to operate.

Accumulator

The accumulator is essentially just a tank that holds fluid under pressure that has its own pressure source. This is used to help smooth out the pressure and take any sudden loads from the motor by having this pressure reserve. This is almost like how capacitors are used in electrical power circuits.

The pressure source in the accumulator is often a weight, springs, or a gas.

There will often be a check valve to make sure the fluid in the accumulator does not go back to the pump.

I am not an expert on hydraulic systems. But I hope this quick introduction helps people. Liked it? Take a second to support me on Patreon! This post appeared first on Robots For Roboticists.

Underwater Considerations

There are some challenges that exist with underwater photography and videography, that are less challenging above the water. Some of them include:

1) Water reflects some of the light that hits the surface, and absorbs the light that travels through it. This causes certain colors to not be visible at certain depths. If you need to see those colors you often need to bring strong lights to restore the visibility of those wavelengths that were absorbed. Red’s tend to disappear first, blues are the primary color seen as camera depth increases. A trick that people often try is to use filters on the camera lens to make certain colors more visible.

If you are using lights then you can get the true color of the target. Sometimes if you are taking images you will see one color with your eye, and then when the strobe flashes a “different color” gets captured. In general you want to get close to the target to minimize the light absorbed by the water.

Visible colors at given depths underwater. [Image Source]

For shallow water work you can often adjust the white balance to sort of compensate for the missing colors. White balance goes a long ways for video and compressed images (such as .jpg). Onboard white balance adjustments are not as important for photographs stored as with a raw image format, since you can deal with it in post processing. Having a white or grey card in the camera field of view (possibly permanently mounted on the robot) is useful for setting the white balance and can make a big difference. The white balance should be readjusted every so often as depth changes, particularly if you are using natural lighting (ie the sun).

Cold temperate water tends to look green (such as a freshwater quarry) (I think from plankton, algae, etc..). Tropical waters (such as in the Caribbean) tend to look blue near the shore and darker blue as you get further away from land (I think based on how light reflects off from the bottom of the water)… Using artificial light sources (such as strobes) can minimize those colors in your imagery.

Auto focus generally works fine underwater. However if you are in the dark you might need to keep a focus light turned on to help the autofocus work, and then a separate strobe flash for taking the image. Some systems turn the focus light off when the images are being taken. This is generally not needed for video as the lights are continuously turned on.

2) Objects underwater appear closer and larger than they really are. A rule of thumb is that the objects will appear 25% larger and/or closer.

3) Suspended particles in the water (algae, dirt, etc..) scatters light which can make visibility poor. This can obscure details in the camera image or make things look blurry (like the camera is out of focus). A rule of thumb is your target should be less than 1/4 distance away from the camera as your total visibility.

The measure of the visibility is called turbidity. You can get turbidity sensors that might let you do something smart (I need to think about this more).

To minimize the backscatter from turbidity there is not a “one size fits all” solution. The key to minimizing backscatter is to control how light strikes the particles. For example if you are using two lights (angled at the left and right of the target), the edge of each cone of light should meet at the target. This way the water between the camera and the target is not illuminated. For wide-angle lenses you often want the light to be behind the camera (out of its plane) and to the sides at 45° angles to the target. With macro lenses you usually want the lights close to the lens.

“If you have a wide-angle lens you probably will use a domed port to protect the camera from water and get the full field of view of the camera.
The dome however can cause distortion in the corners. Here is an interesting article on flat vs dome ports.”

Another tip is to increase the exposure time (such as 1/50th of a second) to allow more natural light in, and use less strobe light to reduce the effect from backscatter.

4) Being underwater usually means you need to seal the camera from water, salts, (and maybe sharks). Make sure the enclosure and seals can withstand the pressure from the depth the robot will be at. Also remember to clean (and lubricate) the O rings in the housing.

“Pro Tip:Here are some common reasons for O ring seals leaking:
a. Old or damaged O rings. Remember O rings don’t last forever and need to be changed.
b. Using the wrong O ring
c. Hair, lint, or dirt getting on the O ring
d. Using no lubricant on the O ring
e. Using too much lubricant on the O rings. (Remember on most systems the lubricant is for small imperfections in the O ring and to help slide the O rings in and out of position.)”

5) On land it is often easy to hold a steady position. Underwater it is harder to hold the camera stable with minimal motion. If the camera is moving a faster shutter speed might be needed to avoid motion blur. This also means that less light is entering the camera, which is the downside of having the faster shutter speed.

When (not if) your camera floods

When your enclosure floods while underwater (or a water sensor alert is triggered):

a. Shut the camera power off as soon as you can.
b. Check if water is actually in the camera. Sometimes humidity can trigger moisture sensors. If it is humidity, you can add desiccant packets in the camera housing.
c. If there is water, try to take the camera apart as much as you reasonably can and let it dry. After drying you can try to turn the camera on and hope that it works. If it works then you are lucky, however remember there can be residual corrosion that causes the camera to fail in the future. Water damage can happen instantaneously or over time.
d. Verify that the enclosure/seals are good before sending the camera back in to the water. It is often good to do a leak test in a sink or pool before going into larger bodies of water.
e. The above items are a standard response to a flooded camera. You should read the owner’s manual of your camera and follow those instructions. (This should be obvious, I am not sure why I am writing this).

Do you have other advice for using cameras underwater and/or attached to a robot? Leave them in the comment section below.

I want to thank John Anderson for some advice for writing this post. Any mistakes that may be in the article are mine and not his.

The main image is from divephotoguide.com. They have a lot of information on underwater cameras, lens, lights and more.

This post appeared first on Robots For Roboticists.

Lithium battery safety is an important issue as there are more and more reports of fires and explosions. Fires have been reported in everything from cell phones to airplanes to robots.

If you don’t know why we need to discuss this, or even if you do know, watch this clip or click here.

I am not a fire expert. This post is based on things I have heard and some basic research. Contact your local fire department for advice specific to your situation. I had very little success contacting my local fire department about this, hopefully you will have more luck.

Preventing Problems

1. Use a proper charger for your battery type and voltage. This will help prevent overcharging. In many cases lithium-ion batteries catch fire when the chargers keep dumping charge into the batteries after the maximum voltage has been reached.

2. Use a battery management system (BMS) when building battery packs with multiple cells. A BMS will monitor the voltage of each cell and halt charging when any cell reaches the maximum voltage. Cheap BMS’s will stop all charging when any cell reaches that maximum voltage. Fancier/better BMS’s can individually charge each cell to help keep the battery pack balanced. A balanced pack is good since each cell will be a similar voltage for optimal battery pack performance. The fancy BMS’s can also often detect if a single cell is reading wrong. There have been cases of a BMS’s working properly but a single cell going bad which confuses the BMS; and yields a fire/explosion.

3. Only charge batteries in designated areas. A designated area should be non combustible. For example cement, sand, cinder block and metal boxes are not uncommon to use for charging areas. For smaller cells you can purchase fire containment bags designed to put the charging battery in.

In addition the area where you charge the batteries should have good ventilation.

I have heard that on the Boeing Dreamliner, part of the solve for their batteries catching fire on planes, was to make sure that the metal enclosure that the batteries were in could withstand the heat of a battery fire. And also to make sure that in the event of a fire the fumes would vent outside the aircraft and not into the cabin.

Dreamliner battery pack before and after fire. [SOURCE]

4. Avoid short circuiting the batteries. This can cause a thermal runoff which will also cause a fire/explosion. When I say avoid short circuiting the battery you are probably thinking of just touching the positive and negative leads together. While that is an example you need to think of other methods as well. For example puncturing a cell (such as with a drill bit or a screw driver) or compressing the cells, can cause a short-circuit with a resulting thermal runoff.

5. Don’t leave batteries unattended when charging. This will let people be available in case of a problem. However, as you saw in the video above, you might want to keep a distance from the battery in case there is a catastrophic event with flames shooting out from the battery pack.

6. Store batteries within the specs of the battery. Usually that means room temperature and out of direct sunlight (to avoid overheating).

7. Training of personnel for handling batteries, charging batteries, and what to do in the event of a fire. Having people trained in what to do can be important so that they stay safe. For example, without training people might not realize how bad the fumes are. Also make sure people know where the fire pull stations are and where the extinguishers are.

Handling Fires

1. There are 2 primary issues with a lithium fire. The fire itself and the gases released. This means that even if you think you can safely extinguish the fire, you need to keep in mind the fumes and possibly clear away from the fire.

2a. Lithium batteries which are usually in the form of small non-rechargeable batteries (such as in a watch) in theory require a class D fire extinguisher. However most people do not have one available. As such, for the most part you need to just let it burn itself out (it is good that the batteries are usually small). You can use a standard class ABC fire extinguisher to prevent the spread of the fire. Avoid using water on the lithium battery itself since the lithium and water can react violently.

2b. Lithium-ion batteries (including LiFePO₄) that are used on many robots, are often larger and rechargeable. For these batteries there is not a lot of actual lithium metal in the battery, so you can use water or a class ABC fire extinguisher. You do not use a class D extinguisher with these batteries.

With both of these types of fires, there is a good chance that you will not be able to extinguish the it. If you can safety be in the area your primary goal is to allow the battery to burn in a controlled and safe manner. If possible try to get the battery outside and on a surface that is not combustible. As a reminder lithium-ion fires are very hot and flames can shoot out from various places unexpectedly; you need to be careful and only do what you can do safety. If you have a battery with multiple cells it is not uncommon for each cell to catch fire separately. So you might see the flames die down, then shortly after another cell catches fire, and then another; as the cells cascade and catch fire.

A quick reminder about how to use a fire extinguisher. Remember first you Pull the pin, then you Aim at the base of the fire, then you Squeeze the handle, followed by Sweeping back and forth at the base of the fire. [SOURCE]

3. In many cases the batteries are in an enclosure where if you spray the robots with an extinguisher you will not even reach the batteries. In this case your priority is your safety (from fire and fumes), followed by preventing the fire from spreading. To prevent the fire from spreading you need to make sure all combustible material is away from the robot. If possible get the battery pack outside.

In firefighting school a common question is: Who is the most important person? To which the response is, me!

4. If charging the battery, try to unplug the battery charger from wall. Again only if you can do this safely.

I hope you found the above useful. I am not an expert on lithium batteries or fire safety. Consult with your local experts and fire authorities. I am writing this post due to the lack of information in the robotics community about battery safety.

As said by Wired “you know what they say: With great power comes great responsibility.”.

Thank you Jeff (I think he said I should call him Merlin) for some help with this topic.

This post appeared first on Robots For Roboticists.

I had the opportunity to attend the National Robot Safety Conference for Industrial Robots today in Pittsburgh, PA (USA). Today was the first day of a three-day conference. While I mostly cover technical content on this site; I felt that this was an important conference to attend since safety and safety standards are becoming more and more important in robot system design. This conference focused specifically on industrial robots. That means the standards discussed were not directly related to self-driving cars, personal robotics, or space robots (you still don’t want to crash into a martian and start an inter-galactic war).

In this post I will go into a bit of detail on the presentations from the first day. Part of the reason I wanted to attend the first day was to hear the overview and introductory talks that formed a base for the rest of the sessions.

The day started out with some Standards Bingo. Lucky for us the conference organizers provided a list of standards terms, abbreviations, codes, and titles (see link below). For somebody (like myself) who does not work with industrial robot safety standards every day, when people start rattling off safety standard numbers it can get confusing very fast.

Quick, what is ISO 10218-1:2011 or IEC 60204-1:2016? For those who do not know, (me included) those are Safety requirements for industrial robots — Part 1: Robots and Safety of machinery – electrical equipment — Part 1: General requirements.

Click here for a post with a guide to relevant safety standards, Abbreviations, Codes & Titles.

The next talk was from Carla Silver at Merck & Company Inc. she introduced what safety team members need to remember to be successful, and introduced Carla’s Top Five List.

1. Do not assume you know everything about the safety of a piece of equipment!
2. Do not assume that the Equipment Vendor has provided all the information or understands the hazards of the equipment.
3. Do not assume that the vendor has built and installed the equipment to meet all safety regulations.
4. Be a “Part of the Process”. – Make sure to involve the entire team (including health and safety people)
5. Continuous Education

I think those 5 items are a good list for life in general.

The prior talk set the stage for why safety can be tricky and the amount of work it takes to stay up to date.

Robot integrator is a certification (and way to make money) from Robotic Industries Association (RIA) that helps provide people who come trained to fill the safety role while integrating and designing new robot systems.

According to Bob Doyle the RIA Director of Communications, RIA certified robot integrators must understand current industry safety standards and undergo an on-site audit in order to get certified. Every two years they need to recertify. Part of the recertification is having an RIA auditor perform a site visit. When recertifing the integrators are expected to know the current standards. I was happy to hear about the two-year recertification, due to how much changes with robotics technology over two years.

A bit unrelated but A3 is the umbrella association for Robotic Industries Association (RIA) as well as Advancing Vision & Imaging (AIA), and Motion Control & Motor Association (MCMA). Bob mentioned that the AIA and MCMA certifications are standalone from the RIA Certified Integrators. However they are both growing as a way to train industrial engineers for those applications. Both the AIA and MCMA certifications are vendor agnostic for the technology used. There are currently several hundred people with the AIA certification. The MCMA certification was just released earlier this year and has several dozen people certified. Bob said that there are several companies that now require at least one team member on a project to have the above certifications.

The next talk really started to get into the details about Robot System Integrators and Best Practices. In particular risk assessments. Risk assessments is a relatively new part of the integration process, but has a strong focus in the current program. Risk assessments are important due to the number of potential safety hazards and the different types or interactions a user might have with the robot system. The risk assessment helps guide the design as well as how users should interact with the robot . The responsibility to perform this risk assessment is with the robot integrator and not directly with the manufacturer or end-user.

One thing that I heard that surprised me was that many integrators do not share the risk assessment with the end-user since it is considered proprietary to that integrator. However one participant said that you can often get them to discuss it in a meeting or over the phone, just they will not hand over the documents.

After a small coffee break we moved on to discussing some of the regulations in detail. In particular R15.06 which is for Industrial Robot Safety standards, the proposed R15.08 standards for industrial mobile robot safety standards, and the R15.606 collaborative robot safety standards. Here are a few notes that I took:

Types of Standards

• A – Basic concepts — Ex. Guidance to assess risk
• B – Generic safety standards — Ex. Safety distances, interlocks, etc..
• C – Machine specific — ex. From the vendor for a particular robot.

Type C standards overrule type A & B standards.

Parts of a Standard

• Normative – These are required and often use the language of “shall”
• Informative – These are recommended or advice and use the language of “should” or “can”. Notes in standards are considered Informative

Key Terms for Safety Standards

• Industrial Robot – Robot manipulator of at least 3 DOF and its controller
• Robot System – The industrial robot with its end effector, work piece and periphery equipment (such as conveyor).
• Robot Cell – Robot system with the safe guarded spaces to include the physical barriers.

Case study that was presented of a 3 robot system in a single cell, and how it was designed to meet safety standards.

R15.06 is all about “keeping people safe by keeping them away from the robot system”. This obviously does not work for mobile robots that move around people and collaborative robots. For that the proposed R15.08 standard for mobile robots and the R15.606 standard for collaborative robots are needed.

R15.08 which is expected to be ratified as a standard in 2019 looks at things like mobile robots, manipulators on mobile robots, and manipulators working while the mobile base is also working. Among other things, the current standard draft says that if an obstacle is detected, the primary mode is for the robot to stop; however dynamic replanning will be allowed.

For R15.606 they are trying to get rid of the term collaborative robot (a robot designed for direct interaction with a human) and think about systems in regard to its application. For example :

…a robotic application where an operator may interact directly with a robot system without relying on perimeter safeguards for protection in pre-determined,low risk tasks…

After all the talk about standards we spent a bit of time looking at various case studies that were very illuminating for designing industrial robotic systems, and some of the problems that can occur.

One thing unrelated, but funny since this was a safety conference, was a person sitting near the back of the room who pulled a roll of packing tape out of their backpack to tape over their laptop power cable that ran across the floor.

I hope you found this interesting. This was the 29th annual national robot safety meeting (really, I did not realize we had been using robots in industry for that long). If you want to find out more about safety and how it affects your work and robots make sure to attend next year.

I would like to thank RIA for giving me a media pass to attend this event.

I was recently asked about the differences between RADAR and LIDAR. I gave the generic answer about LIDAR having higher resolution and accuracy than RADAR. And RADAR having a longer range and performing better in dust and smokey conditions. When prompted for why RADAR is less accurate and lower resolution, I sort of mumbled through a response about the wavelength. However, I did not have a good response, so this post will be my better response.

LIDAR

LIDAR—which is short for Light Detection and Ranging—uses a laser that is emitted and then received back in the sensor. In most of the LIDAR sensors used for mapping (and self driving vehicles) the time between the emission and reception is computed to determine the time of flight (ToF). Knowing the speed of light and (1/2 of the) time for the wave to return (since the signal traveled out and back) we can compute how far away the object was that caused the light to bounce back. That value is the range information that is reported by the sensor. LIDAR’s generally use light in the near-infrared, visible (but not really visible), and UV spectrum’s.

There are some sensors that use triangulation to compute the position (instead of ToF). These are usually high accuracy, high resolution sensors. These sensors are great for verifying components on an assembly lines or inspecting thermal tile damage on the space shuttle. However that is not the focus of this post.

LIDAR data. The top shows the reflectivity data. The bottom shows the range data with brighter points being farther away.

The laser beam can also be focused to have a small spot size that does not expand much. This small spot size can help give a high resolution. If you have a spinning mirror (which is often the case) then you can shoot the laser every degree or so (based on the accuracy of the pointing mechanism) for improved resolution. It is not uncommon to find LIDAR’s operating at 0.25 degrees of angular resolution.

RADAR

RADAR—which is short for Radio Detection and Ranging—uses radio waves to compute velocity, and/or range to an object. Radio waves have less absorption (so less attenuation) than the light waves when contacting objects, so they can work over a longer distance. As you can see in the image below the RF waves have a larger wavelength than the LIDAR waves. The down side is that if an object is much smaller than the RF wave being used, the object might not reflect back enough energy to be detected. For that reason many RADAR’s in use for obstacle detection will be “high frequency” so that the wavelength is shorter (hence why we often use mm-wave in robotics) and can detect smaller objects. However, since LIDAR’s have the significantly smaller wavelength, they will still usually have a finer resolution.

Electromagnetic spectrum showing radio waves all the way on the left for RADAR and near-infrared/visible/ultra-violet waves towards the right for LIDAR usage.

Most of the RADAR’s that I have seen will have a narrow field of view (10’s of degrees) and then just return a single value (or they might have up to a few dozen channels, see multi-mode RADAR below) for the range of the detected object. There are tricks that some systems can do using multiple channels to also get the angle for the range measurement. The angle will not be as high resolution as most LIDAR’s. There are also some RADAR’s on the market that scan to get multiple measurements. The 2 approaches are a spinning antenna (such as what you see at airports or on ships) or electronically “spinning” which is a device using multiple internal antennas with no moving parts. More advanced (newer) RADAR’s can do things like track multiple objects. In many cases they will not actually return the points that outline the objects (like a LIDAR), but will return a range, bearing, and velocity to an estimated centroid of the detected item. If multiple objects are near each other, the sensor might confuse them as being one large object and return one centroid range [Here is the source and a good reference to read].

Using the Doppler frequency shift, the velocity of an object can also be easily determined with relatively little computational effort. If the RADAR sensor and the detected object are both moving than you get a relative velocity between the two objects.

With RADAR there are commonly two operating modes:

1. Time of Flight – This operates similar to the LIDAR sensor above, however it uses radio wave pulses for the Time of Flight calculations. Since the sensors are pulsed, it knows when the pulse was sent. So, computing the range can be easier than with the continuous wave sensors (described below). The resolution of the sensor can be adjusted by changing the pulse width and the length of time you listen for a response (a ping back). These sensors often have fixed antennas leading to a small operating field of views (compared to LIDAR).

There are some systems that will combine multiple ToF radio waves into one package with different pulse widths. These will allow for various ranges to be detected with higher accuracy. These are sometimes called multi-mode RADAR

2. Continuous Wave – This approach frequency modulates (FMCW) a wave and then compares the frequency of the reflected signal to the transmitted signal in order to determine a frequency shift. That frequency shift can be used to determine the range to the object that reflected it. The larger the shift the farther the object is from the sensor (within some bounds). Computing the frequency shift and the corresponding range is computationally easier than ToF, plus the electronics to do so are easier and cheaper. This makes continuous frequency modulated systems popular. Also, since separate transmit and receive antennas are often used, this approach can continuously be transmitting and receiving at the same time unlike the pulsed ToF approach, which needs to transmit then wait for a response. This feature and the simple electronics can make FMCW RADAR very fast at detecting objects.

There is another version of the Continuous Wave RADAR where the wave is not modulated. These systems are cheap and good for quickly detecting speed using the Doppler effect, however they can not determine range. They are often used by police to detect vehicle speed where the range is not important.

SONAR

Unrelated, I should note that SONAR or Sound Navigation and Ranging, can work in both of the modes as RADAR. The wavelength used is even larger than RADAR. It is farther to the left in the spectrum image shown before, and is off the chart.

I should point out that there are cool imaging SONAR sensors. The general idea is that you can make the sensing wave vertical so that the horizontal resolution is very fine (<1 degree) and the vertical resolution is larger (10+ degrees). You can then put many of these beams near each other in a sensor package. There are similar packages that do this with small wave length RADAR.

Cost

LIDAR Sensors tend to cost more than RADAR sensors for several reasons:

1. LIDAR using ToF needs high speed electronics that cost more.
2. LIDAR sensors needs CCD receivers, optics, motors, and lasers to generate and receive the waves used. RADAR only needs some stationary antennas.
3. LIDAR sensors have spinning parts for scanning. That requires motors and encoders. RADAR only needs some stationary antennas. (I know this is sort of similar to the line above).

Computationally Speaking

RADAR sensors tend to generate a lot less data as they just return a single point, or a few dozen points. When the sensor is multi-channel it is often just returning a range/velocity to a few centroid(ish) objects. The LIDAR sensors are sending lots of data about each individual laser point of range data. It is then up to the user to make that data useful. With the RADAR you have a simple number, but that number might not be the best. With LIDAR it depends on the roboticist to generate algorithms to detect the various objects and discern what is being viewed by the sensor.

If your goal is to detect a car in front of you (or driving towards you) and get its velocity, the RADAR can be great. If you are trying to determine the precise location of an item, generate a surface map, or find a small fence-post, a LIDAR might do better. Just remember that if you are in dust or rain the LIDAR might return a cloud of points right near the sensor (as it reads all of those particles/drops); while the RADAR might do much better.

I recently found a SICK LMS291 in the trash (dumpster diving time!). It is a bit of an older model—manufactured in August 2000—however the fundamentals should be similiar to the current generation of sensors. If you look at robots from that era you will often see them covered in this type of LIDAR sensor.

Here is a series of posts about how LIDAR works and evaluating multiple sensors.

If you have always wanted to know how a SICK LIDAR worked inside, now is your chance. If you did not always want to know, this is still your chance to see. Keep reading for some cool pictures.

The sensor feels solid and feels like a brick. I could probably throw it off a cliff and it will still work, not that you should try…

SICK LMS 291. You can see the front black area where the laser shoots out from. The 3 indicator lights at the top front, and the cutout in the back for the connectors.

SICK LMS 291 power and serial communications ports. There is a large sealed connector that plugs into each slot.

Front Plastic Shield

Mirror and encoder wheel. The laser shoots down from above the spinning mirror. The green post on the left reads the position from the encoder wheel shown on the bottom. The encoder wheel is the metal wheel with the slots cut into it. The 6 black tubes on the bottom I think are IR LEDs that are used for detecting dust or anything else occluding the front black visor.

Front Metal Case removed. Walls are about 3/10″ or 7.6mm thick

With the front removed here are the internals of the sensor. On the bottom you can see the metal ring which is a motor, above it is the spinning mirror encoder. The top section has the control boards and the laser hidden behind them.

Bottom view of the open sensor. The motor for spinning the mirror and encoder wheel is clearly visible at the bottom. The black rectangles on the top board are for detecting if the bottom LEDs are visible for fault detection.

These are the wings that go below and above the spinning mirror assembly. On the left side you can see the LEDs and the board on the right has the black square receivers.

The encoder is directly mounted to the mirror for increased accuracy of the laser position. It is very solidly built, and you can see that a designer was having fun with cutting the SICK logo into the metal disk. I was surprised when I saw this since I expected a higher resolution encoder wheel with more slots. But I guess the larger thicker slots can be more reliable. Towards the top of the wheel it looks like one slot is missing, I wonder if it is some sort of index.

Laser and receiver black can assembly visible after removing the front PCB. You can see the 2 gold coax connectors probably for some high frequency signals from the receiver. On the top board in the front you can see the 3 indicator lights that are visible on the exterior of the enclosure. On the left of the front board you can see the board interconnect connector that connects to the board on the right side of this image. When the boards are screwed down that connector is not coming loose.

Front board that I think converts the analog RF receiver signal to digital for the processor board. The board on top has the reciever, a coax cable goes from there to the gold can. Followed by going to this board. I am really curious what is under the gold can.

Look at the washers used above the screw holes. Excellent attention to detail to avoid screws coming loose from vibration. Not shown but there are many really nice touches, such as captive standoffs. I was surprised that I did not see any loctite.

Close up of the front board. Perhaps some RF signal conditioning for the receiver of the laser signal.

The main processor board that was connected to the front board shown before from the left side board connector. You can see the Xilinx FPGA that is running the sensor.

Bodge wire on the rear of the main processing board. I am surprised to see this. However it is really well done. Look at the epoxy blob holding the wire down.

Metal gold can to shield some components (or so I thought) from EM interference. Desiccant packet on the left is to control any moisture that might get into the sensor.

Inside of the shielding can. Is that for creating a time delay or some phase shift in the RF signal coming from the receiver?

Receiver of the incoming laser signal on the top board center. The black can has some mirrors and the laser.

Laser receiver module closeup. What is all the metal heatsinking for?

The motor and mirror removed. You can sort of look up into the laser and reciever assembly. The flat metal part between the ring and the laser assembly is the back of the power supply module.

Looking up from the mirror into the laser assembly. Most of the center that you see is a mirror. The slot in the plastic has its own mirror that points the laser from the gold block down to the spinning mirror. The returned signal goes on the sides of that slot to the receiver above.

Laser that is connected to the slot in the black mirror can.

Connected to gold pins above to (control) the laser. What is under that shield??

Under the shield. The DM74ALS seems to be a quad 2 input nand gate.

The power supply for the sensor that was located behind the spinning mirror module.

All of the components in the LIDAR sensor. The PCB that is still in the rear metal enclosure is the board that connects to the power and serial connectors that we saw on the external of the sensor before.

I hope you enjoyed seeing the internals of this sensor. It is interesting to see how they made it and the spinning mirror that we often hear about. Leave comments below to help identify parts or other questions you may have.

Set point control: Image: Wikipedia Commons

I was asked on the Robots for Roboticists forum about tuning motors and understanding Bode plots. Many motor control software packages come with tuning tools that can generate Bode plots. This post is my response to that question.

What is a control system? A control system alters the future state of its system to a more desirable outcome. We often work with feedback control systems (also called closed-loop control), where the result of the command is fed back into the control system. In particular, we are looking for the error between the command and the desired response. If the output state is not fed back into the control system it is referred to as an open loop system.

The frequency of a system can be hard to visualize just by watching the motors motion. The frequency of the system is when you convert the time domain signal (ie. you look at the motors motion over time), and convert it into the frequency domain using a Fourier transform. Once you convert the signal into the frequency domain we can use Bode plots. Bode plots help us visualize (the transfer function) of a control system response and to verify its stability.

Random Note:
Assuming you know the transfer function, in an open loop system you can just use root finding (ie. finding the values that make the equation equal to 0) to check stability (by making sure that all roots are negative real values). For feedback based closed loop system we can modify the above and solve with a computer (since math is hard), or use the Bode plot to help understand the control system better. (I should also point out you can use Routh-Hurwitz to avoid the complex math, this will need to be another post…)

In general, the Bode plots are showing the phase and gain (magnitude) from your input control signal until it reaches the output (command) in the frequency domain.

Parts of the Bode Plot

Gain is the shift in value between the input signal and resultant command. If you had a system with no gain and no losses, then you would have a straight horizontal line with 0dB of gain. You will usually see the gain drop off (decrease) on the right side of the magnitude plot. The larger the frequency range until it starts dropping off, shows a system that will be stable in more conditions. Random bumps and curves in the main curve are often signs of instability. If the gain increases anywhere to infinity (ie. large values) that is often a sign of instability, and you need to rethink your controller settings! If you have spikes in gain see the filtering section below.

Bandwidth is the area from the top of the curve until the magnitude degrades by -3dB. So in the image above you can see the curve dropping at around 100Hz. So the bandwidth of your system is around 100Hz. This tool actually shows the exact bandwidth value of 118.9Hz in the box at the lower right of the image. Controls past 118.9Hz will by sluggish or unresponsive.

Phase describes the time shift between the input signal and the output command. A phase of 360 is for a single cycle. So if you have a 1KHz (ie 1000Hz) command signal each 360 degrees in the chart would represent 1/1000 of a second (converting frequency to time) or 1 millisecond. You can see in the phase diagram that once you exceed the bandwidth it will take longer for the desired input signal to be transferred to the output signal.

Filtering specific frequencies

Various filters (low-pass, notch, etc..) are often applied to remove a resonance at a specific frequency. For example, if you spin a motor and you see at a specific frequency things start to shake violently, you can add a filter so the gain will be reduced at that frequency. In general, you should tune a motor with no filters, and only add the filters if needed.

Verifying control parameters

You can verify that the selected gains are good by looking at the output waveform when a step command is applied (in the time domain); this is sometimes referred to as oscilloscope mode. If there is a lot of initial ringing (constant changing) or overshoot in the beginning of motion your gains are probably too high. If the initial command is slowly reaching the desired output you might need to increase your gains.

Plots showing common tuning problems followed by a good response curve. The blue lines are the command, and the red lines are the actual motor output.

In the image above starting from the left we can see:
1. Overshooting of the output motion, with a little signal ringing as it settles to the command. A little overshoot is often fine, but we do try to minimize overshoot while still having a responsive system.
2. Slow response of the output. We might want a faster response so the system will be less sluggish. As you make the system less sluggish you often increase the overshooting and potential for instability.
3. Highly unstable. Starts with a bunch of oscillation, followed by a large spike in command output. We want to avoid this!
4. Finally this right-most plot looks good. The motor output is directly on top of the commanded motion, with a very slight overshoot (if you look close).

For more information on tuning controllers visit my post on PID Controllers.

Also while I talk a lot about motors, most of the above works for any control system and does not necessarily need to be a motor.

I want to thank MC_Newbie on the forum for this question.

Credit: CC0 Public Domain

We often want to add an external hard drive to our robots in order to have a dedicated drive for data collection. Having the dedicated drive lets the primary drive remain uncluttered, have less wear-and-tear, split logging between drives for performance, and potentially be a larger spinning disk (as opposed to an expensive SSD). It is also useful when the main hard drive is read only.

(For mechanical mounting skip to the end of this post)

So, how should you mount an external hard drive to your robot? There are many tutorials online and resources, however, this is how I do it and why (assuming Linux).

In the /etc/fstab file I add the following line:

The /dev/sdb1 needs to be changed based on your hard disk configuration, however typically if you have one primary drive and one external drive, the external will be sdb1. While you can name a drive based on its unique ID, I usually just do it based how the drive appears in /dev. This lets us plug any (one) drive into the computer and let it be used for data collection.

You need to create a location that the hard disk should be mounted to (for you to access it from). So before the above change you should create that mount directory. To make the directory above you can type sudo mkdir /media/data. I generally use Ubuntu, however in other distributions you might want to use sudo mkdir /mnt/data if /media does not exist.

Next is the file system. Generally in a Linux only environment ext4 is used. If you are in a mixed mode where you need to connect to Windows or Mac machines you might want to use vfat.

Now for the options. The options I often use are:

async,auto,user,exec,suid,rw,nobootwait,noatime
async – Lets data be written to a drive asynchronously. If many cases you might want this to be set to synchronous sync
auto – Mounts drive on boot and/or with mount -a
user – Allows any user to mount this drive
exec – Lets you execute binaries from the drive (might not be needed if you are only writing data)
suid – Allows the user ID to be set when executing a binary (might not be needed if you are only writing data)
rw – Read & Write access to the drive when mounted
nobootwait – Does not interrupt the boot sequence if drive not connected.
noatime – Disables writing file access times to the drive every time you read a file

Depending on the distro I also sometimes add nofail to work with nobootwait.

With the method of mounting the drive above the secondary drive can be auto mounted to the same mount point at boot. If the drive is not present at boot, the boot sequence will not fail. After the computer is up the drive will automatically mount or you might need to type sudo mount -a to mount the drive.

You can see https://wiki.archlinux.org/index.php/Fstab for more information on /etc/fstab.

I spent the top part of this post talking about mounting from the operating system perspective, however some people might get to this page for physical mounting.

There are many ways to mount a hard drive, these range from velcro, to external enclosures, to removable bays.

Here is one way to mount a hard disk for removable data drives that I like:

ICY DOCK ToughArmor MB991SK-B Full Metal 2.5″ SATA 6Gb/s SSD/HDD Hot Swap Mobile Rack for 3.5″ Device Bay (Fits 7, 9.5, 12.5, 15mm height drive) From Newegg.com

Sled that slides and locks into the hard drive bay. The hard drive goes inside of this sled. From newegg.com

This provides a secure mount that will not let the drive fall out while also protecting the drive. It also allows for swapping drives as disks get full and we want to log more data. We often fill up a drive and take it offsite to transfer to a server while filling up another drive. This allows us to easily rotate drives.

The post How to Mount an External Removable Hard Drive on a Robot appeared first on Robots For Roboticists.

The Car Hacker’s Handbook A Guide for the Penetration Tester is a book about how to interface with cars to read from onboard systems, spoof devices, and control the vehicle on your own. I enjoyed this book, it is easily the best book I found on learning how to use a CAN bus.

The book starts by putting the reader in the proper mindset for exploring the security and attack paths for a given vehicle. The first chapter gets the reader thinking about all (most) of the ways that you can interface with a vehicle to hack it and specific suggestions about how to approach each of those. He describes various ways of rating threats. One of them being DREAD. DREAD is a formal way of assessing threats with a focus on malicious intent (which other rating systems often ignore). When I first read about DREAD I thought he was going to start rating systems with the Harry Potter grading system of Outstanding, Exceeds Expectations, Acceptable, Poor, Dreadful and Troll. This section has two uses; if you modify systems it will help you figure out how to get access to a vehicle, if you build systems it will help you think about securing what you build.

Source: Robots for Roboticists. After discussing security the book switched to things that really interest me such as bus protocols, tools to work with them, and how to reverse engineer messages on those buses. For vehicles, it seems that the year 2000 was the turning point where vehicles started to use digital buses thereby being “hackable.”

Some of the buses that you should be prepared to find discussed in this book and in cars are:

• CAN (Low-speed LS-CAN, mid-speed MS-CAN, high-speed HS-CAN)
• CANopen
• GMLAN
• SAE J1850
• PWM
• VPW
• Keyword
• ISO 9141-2
• LIN
• MOST
• FlexRay
• Automotive Ethernet (& AVB)

I had no idea there were that many protocols in use and I have only heard of 2/3 of them!

The book introduces a bunch of tools for working with CAN buses, I have never used some of them but they are opensource Linux tools that seem to have nice features. I will definitely check them out next time I am working with a CAN bus. There is also an appendix at the end of the book that discusses many tools ranging from hobby level to professional. This follows up with some really basic writing of CAN drivers in Linux and how to communicate with your vehicle (the book calls it weaponizing, I guess it sounds good but I would call it using what you know to get stuff done).

Importantly, this book discusses what to do if you get into different fault conditions. For example:

• Flashing lights
• Car not turning on
• Car not turning off
• Vehicle responding recklessly
• Bricking your car !!!***@@@@##!!

That list above can be scary and the author gives some advice for handling them, however, it might have been nice if the author spent more time discussing the potential faults and how to avoid them (particularly, how not to brick your car!).

It is good to hear that most engine control units (ECU’s) have some sort of tamper protection so you can not change its firmware. However, the author does note that some of those protections are laughably weak. There are a few chapters on understating common ECU protocols, how to simulate them, and how to attack them. This is probably above what most robotic integrations would do, however, I have worked on projects where we removed an ECU and replaced it with our own that we could configure; so this is still a good topic to read. It also has some content that is good for generic embedded systems that are not covered in most embedded systems books.

One thing this book lacks is details about specific car models. I like that the core of the book is not manufacturer dependent but it would be nice to have more information about CAN codes, protocol information, pinouts, ECU configurations, etc. I think some of that high-level information might be good as an appendix, with the full expanded set of documentation as web content for readers.

This book has a good description of applied CAN hardware as well as the protocol. This is what I wish I was able to read when I first started working with CAN buses. I give this book 5 out of 5. It has really good practical knowledge for hacking your vehicle without going into a lot of theory. I would recommend this book for engineers working with embedded systems, even if they do not work with cars. I think that Smith wrote a boot about how to do stuff; which had the unintended consequence of making a great book for learning how to actually work with real systems.

After reading this book I really want to go sniff my vehicles buses and see what I can find.

I would like to thank No Starch Press for providing me with a hard copy of this book for review.

Disclaimer: I have never met the author of this book and the opinions above are mine.

The post Book Review: The Car Hacker’s Handbook by Craig Smith appeared first on Robots For Roboticists.

TReX (Tethered Robotic Explorer). Credit: utiasASRL/YouTube

Some people swear all tethers are bad. Some recommend attaching a tether to robots in order to provide power (to save the mass and volume of the batteries), for reliable fast communications, transfer of pressure or fluid, to track a robot’s position, or as a safety harness (in case the robot needs to be dragged out). However, before designing a tether there are several things you need to consider.

Here are some things to think about:

1. What should be in the tether? For example, can you put power on the robot and then only run communications to the robot?
2. Tethers can easily snag on obstacles as the robot drives. This can cause your robot to get stuck and not be able to proceed forward or get back out.
3. Tethers need to be managed so that you do not get snagged (as discussed above) and so that you do not drive over it, which can damage the tether.
4. Tethers can get bulky. The longer the tether you need, the more mass and volume you will need to carry and the more heat you will produce.
5. Tethers introduce drag, which the robot will need to overcome while driving.
6. Abrasion of the tether with use.
7. Cables, wire, and tubes in the tether can break which might incapacitate the robot. If the robot is going into a critical environment you might not be able to retrieve the robot should it fail.

Credit: Robots for Roboticists

This image (to the left) shows how a tether can tighten around corners as the robot drives. As the tether gets pulled into the corners the force on the tether increases, and increases the chance of the robot getting stuck, breaking, and making mobility more difficult.

Tension on tether base (neglecting the coefficient of friction from contact points) can be computed as shown below.

Force on a tethered robot. This shows why it is much harder to pull a robot after it has gone around a bend.

For reasons I mentioned above, tethers are often deployed from the robot, not from base equipment. In underwater applications, you can usually feed the tether from the base without the problems seen on land. When choosing where to deploy the tether from you will need to consider:

• Can your robot support the volume/mass of the tether?
• Where are the snag points?
• Volume of the tether, which is: Volume = Area of cable x length of the cable
• Heat generated by the tether from I²R losses.

This paper from Dante is a must read for anyone developing a tethered robot. Dante is a robot that flipped while trying to climb out from a volcano partially due to bad tether angles on difficult terrain. While people often point to Dante as an example of why tethers are bad, there are more examples of tethers being used successfully. In the nuclear accident of Chernobyl, a number of robotic (tele-operated) vehicles (robot pictures) were used in the recovery and cleanup. The robots were used for many things such as inspection, pushing radioactive material out of the way, turning over radioactive dirt and moving containers. Most of those robots were tethered (about 55 of the 60 vehicles). Many of those robots ultimately perished due to tether malfunctions, but that was after operating for extended times and doing good work. With new technology, better cable design, lower powered devices, better proprioception of the tether we should be able to do a better job building tethers.

TReX is another paper that you need to check out before designing a tethered robot.

This is not really related but it is an interesting video showing Chernobyl robots and video from them (at least I think, it is in Russian).

I think tethers often get a bad name, however, they can be used. In order to use a tether, the design must be carefully evaluated and the concept of operations of the robot needs to be reviewed. Once the robot is built people need to monitor the tether while the robot is operating.

The post Tether’s: Should Your Robot Have One? appeared first on Robots For Roboticists.

Time synchronization diagram.

Time synchronization affects many robots. Robots have more computers and sensors, so keeping everything in sync is important. Trying to look through log files where all of the times are skewed is not fun and makes processing difficult. Merging sensor data together with GPS can also be disastrous if the times are offset. Further complicating time synchronization is that the robots are often not connected to the internet, so utilizing public time servers will not work.

My preferred tool for time synchronization is chrony. Chrony is based on NTP, but performs better when not connected to the internet and has smoother clock adjustments, plus, is easier to get GPS and PPS signals into.

Installing time synchronization

If you are using GPS as your time source the first step is to wire the GPS to a serial port on your computer. If you want to use PPS make sure your GPS has a PPS output, such as the Garmin 16x or 18x). For wiring, I use the standard pins of 2,3 & 5 (GPS tx, GPS rx, ground) for RS-232 DB-9 serial connections, then I run the PPS line into pin 1 of the DB9 connector. I have not tried it, but I assume the GPS with no PPS would work via USB.

There are 2 methods to installing chrony that I use:
1. If a PPS (pulse per second) input is being used (such as from a GPS receiver), then we need to build chrony from source:

• git clone git://www.linuxpps.org/git/pps-tools pps-tools to get timepps.h.
• From chrony install manual
  If a ‘timepps.h’ header is available (e.g. from the LinuxPPS project), chronyd will be built with PPS API reference clock driver. If the header is installed in a location that isn’t normally searched by the compiler, you can add it to the searched locations by setting CPPFLAGS variable to -I/path/to/timepps.
• Then git clone git://git.tuxfamily.org/gitroot/chrony/chrony.git
  run .configure, make all, and make install
• I needed to run sudo apt-get install bison to get it the make all to compile

That should give you chrony with pps support!

2. If no PPS input is being used (this is the easy option):

• sudo apt-get install chrony

Now, we need to install the GPS driver. For this I use GPSD. Using GPSD is nice because it is easy and allows you to run a GPSD client that listens to the GPS, so you can also use the position for your robot. GPSD is needed to allow clients to use the GPS that is connected to one serial port.

To install GPSD:

• sudo apt-get install gpsd
  The config file in /etc/default/gps should be edited using the dpkg command to set baud rate and the port of the GPS device.

We now need to edit the chrony config file /etc/crony/crony.cong on the main computer:

• If the robot will ever connect to the internet:
  Modify the existing server lines to say offline right after the server name. ex. server SERVER_NAME offline
• If the robot will never touch (figuratively) the internet:
  Delete (or comment) all of the server lines

Now here are some settings I change:
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0

I see many people also comment out dumponexit. I am not entirely sure why.

There are 2 ways to add the GPS/PPS:
https://chrony.tuxfamily.org/manual.html
https://chrony.tuxfamily.org/doc/2.3/manual.html#refclock-directive

1:
# add socket with small delay for PPS
refclock SOCK /var/run/chrony.sock offset 0.002 delay 1e-4 refid SOCK
makestep 0.1 5
maxupdateskew 100.0

set stratum local stratum 6

2:
refclock PPS /dev/pps0 lock NMEA
refclock SHM 0 offset 0.5 delay 0.2 refid NMEA noselect

On any secondary computers that need to sync with the main computer here is what I do

Remove all existing servers and then add our server:
makestep -1 100
# replace IP below with your server
server 192.168.10.2 minpoll 1 maxpoll 2

I see many people also comment out dumponexit. I am not entirely sure why.

Running time synchronization

1. Start GPS Daemon: sudo gpsd -n -N -D2 /dev/ttyS0 Changing /dev/ttySx for the port you can GPS connected to

• You should see a bunch of lines such as: gpsd:INFO PPS cycle…
• This can also be run from an init.d script

2. Running chrony: sudo /etc/init.d/chrony start

The two commands I use most for debugging and checking status are chronyc tracking and chronyc sources.

• The tracking command shows how good your current time is and what the offset of your system clock is.
• The sources command shows information about which sources are available, their status, and when they last were checked. If you are connected to the internet you will see a bunch of servers. If you are just connected to GPS and PPS you will just see those sources.
• A good reference for the commands above is here.

Output of tracking and sources command for chrony while using GPS. If PPS was enabled it would also show as a source. Source: Wikipedia Commons

One thing to be aware of is that with just GPS and no internet time servers I often see it can take 10 minutes for the chrony server to enter online mode. When checking any status such as cronyc sources you get an error saying 506 Cannot talk to daemon. After connecting to an internet time server or waiting about 10 minutes chrony will come online and start working.

I know there is a lot of detail above, and you might need to tweak things for your application, but I hope it help and you can look back as a reference.

The post chrony with GPS for Time Synchronization – Kicks NTP’s A$$ appeared first on Robots For Roboticists.

Different wheels for robots and rovers. Credit: CC0 public domain

In the past, we have looked at wheel design and the kinematics of skid steer and mecanum wheels. In this post, we will take a quick look at different types of mobility types (ie. wheels, tracks) and how to connect them. 

I know the items in this list are not direct comparisons. For example, listing rocker bogie is not necessarily exclusive to other types listed. Also, I know that you can design a vehicle to get around the pros and cons that I list below. The list is based on the common mechanical configurations.

For the purpose of this post:

• Holonomic motion: is where a vehicle can go in all X and Y directions and is not constrained.
• Non-holonomic motion: is where a vehicle is constrained to only certain motions. An example is a car that is not capable to drive sideways (with its ackerman steering). Don’t yell at me about the parallel parking magical cars. They are not the norm.

Source: Robots for Roboticists

*Mecanum X vs O configuration is based on how the wheels are mounted. With mecanum wheels the left and right side wheels are physically different. Looking from the bottom you want an O configuration. The X configuration does not allow rotation (without fighting the rollers).

Mecanum wheel configurations. When viewed from the bottom the direction of the rollers form an X or an O shape.

** Basic description of inchworming. Inchworming moves one set of wheels at a time to utilize static friction for increased mobility.

Inchworming image. Image on left shows standard driving. Images on right shows inchworming during each of the two stages of motion. The top image shows the robot lowering while moving the front wheel. The bottom image shows the robot raising up while pulling the rear wheel in.

First described here and further examined by others.

For more examples of unusual locomotion methods, visit unusuallocomotion.com.

Are there other mobility options that I should have included?

Drive Selection – Wheels, tracks and more appeared first on Robots For Roboticists.

Photo: Wikipedia

I am often in need of the basic kinematic motion equations for skid steer vehicles. I have also recently been working with mecanum wheeled vehicles. The skid steer equations are fairly simple and easy to find, however, I will include it in different versions and include a ROS approach. The mecanum wheel equations are harder to find and there are different versions floating around. The first version I found had a lot of trig and mostly worked. The version I present here is easier to intuitively understand and seems to work better (I don’t need a random scale factor for this version), I also include a ROS approach for them.

Skid Steer / Differential Drive

Here is some math for 2 and 4 wheel differential drive vehicles, 2 wheels and a castor, or skid steer tracked vehicles.

Arc based commands

The basic skid steer equations are:

velocity_right = w(RADIUS_OF_ARC_TO_DRIVE + WHEEL_BASE/2)
velocity_left = w(RADIUS_OF_ARC_TO_DRIVE – WHEEL_BASE/2)

Where w is the angular rotation, RADIUS_OF_ARC_TO_DRIVE is the arc radius that the robot should drive, and the WHEEL_BASE is the distance from the center of the left wheel to the center of the right wheel (See image above).

This can also be written as:

w = (velocity_right-velocity_left)/WHEEL_BASE

There are two special cases:

IF velocity_right == velocity_left :
THEN the radius of the arc is infinite so the robot will drive straight.

IF velocity_right == -velocity_left :
THEN the radius of the arc is 0, and the robot rotates in place (ie. point turn)

Linear & Angular Velocity Commands for ROS

In ROS if using the Twist topic (which is the default for drive messages) (message name is often cmd_vel) you will often set linear_velocity in the linear.x field and angular_velocity in the angular.zfield.

velocity_left_cmd = (linear_velocity – angular_velocity * WHEEL_BASE / 2.0)/WHEEL_RADIUS;

velocity_right_cmd = (linear_velocity + angular_velocity * WHEEL_BASE / 2.0)/WHEEL_RADIUS;

Mecanum Wheel Math

Mecanum wheels from Andymark

In ROS if using the Twist message you will often set the linear.x, linear.y and angular.z fields. One unrelated note is that if you are operating on uneven terrain then doing mecanum type motions will fail and have a lot of slip. Skid steer type motions will often work better (using the mecanum wheels).

WHEEL_SEPARATION_WIDTH = DISTANCE_LEFT_TO_RIGHT_WHEEL / 2

WHEEL_SEPARATION_LENGTH = DISTANCE_FRONT_TO_REAR_WHEEL / 2

Forward kinematics

Wheel commands units are in rad/s

wheel_front_left = (1/WHEEL_RADIUS) * (linear.x – linear.y – (WHEEL_SEPARATION_WIDTH + WHEEL_SEPARATION_LENGTH)*angular.z);

wheel_front_right = (1/WHEEL_RADIUS) * (linear.x + linear.y + (WHEEL_SEPARATION_WIDTH + WHEEL_SEPARATION_LENGTH)*angular.z);

wheel_rear_left = (1/WHEEL_RADIUS) * (linear.x + linear.y – (WHEEL_SEPARATION_WIDTH + WHEEL_SEPARATION_LENGTH)*angular.z);

wheel_rear_right = (1/WHEEL_RADIUS) * (linear.x – linear.y + (WHEEL_SEPARATION_WIDTH + WHEEL_SEPARATION_LENGTH)*angular.z);

To drive a robot you will probably need to also invert one side since the motors are mounted opposite the other side. For example:

wheel_front_right = -1 * wheel_front_right

wheel_rear_right = -1 * wheel_rear_right

Also this gives an output in rad/s. If your motor controller is operating with encoder counts as the unit you will need to convert the units.

Inverse Kinematics

linear.x = (wheel_front_left + wheel_front_right + wheel_rear_left + wheel_rear_right) * (WHEEL_RADIUS/4)

linear.y = ( -wheel_front_left + wheel_front_right + wheel_rear_left – wheel_rear_right) * (WHEEL_RADIUS/4)

angular.z = ( -wheel_front_left + wheel_front_right – wheel_rear_left + wheel_rear_right) * (WHEEL_RADIUS/(4 * (WHEEL_SEPARATION_WIDTH + WHEEL_SEPARATION_LENGTH)))

Source for mecanum wheel math: here. There are other versions of how to compute the wheel velocities but this is the one I like best.

If you have any pressing questions, visit the Robots for Roboticists Forum.

The post “Drive Kinematics: Skid Steer & Mecanum (ROS Twist included)” appeared on Robots For Roboticists.

When building a new robot mechanical engineers always ask me: how close can different antennas be to one another? It is not uncommon to try squeezing 5+ antennas on a single robot (GPS, GPS2 for heading, RTK, joystick, e-stop, communications, etc..). So what is the proper response? The real answer is that it depends heavily on the environment. However, below are the rules of thumb I have learned and have been passed down to me for antenna separation. I do want to give a disclaimer some of this has been passed down as rules of thumb and may not be 100% correct.

Here is the rule: The horizontal distance between antennas should be greater than 1/4 of its wavelength (absolute minimum separation), but it should not be located at the exact multiples of its wavelength (maybe avoid the first 3-4 multiples). If multiple frequency antennas are near each other, then use the spacing distance of the lower frequency antenna, or even better, try to satisfy the rule for both frequencies.

Here is a nice wavelength calculator I just found to generate the table above.

* If you are using two GPS antennas to compute heading then this does not apply. These numbers are strictly for RF considerations.

So, for example, if you have a GPS antenna and a WiFi 2.4GHz antenna you would want them to be separated by at least (more is better, within reason) 8.33cm. And you should avoid putting them at exactly 24.43cm or 33.3cm from each other.

This rule seems to work with the low power antennas that we typically use in most robotics applications. I am not sure how this would work with high power transmitters. For higher power transmitting antennas, you might want greater separation. The power drops off pretty quickly with distance (proportional to the square of the distance).

I also try to separate receive and transmit antennas (as a precaution) to try and prevent interference problems.

An extension of the above rule is ground planes. Ground planes are conductive reference planes that are put below antennas to reflect the waves to create a predictable wave pattern and can also help prevent multipath waves (that are bouncing off the ground, water, buildings, etc…). The further an antenna is from the ground (since the ground can act as a ground plane), the more likely having a ground place becomes necessary. In its simplest form, a ground plane is a piece of metal that extends out from the antennas base at least 1/4 wavelength in each direction. Fancy ground planes might just be several metal prongs that stick out. A very common ground plane is the metal roof of a vehicle/robot.

Note: Do not confuse ground planes with RF grounds, signal grounds, DC grounds, etc…

Aerial roof markings on London police car. Source: Wikimedia Commons

An example of building a ground plane can be with a GPS antenna. It should be mounted in the center of a metal roofed robot/car or on the largest flat metal location. This will minimize the multipath signals from the ground. If there is no flat metal surface to mount the antenna you can create a ground plane by putting a 12.22cm diameter metal sheet directly below the antenna (about 1/2 the signals wavelength, which gives 1/4 wavelength per side).

Note: Some fancy antennas do not require that you add a ground plane. For example, the Novatel GPS antennas do NOT require you to add a ground plane, as described above.

Other things to watch out for are shadowing between the antennas and sensors and the fresnel zone. For more information on the fresnel zone, and why antennas are not actually just line of site, click here.

Code review of a C++ program with an error found.

I have been part of many software teams where we desired to do code reviews. In most of those cases the code reviews did not take place, or were pointless and a waste of time. So the question is: how do you effectively conduct peer reviews in order to improve the quality of your systems?

I found this book, Peer Reviews in Software: A Practical Guide by Karl E. Wiegers. This book was recommended to me, and having “practical guide” in the title caught my attention —  I have reviewed other books that claimed practical, but were not. Hopefully this book will help provide me (and you) with tools for conducting valuable code reviews.

Peer Reviews in Software: A Practical Guide. Photo: Amazon

As a human, I will make mistakes when programming; finding my mistakes is often difficult since I am very close to my work. How many times have you spent hours trying to find a bug in your code only to realize you had a bad semi-colon or parentheses? Another person who has not worked on the code for hours might have been able to spot the problem right away. When I first started programming it could be embarrassing to have somebody review my code and point out the problems. However now that I am more senior, I do not view it as an embarrassment, but as a learning opportunity since everybody has a different set of experiences that influences their code. I would encourage other developers to view it as a learning experience and not be bashful about reviews. Remember the person is critiquing the work, not you; this is how to become a better developer.

According to Wiegers, there are many types of peer reviews including: inspections, team reviews, walkthroughs, pair programming, peer desk check passaround, and finally ad hoc review.

This book is divided into three sections:

1. Cultural & social aspects
2. Different types of reviews (with a strong focus on inspection)
3. How to implement review process within your projects

Cultural & Social Aspects

In this first section of the book, the author makes the argument that quality work is not free and that “paying” the extra cost of peer reviews is a good investment in the future. By having peer review you can reduce failures before the product is released out into the world and any applicable reworks. Shifting the defect detection to the early stages of a product has huge potential payoff, due to high costs of fixing defects found late in the release cycle, or after release. The space shuttle program found the relative cost for fixing a defect is: $1, if found during initial inspection; $13, if found during a system test; and $92, to fix after delivery! In the book, the author documents various companies who saved substantial amounts of time and money all by having code inspection programs.

One thing I like is the reference to IEEE 1999, which talks about other items that are good to review. People don’t think about it but other things, such as marketing brochures, requirement specifications, user guides, test plans and many other things, are good candidates for peer review.

I have seen many project teams try to do error tracking and/or code reviews but fail, due to team culture. I saw one case where peer review actually worked: when a dedicated person’s only job was to manage reliability in the project. He was great at hounding people to track bugs and review code. This book discussed how team culture must be developed to value “quality”. If you are the type of person that does not want to waste time reviewing another’s code, you must remember you will want the other person to “waste” time looking at your code. In this manner, we must all learn to scratch each other’s back. There are also two traps to watch out for:

1. Becoming lazy and submitting bad code for review since somebody else will find/fix it, or
2. Trying to perfect your code before sharing it, in order to protect your ego from getting bruised, and to only show your best work.

We also cannot forget managers. Managers need to value quality and provide time and resources for employees to develop good practices. Managers need to understand the point of these exercises are to find flaws and people should not be punished based on those flaws. I have often seen managers not putting time in the schedule for good code reviews.

Types of reviews

Before discussing the types of reviews there is a good discussion on the guiding principles for reviews. Some of the principles are:

• Check your egos at the door
• Keep the review team small
• Find problems during review, but don’t try to fix them at the review. Give up to 1 minute for discussion of fixes.
• Limit review meeting to 2 hours max
• Require advanced preparation

There are several types of peer reviews discussed in this book. This list starts with the least formal approach and develops until the most formal approach (the book uses the opposite order which I found non intuitive).

1. Ad Hoc – These are the spur of the moment meetings where you call a coworker to your desk to help with a small problem. Usually, this just solves an immediate problem. (This is super useful when trying to work out various coordinate transforms)
2. Peer passaround/deskcheck, – In this approach a copy of the work is sent to multiple reviewers, after which you can then collate all of the reviews. This allows multiple people to look at the code/item and also lets you get something if one person does not respond. In the peer deskcheck version, only one person looks at it instead of passing it around for multiple reviews.
3. Pair Programming – This is the idea that two people program together. So while there is no official review two sets of eyes see each line of code being typed. This has an added bonus that now two people will understand the code. The downside is that often one of the coders can “doze-off” and not be effective at watching for flaws. Also, many coders might not like this.
4. Walkthrough – This is where the author of the code walks through the code to a group of reviewers. This is often unstructured and heavily dependent on how good of a job the author prepared. In my experience this is good for helping people understand the code and finding large logic flaws, but not so much for finding smalls flaws/bugs.
5. Team Review – This is similar to the walkthrough however reviewers are provided with documentation/code in advance to review and their results are collated.
6. Inspection – Finally, we have the most formal approach which the author appears to favor. In this approach the author of the code does not lead the review, rather, a moderator, often with the help of checklists, will lead the meeting and read out the various sections. After the moderator reads a section, the reviewers discuss it. The author of the code can answer questions and learn how to improve various sections. Often the author might identify other instances of the same problem that the reviewers did not point out. An issue log should be maintained as a formal way of providing feedback and a list to verify fixes against.

Suggested review methods from “Peer Reviews in Software”

The book then spends the next few chapters detailing the inspection method of peer review. Here are just a few notes. As always, read the book to find out more.

• In most situation 3-7 is a good size group for the inspection. The number of people can be based on the item being reviewed.
• The review needs to be planned in advance and have time to prepare content to distribute to reviewers.
• After the meeting the author should address each item in the issue log that was created and submit it to the moderator (or other such person) to verify that the solutions are good.
• Perform an inspection when that module is ready to pass to the next development stage. Waiting too long can leave a person with a lot of bad code that is now too hard to fix.
• You can (sort of) measure the ROI by looking at the bugs found and how long they took to find. There are many other metrics detailed in the book.
• Keep spelling and grammar mistakes on a separate paper and not on the main issue list.

How to implement review processes within your projects

Getting a software team and management to change can be difficult. The last part of this book is dedicated to how you can get reviews started, and how to let them naturally grow within the company. One significant thing identified is to have a key senior person act as a coordinator for building a culture of peer review and to provide training to developers. There is a nice long table in the book of the various pitfalls that an organization may encounter and how to deal with them.

This book also discusses special challenges and how it can affect your review process. Some of the situations addressed are:

• Large work products
• Geographic or time separation
• Distributed reviewers
• Asynchronous review
• Generated and non-procedural code
• To many participants
• No qualified reviewers available

At the end of this book, there is a link to supplemental material online. I was excited to see this. However when I went to the site, I saw it was all for sale and not free (most things were around $5). That kind of burst my bubble of excitement for the supplemental material. There is a second website for the book that is referenced but does not seem to be valid anymore.

Throughout the book the idea is getting proper training for people on how to conduct inspection reviews. Towards the end of the book, the idea of hiring the book’s author as a trainer to help with this training is suggested.

Overall, I think this is a good book. It introduces people on how to do software reviews. The use of graphics and tables in the book are pretty good. It is practical and easy to read. I also like how this book addresses management and makes the business case for peer reviews. I give this book 4.5 out of 5 stars. The missing 0.5 stars is due to the supplemental material not being free and for not providing those forms with the book.

Disclaimer: I do not know the book author. I purchased this book myself from Amazon.

The book starts with an introduction to ROS. The introduction does a good job describing the basic ROS constructs such as the directory structure, nodes, services, etc. and goes into detail to describe those constructs. The book continuous to show how to create ROS packages, add custom messages (topics), and creating launch files. The first chapter has everything you need to get a basic ROS system up and running. One thing missing is how to have your launch file start on computer boot up (using the “ROS way” as opposed to just adding it to rclocal).

The book can use more information on using the catkin build system and CMake. I am not sure if that is fair to expect in this book, but it is an essential skill to develop with ROS, and is not listed as a skill that people using this book are expected to have.

ROS only supports versions of Ubuntu that are around when that version of ROS was released. In general, ROS is not upgraded when a new version of Ubuntu is released (this is one of the things that I dislike about ROS). To deal with this, the examples in the book are given for both ROS Indigo (the prior version) and ROS Jade (the current version). Good job to the author for that!

After you are given the basics of ROS, the rest of the book is roughly split into three sections: ‘Modeling, Simulating & Autonomy’, ‘Working with Hardware’, and an example.

For Modeling, Simulating & Autonomy, the book starts with a chapter on how to model your robot with URDF. Afterwards you use the model created to simulate it using Gazebo and learn how to add planning and autonomy to arms and mobile robots. There is an extra chapter dealing with advanced usage of MoveIt for robotic arms, I would have liked to see an advanced chapter for the Navigation Stack. I also would have liked more information on using the transforms within the Navigation Stack. With that said, I am happy the book addresses these items as many other authors do not.

After getting the high-level tour of ROS and making an autonomous robot with existing nodes, the book steps back to teach the reader how to build controllers, work with hardware, (controllers, motors, sensors, cameras, etc.) and visualizations. The book has many examples of working with specific hardware items such as Arduino, Raspberry Pi, Kinect, webcams, Hokuyo, & the Velodyne. Adding a joystick to that list might have been nice. Working with OpenCV and PCL within ROS has a dedicated chapter.

At first I was skeptical of having an example section since I have seen many books do this poorly, however, this book does a good job describing in detail how to configure an example robot without making you feel like they are just regurgitating what they built. It also has more details about the Navigation Stack, which partially makes up for not having an advanced chapter on it.

The best practices section at the end of the book could have had more ROS specific practices, instead of just generic C++ practices. I like the fact that the book uses c++ as that is how most robots are built. It would have been nice to have a chapter with basic discussions on python and java usage. The author briefly mentions setting up ROS on distributed systems, this could be expanded a little (such as in the roswtf section for looking at timing).

Overall, I give this book 4.5 out of 5 stars. By going into detail for both robotic arms and mobile robots, this book is sure to help both a novice or experienced programmer enter the world of ROS and get their robots up and moving.

Note: The paperback book has black and white images. I think the e-book has color images.

I would like to thank the Publisher PACKT for providing me with a copy of this book for review.

Some words of disclaimer:
I have never met the author of this book and the opinions above are mine.

If you enjoyed this post, you might also like:

• Book Review: Practical Field Robotics, by Robert Sturges
• Book Review: Implementation of Robot Systems, by Mike Wilson

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

There are some specialty cases that can make this problem easier. Most USB devices (in Linux) show up as /dev/ttyUSBX, where X is the number in which that device was initialized (ex. /dev/ttyUSB0). Some devices will come up differently. For example Hokuyo LIDAR’s show up as /dev/ttyACMX. And USB joysticks show up as a joystick device in /dev/input/jsX. So if you have one each of a joystick, a Hokuyo, and a motor controller, you might get lucky and have them all map to different devices. But for the many times you are not lucky, how should you deal with it?

(Random note: ACM refers to a USB modem. Most devices that we use are not really modems and just ‘lie’ and claim to be an ACM device (often when they do the USB “stuff” on the main processor). Many USB-to-serial converter chips (such as FTDI) do not lie and show up as /dev/ttyUSB.)

The traditional answer is to use udev rules. The basic idea is to make a file in /etc/udev/rules.d/ that will control how a device gets mapped and started. This allows you to change the links, change permissions, or run a script when a device is detected. A basic udev rule can follow the format of:

SUBSYSTEMS==”usb”, KERNEL==”ttyACM[0-9]*”, ACTION==”add”, ATTRS{idVendor}==”15d1″, ATTRS{idProduct}==”0000″, MODE=”666″, PROGRAM=”/opt/ros/hydro/lib/urg_node/getID /dev/%k q”, SYMLINK+=”sensors/hokuyo_%c”, GROUP=”dialout”

A great tutorial on udev (and also where I got the rule above) is the “Do more with udev” tutorial from Clearpath Robotics.

In my experience using udev rules work well to set startup permissions (to allow non-root access to the device) or to run a script when a device is connected. However the symlink that maps a device to a specific name will sometimes create a link that you cannot open (ie. when open(/dev/newSymLink) fails). There are also cases where you cannot use udev in certain embedded systems or where you do not want to “install” udev rules.

There are several ways to avoid using udev. For example you could run the dmesg command to find where the USB device was connected. Another way is to have a script run whenever a device is plugged in that updates a text file that stores the device name.

Another solution (presented below) is ugly but it has tested well in cases where udev was giving me a hard time. The solution below is easier than parsing dmesg and does not require a udev rule to create a symlink that needs to be installed.

The first step, which I got from here, gets the mapping of all your devices and the associated port numbers.

#!/bin/bash
for sysdevpath in $(find /sys/bus/usb/devices/usb*/ -name dev); do
(
syspath=”${sysdevpath%/dev}”
devname=”$(udevadm info -q name -p $syspath)”
[[ “$devname” == “bus/”* ]] && continue
eval “$(udevadm info -q property –export -p $syspath)”
[[ -z “$ID_SERIAL” ]] && continue
echo “/dev/$devname – $ID_SERIAL”
)
done

Running the script above will give you a list of all the attached USB devices. You can save the script above into a file called list_usb_devices.sh.

The next step is to run that script from your program. To do that I found some code that allows you to run a system call and get the output into a string.

#include <string>
#include <iostream>
#include <cstdio>
#include <memory>

std::string system_exec(char* cmd)
{
std::shared_ptr pipe(popen(cmd, “r”), pclose);
if (!pipe) return “ERROR”;
char buffer[128];
std::string result = “”;
while (!feof(pipe.get())) {
if (fgets(buffer, 128, pipe.get()) != NULL)
result += buffer;
}
return result;
}

Adding the above to the driver for the USB device, you can now use the following to get the port that you need to open:

// get the names, grep to search for the device we want, cut the name of the port from the full line of text
std::string port = system_exec(“//list_usb_devices.sh |grep -m 1 |cut -c 1-12″);

// Get rid of any newlines (n) in the string
port.erase(std::remove(port.begin(), port.end(), ‘n’), port.end());

// switch to string to c style for using in the open command
const char * device = port.c_str();

// Finally we can now open our device
fd = open(device, O_RDWR | O_NOCTTY);

This approach is ugly, but it works. By simply using the bash script and the system call from the c++ portion you can easily adapt this to any programming environment.

The above approach is often the wrong approach (since it is ugly), but it can help when udev is not working as expected or it can not be used.

I still avoid using USB devices when possible since they are a pain and are often not reliable. However if you must use them, then the information above **might** make your life a little better. I hope it helps! Please leave comments below if this helped you or with other ways to handle USB devices.

SparkFun Inventor’s Kit for RedBot.

I get many questions from people about how I think kids and adults should get started in robotics, how they should progress, and what they should buy, to learn about robotics. This is a quick guide to help you get going.

I’ve described three levels below — Level 1 is for people older than 12; Level 2 is for people older than 15, and Level 3 is for people over 18. An adult can probably start at Level 2 if desired, however starting at Level 1 will give you important basic skills and knowledge that you can build on.

Don’t worry about the details. You do not need to learn how SPI or wifi work, for example, but you will slowly pick up the details as you use them.

Level 1 – Getting Started with Micros

1. Set a clear and realistic goal – Robots are hard, so match your expectations to your skills. Your first robot should be really simple.
2. Recommended Book – Make: Arduino Bots and Gadgets: Six Embedded Projects with Open Source Hardware and Software and Arduino Robot Bonanza
3. Get your hands dirty – Learn how to mechanically and electrically build a robot.
   • For this task, design and build a robot that uses an Arduino Uno, 2-4 motors, 2-4 simple sensors, a switch, a LED and a battery.
   • The Sparkfun Inventors Kit for Redbot is a great choice for this step.
   • Design on paper what the robot should look like and the parts that you need (if you buy a kit, use it, but then modify it).
   • Build the robot using basic hand and power tools.
4. Learn how to program – Use the Arduino to program the robot.
   • Start by simply making the light on the Arduino blink. If you have never done this before, it will take longer than you think it!
   • Spin a single motor.
   • Read from your sensors and play with them – use Microsoft Excel to generate a calibration curve.
   • Combine the sensors and motor code to do what you desire.
5. Join a robotics club – There are many options! For example:
   • School robotics club
   • First Robotics
   • Society of Robots

Level 2 – Getting Started with Embedded Computing

1. Set a clear and realistic goal – Build upon what you learned in Level 1 to set goals for level 2.
2. Recommended Book – Make a Raspberry Pi-Controlled Robot: Building a Rover with Python, Linux, Motors, and Sensors
3. Get your hands dirty – Learn how to mechanically and electrically build a robot.
   • For this task, design and build a robot that uses a Raspberry Pi computer, 2-4 motors, 2-4 sensors, and a battery
   • Design your parts with a CAD tool (such as Google Sketchup or Solidworks)
   • Think about how you will interface your sensors to the computer?
   • Use new materials and construction techniques. Try to use a 3D printer or laser cutter if possible.
4. Learn how to program – Use the Linux computer to program the robot.
   • Learn basic C++ or Python, try talking to serial ports.
   • Make your robot act as desired.

Level 3 – Advanced Computing

1. Set clear and realistic goals – You should increase the difficulty of your goals as you advance. At this point, try setting a goal that you’d like to attempt, even if you are not sure you can achieve it.
2. Learn basic trig and statistics – Learn the basic math that you need for robotics.
3. Get someone else’s hands dirty – Design a part and shop it out to be machined.
4. Learn how to use more advanced sensors – Such as a Camera and/or LIDAR.
5. Software – Learn the Robot Operating System (ROS).
6. Algorithms – Continue making software more advanced. Autonomy, mapping, device drivers, etc…

Each level will take time to develop and learn, but following this path will ensure that you have the knowledge you’ll need to progress to the next level.

Additional Resources

I tend to like Sparkfun for buying hobby parts. Other places you should look are Adafruit, and Pololu. They all have blogs and tutorials for using the hardware they sell, including basic robotics, Arduino, and Raspberry Pi.

To start with the simple devices … having a fuse where the batteries enter the system is a good idea. After that I like to fuse each voltage rail (ie. DC-DC converter) so that we can take groups of sensors/computers offline at a time for testing as well as for the protection the fuses provide. I think fusing each bus is often a good compromise between fusing everything and fusing nothing.

The place where fusing gets tricky is with motors. To start, whenever you have a lot of energy (relative to your system) being converted from mechanical to electrical energy through your motor, a shunt regulator should be used. Any time your motors might be back driving, decelerating quickly, or dropping due to gravity (such as in a robotic arm) you have the potential for the voltage on your power bus to increase. When the voltage starts increasing you can burn out the components on your bus. For example if your motor controller is rated for 55V Maximum and you are driving a 48V motor, it is very easy for the back driving of the motor to raise the voltage above that maximum value. Remember Every motor is a generator; and every generator is a motor – it just depends which direction you spin it. The solution to this problem is to put a shunt regulator on your bus.

A shunt regulator is pretty much a big resistor that can shunt energy to ground in order to prevent the bus voltage from increasing to dangerous levels and destroying your robot. You generally want to set (or purchase) the shunt regulator at a value higher than the bus voltage. For example on a 48V motor you might want to set the shunt regulation voltage to 56V. One thing to be careful about is if your motors are on the main bus with the batteries, and you are charging the batteries in place, then the bus voltage increases from the charger. The shunt regulator voltage setpoint must be higher than the highest voltage that your battery charger will use while charging the batteries. Wiring the shunt regulator is super-simple. All you need to do is run two wires to the positive and ground rails of the power bus that you are trying to protect.

It’s common to go ahead and put a fuse before each motor driver (and its motor), and put the shunt regulator on the main bus (with no fuse). This looks pretty but you just set yourself up for problems: if the fuse blows, the amplifier is now disconnected from the shunt regulator, allowing the voltage to increase on that segment and destroy your motor (and driver)!

So what is the solution? There are generally two approaches:

• Do not fuse each motor driver individually. This lets you put all your motors and the shunt regulator on the same segment, so that if the fuse blows there is still a path to the shunt regulator.
• Fuse each motor driver separately. However you put a power diode across the fuse to allow current to flow from the motor amplifier to your main bus where the shunt regulator is.

There are two other approaches for this that are seldom used in robotics.

• You can put a shunt regulator next to each motor driver, but this is often not done due to cost and volume.
• You can increase the capacitance of your power supply/system, allowing it to store more energy.

When you choose the value for the fuse there are generally two approaches:

1. Choose the value based on what you expect currents to be (plus some margin).
2. Select a fuse based on protecting a device from the maximum current that will destroy it.

When you select fuses for a motor you will often want to use the second method of selecting a fuse just to avoid having to deal with voltage spikes blowing fuses. An example of when you might want the first option is if you want to limit current so something will not damage its environment if things go bad. You will also usually want to get a slow blow fuse and not a fast or quick blow fuse. This will give a little extra margin before the fuse blows to handle small transients.

There are several places to purchase shunt regulators from. Two of the common sources are Maxon Motors and Advanced Motion Controls. In some cases you can get a shunt regulator integrated into your motor driver, for example Galil Motion Control has some nice (and inexpensive) integrated options.

Here is an interesting app note from Galil Motion Control about computing voltage increases.

Main image is from Advanced Motion Controls.

Practical Field Robotics: A Systems Approach

This book has two primary sections. The first part of the book looks at three different example robotic systems from the domains of nuclear service robotics (teleoperated), mining robotics (large and autonomous), and a grass cutting robot (cheap consumer product). The second part of the book focuses on moving beyond those designs to cover the detailed software and systems that make a robot work.

The author presents a series of layers that can be applied to systems to characterize and guide a design. These layers are a way to guide the definition of requirements in order to build a robotic (or any other) system.

• Field Environment – This is where the operating environment needs to be defined. These items can include: thermal, radiation, humidity, site layout, terrain, water, dimensions of interest, etc.
• Field Work – This includes the tasks that the robot needs to complete in the environment from above.
• Equipment Requirements – What constraints need to be placed on the robot due to the layers above. For example in a reactor building you can not use halogens on your robot/equipment.
• Conceptional & Operational Designs – This layer is where you can really spend a lot of time. This is where you take the requirements and constraints that you defined in the above layers and actually create the high level details for the system that you will build. This can include creating concept of operations, figuring out what a mechanism should be, and determining your high level design.
• Safety & Reliability – Once you have a basic design you need to evaluate the safety and reliability of the resultant design. This applies to the robot, the operators, the environment, etc. Note that this comes before the detailed design is completed.
• Detailed System Design – <system> – Once you have a basic design and you make sure it will be safe and reliable you are finally able to create the detailed design that you will build. You can have multiple instances of this layer for each of your various systems.

One thing I ignored above is that the author discusses creating free body diagram’s (FBD) to help design the above systems.

The second half of the book moves on to the next levels of design. For example when performing the exercises above you create an FBD that has a block for Send Sound. The next level is detailing that block; you can create an FBD of that step alone. The author expands this by discussing the electronics, software (assembly style code) and how to set parameters in order to execute a Send Sound block. The author does this for several different types of functions. In practice the second half of the book is just a detailed view into how they built their robotic lawnmower project.

The author says several times that “This book covers electronic, electrical, mechanical, control, and software disciplines as needed,” however I disagree. The book does discuss some small details of the above and I guess it maybe meets the “as needed” clause that is on that assertion. However when it comes to building “Practical Field Robotics” I do not think there is any real discussion about the electronic, electrical, mechanical, and controls needed. There is a chapter that details software but it is pretty specific to the autonomous lawn mower project that is discussed. I expected it to cover the high level modules that a robot would need, but instead it is a very detailed review of the code needed for their robotic lawnmower project.

I think the first half of this book is a useful approach to systems engineering. However I am not sure how valuable the second half of the book is. I think if the author added another section to the book describing a systems-level approach to electrical, mechanical, etc. that would be great. You could imagine looking at a power system from the batteries to different DC/DC converts, to shunt regulators, etc. You could also imagine looking at basic mechanical systems such as 4-bar linkages and motors. This systems approach can be pushed even farther if we discuss sensors. However that was not done.

In conclusion if your goal is to learn how to build a field robot this book might not be for you. If you are looking to study systems engineering, then this book is worth the read.

I would like to thank Wiley for providing me with a hard copy of this book for review.

Some words of disclaimer:
I have never met the author of this book and the opinions are mine.

I define embedded as any custom-built computer system, not only tiny devices. In many cases you can develop on the computer itself for ease of development, however in other cases you will need to be able to set up a cross compile environment (for example if you have a slow ARM computer and you want to compile things on your fast Intel i7 processor).

This post will give you a high level list of the steps I take when setting up my Linux systems, with links for more information is some cases.

Linux is great since you can modify just about anything, it is free, you can strip out components you do not need, and you can configure just about anything (including the scheduler). The downside is that you can configure just about anything and break something in the process. Linux also tends to be a little behind when new technologies are released; common problems have been wireless cards, SSDs, firewire and USB3. Linux is in essence just a kernel that let’s you build operating system distributions on it. Some of the common distros are Debian, Ubuntu (I know this is Debian, but this is the flavor that is very common, supported, and one that I often use), Fedora, Suse, and Wind River.

A common question is whether you need a real-time version of Linux, and the answer is that most people do not. Look at your system and determine how critical it is to have guaranteed timing that an event will happen within a specific time allotment; usually the answer is no. I heard a speaker from Space X who said they mostly just use Ubuntu and not any real-time system on their rockets. If you do need real-time Linux, there are several variants including Wind River (costs $$$) and RTEMS (FREE).

There are many people who come from the world of servers who want to setup virtual machines (VMs) and use the Linux VMs to run the robot. I generally don’t like this. I have had many reliability problems from VMs that are constantly being turned on and off. I have also had VMs randomly not recognize devices/ports that are then recognized with a reboot. You also take a large performance hit since there is a lot of overhead in running a VM. The notion that you can have a VM on the robot and then a VM on your desktop for development usually does not work since they do not stay in sync. If you are mass producing a system, then you should just create a master drive or image, and clone that to all of the other drives; a VM is not needed.

Here is a rough list of steps for how to convert your Linux system into an embedded system:

1. Choosing a filesystem. Select a volatile RAM drive for maximum reliability (and hardest development cycle). For a generic drive use journaling for reliability if the system crashes or shuts down uncleanly. In Linux this generally means EXT3 or EXT4.
2. Set the OS as read-only so you can handle system crashes. Learn more.
3. Set bootloader to not stop on failure. This is especially true for new versions of Ubuntu; if the computer does not shut down cleanly it will halt at the bootloader until you press a key. Learn More.
4. Set BIOS (I know this is not technically Linux) to autostart when power is applied (the default is to use the switch on the computer).
5. While I am in the BIOS I will often enable some of the options to speed up boot time, including reducing the length of the countdown before booting.
6. If large amounts of storage are needed, use an SSD for the OS and a spinning disk drive or second SSD for the data.
7. Change the default setting to not do a disk scan after X days or X boots. If your computer decides to do those scans you tend to stand around thinking your robot is broken, and then after it finally boots you wonder how it fixed itself.
8. Have a system watchdog. This will let you detect if your software crashes so you can restart the system. At minimum you can add a software watchdog. Even better is to purchase a computer with an integrated hardware watchdog.
9. Create a script in /etc/init.d/ for starting your process. Any paths you use should be absolute (and not relative) paths. The newer way to do this is with upstart, though I don’t have much experience with this yet.
10. Add symlinks to your /etc/init.d/ in /etc/rc*.d for the code you want to run at a given runlevel. I usually put a symlink into /etc/rc2.d/, /etc/rc3.d/, and /etc/rc5.d/. The other way to do this is to just edit the /etc/rc.local file.
11. Add /etc/udev entries for mapping devices (such as USB). This can sometimes be a tricky process that needs some experimentation with to get right. Learn More.
12. Add other drives to /etc/fstab so that the drives come up the same with proper mount points and permissions every time. One thing to watch out for is that if the drive is not available, fstab might panic and not boot fully. If you think your drive might not be available (or you just want to be cautious) you can set nofail as one of the options.
13. Disable all software updates (except maybe security updates). I have seen many times where a software update will break code that has been working for a long time.
14. Good tools to install are ssh (or openssh) server and rsync for managing and updating code.
15. Use GCC tool chains when possible. Do NOT mess with other tool chains unless you have a very good reason.
16. Use top or htop to monitor system usage after loading your code. I try to only use around 75% of CPU and memory to allow for mostly repeatable code timing.
17. If I am using a wired network (which I almost always do) I try to put my settings in /etc/networking/interfaces and not in the GUI network manager. The reason for this is that it is easier to remotely change the setting (I use SSH for everything) if you ever need to change them in the future. I rarely use wireless in an embedded application for reliability reasons. If I am using wireless I will often use the GUI out of laziness, but there are ways to still use config files for wireless (which is the better way).

There you have it – my list of things I do to stabilize and prepare a fresh Linux install to work in an embedded application.

What other steps do you take? Leave it in the comments below.

Implementation of Robot Systems

After the introductory section discussing the history of robots in manufacturing we jump into a discussion of the different types of robots (articulated, SCARA, cartesian, parallel mechanisms, etc…), how they perform, and how to select the proper robot type. For performance he picks out the following four items that you need to evaluate for a given application and robot.

1. Weight carrying capacity
2. Repeatability (path and tool position)
3. Reach and Working envelope (configuration, number of axes, etc..)
4. Speed (for each axis or given path).

That list is followed by a list of how to select your robot. It is a combination of the items above and a few more things such as:

5. Mounting capabilities
6. Dimensions and weight
7. Protection and environmental considerations
8. Electrical requirements

The following two chapters are all about the common components in a manufacturing system and the applications that robots are commonly used for. So to build your robotic system you will need to start by considering:

• Handling Equipment: conveyors, ground vehicles, part feeders, bowl feeders, linear feeders, blow feeders, bandoleer feeders, and magazine feeders
• Vision Systems: For inspection and positioning
• Process Equipment: There are two types of process equipment.
  1. Equipment that handles parts
  2. Equipment that applies a process: Welding, Painting, dispensing, cutting, etc..
• Grippers and Tool Changers
• Tooling & Fixturing
• Assembly Automation Components
• System Controls
• Safety & Guarding

While I just provided a list, the book goes into detail about each of the above categories.

Now that the reader knows what they need to consider and how to evaluate a solution, we can look at typical applications. The primary applications discussed include: welding (arc, spot and laser), dispensing (painting, adhesives, and sealant), processing (cutting, grinding, deburing, and polishing), handling (casting, molding, forging, stamping, inspection, palatizing, and packing), followed by some electronics assembly. For each of these topics the concept and requirements are first discussed, followed by a section on developing a solution.

After developing the ideas required to iterate a system we are ready to develop specifications for each section. The author discusses the process starting with the concept and requirements, all the way to testing, warranties, and training.

Once your solution is in place it is important to quantify the benefits that you are receiving. The author discusses the 10 key benefits of robots as developed by the International Federation of Robotics in 2005:

1. Reduce operating cost
2. Improve product quality and consistency
3. Improve quality of work for employees
4. Increase production output
5. Increase product manufacturing flexibility
6. Reduce material waste and increase yield
7. Comply with safety rules and improve workplace health and safety
8. Reduce labor turnover and difficulty of recruiting workers
9. Reduce capital costs
10. Save space in high-value manufacturing areas

These ten areas are a good start for justifying robots as part of a business model. They can also be used to evaluate a system before purchasing.

After reading this book I found it interesting to see the different processes and methods that robots are typically used for in manufacturing. If you are looking to get into the field, then you should read this book. While I think it is great that the author walks the reader through the different tasks, and how to evaluate the robotic solutions, I often felt that the book was repetitive.

I think this book is good for researchers looking to break into manufacturing robotics, to help get a good idea of various manufacturing processes. It might also useful when writing grants to have metrics that you can discuss. For a practicing (maybe beginner) engineer, this book has good chapters on project management and how to evaluate a system pre and post installation.

I would like to thank Wiley for providing me with a hard copy of this book for review.

The post Book Review: Implementation of Robot Systems by Mike Wilson appeared first on Robots For Roboticists.

• Toughbook: The super rugged laptop teardown
• Selecting a camera and lens for your robot
• Things to think about when transporting your robot
• Developing trust in autonomous robots: Seminar with Michael Wagner

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

I have often thought about what the proper software methodology should be for the various robots that I build. My thoughts have evolved over time as I have seen these tool work. While I do not have any formal software engineering training, these are the common principles that I have seen, heard, read, etc. that I believe in (at 2am while I write this).

Disclaimer: Most of the suggestions here have come from other sources. Please check out the links attached for more information.

I will start with how to write code, since that is the basis of everything else. After that we will move into the software engineering infrastructure needed to make the software work properly.

General Programming Rules

Without having basic rules that you follow when coding, your code is doomed to fail and be unreliable. Everything else is built upon this. Many people start programming and want to use crazy template magic where everything inherits something else, however you must STOP and write simple code that is easy to understand and test.

• Keep control structures simple – Limit your branching, don’t have long nested if, case, and loop statements, no recursive magic.
• Endless loops – Do not use boundless loops unless you really want to be stuck there forever (such as the main loop). Everything else must have an upper/lower bound for exiting the loop. Think more about for loops than while loops.
• No dynamic memory – Forget that malloc exists. It can cause programs to act differently at each run time, and can also add memory leaks that can be hard to detect.
• asserts – Asserts can help you to enforce that the proper thing is helping in each function. I generally do not like the default assert functions that simply cause an exit; sometimes that is appropriate, but in many cases you should try recovering from the error instead of just exiting. You need to evaluate what is the safer approach in your application.
• Keep scope – Try to assign and initialize variables, structures, etc. in as small a scope as possible. This includes limiting your usage of global variables.
• Pointers – Limit your use of pointers when this is easily possible. You should really avoid multiple levels of pointers. They can be very confusing to follow and lead to all sorts of problems if you reference memory addresses that you should not be touching.
• Check return value from all (non void) functions – If a function can (and should be able to) return an error value, make sure to catch it and act on it. It can also be good to check the bounds of a value returned instead of blindly trusting it.
• Turn on all compiler warnings – So you catch things early. This is especially important when formatting text, working with memory, and when bit banging.
• Use parentheses to control order of operations – I have seen many people assume or forget about the proper order of operations. Using parentheses can clarify and enforce the desired result.
• Hard coded number – Please use variables for any value that might need to be changed by a programmer. If you have an even slightly non-obvious number, include a comment about the source of that number and how to derive it.
• Preprocesor – Limit the preprocessor to “simple” things, such as #define and #if. Using complex macros can lead to hard-to-understand code, poor portability, and a increased probability of bugs.
• Standards – Keep your code consistent. This includes naming, white space, and where your curly braces go. This makes it easier to follow the code. If you are editing existing code, use the format of the existing code.
• Sleep with noop’s or empty for loops – These should be avoided since they will run differently on different systems. This is primarily for embedded systems.
• Document your code – Need I say more?

Helpful links:
Rules for defensive C programming
The Power of Ten – Rules for Developing Safety Critical Code

Software Repositories

Having a code repo should be a given for every programmer and programming team. There are many free tools available, so there is no excuse to not use them.

Having a software repository lets you save your code at various points so that you can roll back to prior working versions. Repositories also let you log what was changed in each file and by whom. These tools are a great way to share code with a team – there is no need to email code back and forth. You can also put documentation in the repo so that is is always available.

There are many options to choose, from cvs, svn, mercurial, git, bitkeeper, etc. Just pick one!

Lately I have been using a hosted repo service called github.com – I like all of the tools that are packaged with git on the website. bitbucket.org is another similar option.

I generally like to create repositories with the following directories in the root directory:

• bin – A place to put all of the binaries after they are compiled. By default this directory should have nothing checked into the repository.
• config – If I have lots of config files I will put them all in this directory.
• doc – Documentation for the system (datasheets, diagrams, notes, etc..)
• externals – Source code and libraries from outside parties (ie. you did not write them)
• includes – Header files that other multiple programs want access to at compile time
• libs – A place to put all of the libraries after they are compiled. By default this directory should have nothing checked into the repository.
• src – This is where all of the code we write should live.
• tools – This is for random “tools” that do not fit anywhere else.

In addition to the directories above, I will usually put the main make file for the project and a README in the root directory.

Links:
Software repositories or just plain repo

Bug/Issue tracking

Having a central database to track bugs is very important for developing great code that runs bug free. This lets anyone who identifies a bug to report it in such a way that it does not get lost. Just telling the developer or emailing them is not sufficient. People forget things easily. Ideally, you do not want the developer to close a bug; you want somebody to report the bug, the developer to fix it, and then the original person who identified the bug verify that it was properly fixed.

A bug report needs three things:

1. What you expected to happen
2. What did happen
3. Steps to reproduce observed behavior (ie bug). Try to minimize the number of steps needed to reproduce error. Include versions of code that you are using.

Links:
Painless Bug Tracking

Automated Testing

Each of your processes/functions should have a set of tests (often called “unit tests”) performed on them to verify functionality. These tests make sure that functions work with various input extremes and combinations. Ideally you should have a test for each possible control path within a function.

For example if you are testing a “sum(number1, number2)” function, you can have the following test file:

int main () {
assert( 2 = sum(1,1));
assert( 0 = sum(-1,1));
assert( NULL = sum(1,NULL)); // or whatever you want it to be doing…
assert( 0 = sum(0,0));
assert( 1999998 = sum(999999,999999));
assert( 5 = sum(4.2,1)); // assuming integers and that floats are rounded.

RETURN (TRUE);
}

In this example assert will print an error message about where it failed and exit. (This is just my quick example, and can definitely be expanded and improved. It can also be changed to fail at compile time so that you do not need to “run” it.)

Automatic (Daily) build system

Having a build server that builds every time somebody commits code, or at minimum, every night, is valuable for identifying inadvertent bugs introduced into your system and automatically running your tests.

Often you will make a change to one module that will cause another module to fail. But as developers we get focused on our modules and tend to not try recompiling all of the code to make sure that we did not break anything. It is always better to find out you broke something earlier than later.

Certain things tend to cause other modules to break more than others. For example making a change to a widely used header file or message definition file can affect other items.

This also makes programmers only commit code that compiles to the repo and not broken code. If they commit broken code the build tools can/should send out emails to notify people that the build failed (and whose fault it was).

You can either just make a quick script to check out the repo, build it, parse the output and email the results; or you can get a proper build system such as Jenkins. Generally using somebody else’s product will be more reliable and a better use of your time.

Links:
Daily Builds Are Your Friend

Code Reviews

Code reviews are tough, but they are also one of the best ways to reduce the number of bugs in a piece of software. The traditional code review – where a person gets up and talks others in the room through the code (that the people have never seen before) – DOES NOT WORK! This might be good for getting people familiar with the program’s operation, but it is not the best way to do a code review and find problems.

To do a code review you should have the programmer send a review request to 1-3 other software engineers. The review request should have an overview of the code, a flowchart, and directions to access the code. The number of engineers and the experience level of those engineers should be based on how critical the code it. Each reviewer should:

1. Review the code (obviously) – Don’t dwell on style, you have better things to do with your time.
2. Develop a list of questions about the code
3. Write some tests and make sure they pass (these can be committed to always run in the nightly build).

Some of things reviewers should watch out for are when reviewing code before a large review:

• Does the code do what it is supposed to do (and not do what it is not supposed to do)?
• Should the code/function be written in a more efficient manner?
• Is the control flow simple/clean/good (if, else, return, etc..)?
• Do switch statements have a default catch all?
• Is the code commented adequately?
• Are variables declared at the proper scope (minimizing globals)?
• Are there memory leaks?
• What happens if things return NULL?
• Error/Exception handling
• Buffer overflows (doing raw things with char’s, int’s, etc.. memory locations)
• Pointer and pointer based math
• Array indexing
• Closing all handles (files, ports, etc..)
• Macro usage
• 64bit vs 32 bit modifications
• Multithreading (is it needed?, number of threads, race points, deadlocks, data passing, priority inversion, etc.)
• Operators (precedence and proper usage [ & vs &&, = vs == ])
• If input items from users and functions is checked before being used

(Did you notice how this list is similar to the good programming practices above?)

After doing the above steps it is now OK to hold the big meeting where people sit down and walk through and review the code; although this is not strictly necessary.

Reviewing code can be hard. Getting your programmers used to reading code and reviewing it will help strengthen their own coding. It can also be useful to have dedicated QA people who review code.

Links:
Embedded System Code Review Checklist
Microsoft: Best Practices: Code Reviews

Build System

You should be using a build tool so that you are not manually compiling each file. Probably the most common one is make.

Each make file should have at minimum the following directives:

• all – Build all of the production code
• clean – Deletes the binary and object files. This lets the next build be completely clean.
• install – Installs the binaries and libraries into the proper location. This can be a process such as:
  1. Copy old binary to <binaryName>_<archivedDateTime>
  2. Copy new binary to location with active processes
• test – Builds a set of unit/system tests that verify operation and make sure bugs were not introduced.

I believe you should be able to build, install, test, or clean your entire system with one command. As such I will normally create a make file for each process, and then create one master make file that calls all of the individual make files. Having a single make file that can build everything is good for installing a new system and makes setting up the nightly build easier.

Summary

• Write good code.
• Use a repository service (assuming it is not super sensitive data) such as github or bitbucket. That gives you the repo, the issue tracking, and the ability to easily do code reviews.
• Setup a server that builds your repository and runs your tests, at least once a day.

Do you have other favorite tools to make your software more reliable? Please leave comments below.

Main image based on sample code from wikipedia and hammer from pixabay.com/.

Tribology – the study of friction, wear, and lubrication – can help us determine the best approach.

Where do you need lubrication (lube) on a robot? The simple answer is: at any joint that moves. In practice this means near actuated joints, bearings, sliders, chains, and in gear boxes. Lube can also be used to reduce rust on metal components.

There are generally two classes of lubrication: wet, and dry (or solid).

Wet lubes stay “wet” while on the part, which is good for operating in wet/humid conditions. The down side is that dirt can stick to it.

Dry lube often goes on wet but then dries on the part it has been applied to. Soil particles do not stick to dry lube, but generally it does not last as long as a wet lube and needs to be reapplied more often. That said, dry lubes tends to stay in place a better than wet lubes. The dry lubes are generally more expensive and have lower performance. Dry lubes are usually required for space and vacuum applications to minimize out-gassing.

Another lubrication decision to make is grease vs oil. This is especially true for motor gearboxes.

Grease adheres better than oil, tends to last longer, and has the added benefit of helping to keep dirt out by acting as a sealant. That said, if a lot of particulate matter gets into the grease, it can compromise the lubricant, so using seals to “hide” the lubricant is a good idea. Grease is thicker than oil when it’s cold, and can be very hard – making it difficult to form an effective coating on the parts. It can take a lot of energy to heat up and/or spin a motor when using grease from a cold start, and running with cold grease can be equivalent to running with no lubrication or running with a solid mass in the way. The result is that a cold motor lubricated with grease can draw a higher current that will drop as the grease starts to move, heat up, and form a light coating on the parts.

Oil is often a better choice if you need to start from a cold temperature and/or want to reduce your current consumption. There is usually an optimal oil viscosity given a mechanical speed and power input, since the viscosity and lubricating effectiveness changes based on the heating effects. Oil often is used at higher speeds because it has a lower viscous drag than grease. There is a continuum of various “weights” in greases and oils across the viscosity spectrum that you can look at when choosing your lube. Oil is also good where lube needs to be circulated through something (examples are for automated lube systems or for transferring heat for thermal management).

Two plots of different standard engine oil. Showing the viscosity with temperature. (Click for larger image).

People often put too much lube on their system. Usually only a thin coat is needed on your moving parts, and any extra globs are generally a waste. Factory systems that require regular lubrication often use automated systems that apply the lube on a schedule.

The above is general information. There are many different types of oil and grease, each with different characteristics. When you really start getting into the details there are all sorts of material compatibilities, corrosion properties, organic vs. synthetic lubes, viscosities, temperatures, speeds, forces, fretting, water displacement film layers, etc.. that you must take into account. If you are too lazy to select a lubricant (and I often am), purchasing a “general purpose” grease or oil will probably give you medium performance, medium viscosity, and medium just about every other parameter.

It is important to note that lubricants can sometimes be avoided in mechanisms (I know I am contradicting what I have said above). Low friction bushing materials like teflon, nylon, rulon-J, bronze, and even steel on steel, are simple options for mechanisms with low-speed joints that can require no lubrication.

Do you know more about lube? Please leave your comments below.

I would like to thank Nick for helping me edit this and provide information to improve this article.

Swivel touchscreen top. Can swivel 180degrees in the clockwise direction. Lock button for the screen is at the base of the swivel.

The computer weighs 4lb 10.8 oz and feels as solid as a brick. The entire case and most of the internals are made from metal, which makes for a very strong laptop that feels like it can be abused. The designers were nice enough to leave the screws exposed for easy maintenance, repair, and teardowns. Gotta love it! The bottom of the laptop claims that there are dangerous voltages inside and no user-serviceable parts.

Uh Oh… We better not open this!

Using the laptop can be a bit difficult at first. The keyboard is small (9.2 x 4.2 inches) and can be hard to type with. It requires a good amount of force to type (somewhat more than a standard laptop), which I found pleasing. Also, the mouse is not the most responsive and has a small touch area (2 x 1.5 inches). The touchscreen is really nice for the era and helps to compensate for the mouse.

The display on the monitor was pretty good. It had even back-lighting and sufficient power.

The front panel has a metal lock that holds the lid shut. This is a two-part lock that will keep the lid closed nicely. On the left is a strong slide switch for power with a few soft buttons on the right for contrast, locks, etc..

The left side has a majority of the connectors. It has the power, USB, modem, ethernet, and the PC-CARD slots. Each port is covered by a rubber sealing cover, to help keep dust and water out. The stylus for the touchscreen slides into the bottom part of the screen.

The right side has both the battery and the hard drive. In order to open those slots you need to move the switch over and then down in two separate motions … really strong. All of these covers (also on other sides) are screwed down to the metal bottom frame.

Hard drive and battery removed from slots.

The battery is a Li-ion 7.4V 7.65Ah from Matsushita Electric in Japan.

Note the strap and the clip on the right to open the strap. Nice!

The back of the laptop has speaker, microphone, VGA, serial (RS-232), and a lock port. In addition, there is a strap running across the back that can be used as a carrying handle.

The bottom of the laptop has a large panel that can be removed to get into the laptop, a docking port, as well as the speaker on its own plate.

I was wondering where the RAM was hidden since I thought that it would be considered a serviceable item. I found it under the speaker. After removing the speaker mounting plate there was a 256MB DDR PC-2700 333MHz RAM (with a label that says “FOR PANASONIC”). The speaker panel is sealed with 4 screws and some sticky foam. There is what looks like a thermal gap pad between the RAM chips and the metal of the speaker mount, possibly to help thermal dissipation. At first I was surprised to see standard crappy metal clips holding the RAM modules in, but then I saw a curved piece of metal on the speaker plate that coupled with the gap pad make sure the RAM module cannot move.

RAM inside the speaker compartment.

Finally to get into the computer’s bottom I had to open 17 screws (4 of them on the speaker module). The screws all had traces of locktite on them, making it difficult to open. My fingers were really hurting after opening the first few screws. Opening the bottom plate caused the “Warranty Void” sticker in the battery compartment between the bottom and the case to come loose.

The cover is finally open.

Showing how battery and hard drive slide in.

I was not able to non-destructively open the top since I could not get the screws loose. Sorry about that. 

Doing a youtube search for toughbook torture yields some nice videos.

I hope you enjoyed the pictures. If you have any field experience with the Toughbooks or have a question, please leave comments below.

Below are some key takeaway points from the talk (with some embellishment by me), followed by a video clip of the talk itself.

Physical Safety

• One way to determine how close people can be to autonomous vehicle is to look at the speed with which you can stop the vehicle, and the distance traveled in that time. When looking at the time to stop the vehicle you need to look at human reaction time, signal latencies, and mechanical stopping time of vehicle.
• You can improve the above time by having an independent safety critical system onboard that evaluates safety at run-time and can stop vehicle faster than a human can. I really like this idea and have taken a similar (more basic) approach in the past

Testing Motivation

• IEC-61508 is a key safety standard for determining how safe a system needs to be. It provides guidance on what traits map to a given safety integrity level. However, dynamically changing parameters and AI generally make a system fall into the NOT safe categories.
• For safety critical systems we need to look at the worst case scenarios (and not the nominal or best case).
• We need to test, since some scenarios will violate assumptions that we did not even know that we made.
• “No amount of experimentation can ever prove me right; a single experiment can prove me wrong” – Albert Einstein
• Software cares about the range of the inputs and not necessarily about the duration that you run the code for. (Duration can also matter and needs to be tested for memory usage, and other unexpected parameters that will only show up after code has been running for awhile.)
• The value of a test is not the test, but how you improve the system and learn from it

Testing Approach

• Field testing is very important. Field test till errors diminish. Then simulate system for the “next million miles.”
• The question becomes how to simulate and error check the code. One method is with robustness testing, which lets the software use automated methods to find the problems, so that the developers know what to fix.
• With robustness testing you can apply random inputs to the system and see what causes it to crash or hang. This lets you simulate inputs and not just scenarios.
• You can also probabilistically modify the real world inputs that are entering your system, and verify the outputs.
• Use system requirements to generate safety rules that are checked in real-time. The great thing about safety rules is that if a rule ever fails, you know something is wrong, and the code/test/robot can stop.
• You can also add a dictionary test on your code, where you control the inputs to see what the outputs will be. You can build a dictionary over time so that as you continue testing the system you do not reintroduce old errors that you have seen already.
• Temporal logic is useful to create rules such as “get a message within x seconds”; as opposed to “a message must respond eventually”. Tests need to reflect that.

Things that commonly fail testing:

• Improper handling of floating point numbers (out-of-bounds, NaN, infinite (inf), etc.
• Array indexing
• Memory issues. Leaking, too much specified, not enough specified, buffer overflows, etc.
• Time going backwards and old/stale data (I have seen this error more times than I can remember)
• Problems handling dynamic state

And now the part you have been waiting for:

If you liked this article, you may also be interested in:

• Programming safety into self-driving cars
• Safety concerns for collaborative robots
• ShanghAI Lectures: Weidong Chen “Enhancing Autonomy and Safety of Assistive Robots”
• Quadrocopter failsafe algorithm: Recovery after propeller loss

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

IDS Imaging Development Systems – USB3 Vision industrial cameras

Choosing a camera can be confusing. It is important to determine your requirements, and then figure out how these can be achieved between the camera and the optics.

The first thing that most people talk about is resolution. The classic resolution of a camera is based on pixels (e.g.600 pixels x 400 pixels). The other type of resolution we must talk about is the spatial resolution. The spatial resolution is how close the pixels are to each other; or how many pixels-per-inch (ppi) is on the sensor. In practice it is the spatial resolution that really controls how an image will look. Sometimes the spatial resolution is measured in micrometers. When we use a lens on the camera, this effective resolution can change.

After determining the resolution requirements you should look at the focal length. The focal length you choose depends on what zoom level you need. A larger focal length (such as 200) will be zoomed in, a focal length of 30-50 is about what we see with our eyes, and a smaller focal length (such as 10) will be zoomed out and you will see a larger picture (lenses with small focal lengths are often called a wide-angle lenses). An extreme example of a small focal length is a fish-eye lens that can see around 180° (with a fairly distorted image). If the focal length is specified as a range, it is probably an adjustable zoom lens.

The next thing to look at is the Maximum Aperture or f number. The f number is often specified as f/2.8 or F2.8. The larger the number, the less light that can enter into the aperture. If you need to take images in a low light condition you will want a small f number to avoid needing external lighting of the scene. The smaller the f number, the shallower the depth of field will be. The depth of field is the part of the image that appears in focus (and sharp).

F-numbers. Each step is allows half the light as the preceding step.

Arguably this should have been mentioned first, but you will also need to look at the Field of View or FOV. The FOV is the angular measurement window that can be seen by the lens. The FOV is usually specified with two numbers, such as 60° X 90°. In this case 60° is the horizontal FOV and 90° is the vertical FOV. Sometimes instead of giving 2 numbers people will just specify 1 number based on the diagonal. FOV can be related to the focal length of the lens.

We can compute the FOV by knowing the size of the camera imaging array (ie CCD) from the datasheet and the focal length of the lens.

So for a 36 X 24mm sensor size and a focal length of 50mm, we can get the following camera FOV’s:

To calculate the image (or camera) resolution required based on a specific lens FOV to detect a certain size obstacle there is a simple equation.

So for example if your lens has a FOV of 60°x90°, the working distance from the sensor (ie where the camera hits the target) is 2meters away, and the smallest obstacle that you need to be able to detect (with a minimum of 2 pixels on it) is 0.01meters:

So we now know that when we choose a camera it must have a minimum resolution of 460 X 800 to meet the requirement of seeing a 0.01m item from 2m away.

We can also look at the working distance and how that affects other camera/lens parameters.

In many cases the focal length and the sensor size are fixed. So we can then look at how changing the viewing area or changing the working distance affects each other. On other cameras the focal length is adjustable and we can also look at how changing that affects the other parameters.

Note the vignetting at the corners of the image.

With all lenses, and particularly with cheaper (<$150) lenses, distortion and vignetting can be a big problem. Common distortion modes are where the X or Y axis appears to no longer be straight and perpendicular with each other (rectilinear). Often you will see an image look wavy or bulging. With vignetting the edges and particularly the corners become darkened. You can often reverse the effects of warping by using a homography for image rectification.

With any lens and camera system you need to check the mount types. There are many different styles for mounting a lens to a camera. Wikipedia has a long list of mounts that can be found here. The most common mount that I have seen for computer vision cameras (ie. no viewfinder and designed for machine vision applications) is the C mount. Choose a lens that you can lock into place. Not only should you be able to lock the lens into place you should be able to lock any rotating knobs into place (such as for zoom and focus). This is usually accomplished with set screws. I am not that familiar with them but I will note that there are many different filters that can be attached to your lens for things such as polarization and blocking certain parts of the spectrum (such as IR). Your iPhone camera typically has a built in IR filter in the lens to remove IR components from your images.

Another semi-obvious thing to look into is whether you need a black and white (often expressed as B&W, BW, or B/W) or color camera. In many cases B/W cameras will be easier for your algorithms to process. However having color can give you more channels for humans to look at and for algorithms to learn from. In addition to black and white, there are hyper spectral cameras that let you see various frequency bands. Some of the common spectral ranges that you might want are ultra-violet (UV), near-infrared (NIR), visible near-infrared (VisNIR), and infrared (IR). You will also want to pay attention to the Dynamic Range of the camera. The larger the dynamic range, the greater the light difference that can be handled within an image. If the robot is operating outdoors in sun and shade you might want to consider a high dynamic range (HDR) camera.

You will also want to consider the interface you have to the camera – both the electrical and software interface. On the electrical side, the common camera protocols are camera-link, USB2.0, USB3, firewire (IEEE1394), and gigabit ethernet (GigE). GigE cameras are nice since they just plug into an ethernet port making wiring easy. Many of them can use power-over-ethernet (PoE) so the power goes over the ethernet cable and you only have one cable to run. The downside of GigE is the latency and non deterministic nature of ethernet. The other interfaces might be better if latency is a problem. Also, you generally can only send full video over GigE with a wired connection, and not from a wireless connection. This is because you need to set the ethernet port to use jumbo packets, which can not be done on a standard wireless connection. Probably the most common reason I see GigE cameras not working properly is that the ethernet port on the computer is not configured for jumbo packets. For software, you want to make sure that your camera has an SDK that will be easy for you to use. If you are using ROS or OpenCV, you will want to verify that the drivers are good. You will also want to check what format the image is supplied back to you from the camera: will it be a raw image format? or will it be a file format such as png of jpg?

If you are doing stereo vision, you want to make sure the cameras have a triggering method, so that when you issue an image capture command you get images from both cameras simultaneously. The triggering can be in software or hardware, but hardware is typically better and faster. If you are having problems with your stereo algorithm this can be the source of the problem, especially if you are moving fast.

Finally, if you are looking for video, you also need to look out for the Frame Rate typically specified in Frames per Second (fps). This refers to how many images the camera can take in a second. We can then call that sequence of images a video.

Hope this helps. If you have camera experiences you would like to share – especially related to good/bad SDKs and what works/doesn’t-work with ROS – please share in the comments below.

While writing this post I saw Wikipedia said “MV is related to, though distinct from, computer vision.” This surprised me as I always viewed machine vision and computer vision to be similar fields, just different terms used in different industries. So I followed the references and found an interesting article from Bruce Batchelor here. After reading his article I am still not sure if I agree. I think there are people who are theorists that only care about the vision aspects, there are integrator’s who only care about the system and don’t know much about the vision aspects. However there is also a large segment in the middle, such as roboticists, that care about both sides of the problem. Working in robotics you need to care about the real world applications while also understanding the vision problems and develop new vision methods and techniques.

As roboticists are we doing both? are we only doing computer vision? only machine vision? What do you think? Leave your comments below.

For optics and some good technical notes you can visit Edmund Optics. They have a large supply of everything optics related.

Sources:

• http://www.gizmag.com/camera-lens-buying-guide/29141/
• http://vitaleartconservation.com/PDF/affects_of_lens_quality_on_image_resolution_v3a_draft.pdf
• http://www.gizmag.com/camera-lens-buying-guide/29141/
• http://digital.ni.com/public.nsf/allkb/1948AE3264ECF42E86257D00007305D5
• http://www.nikonusa.com/en/Learn-And-Explore/Article/g3cu6o2o/understanding-focal-length.html#!
• http://en.wikipedia.org/wiki/Angle_of_view

If you liked this article, you may also be interested in:

• Things to think about when transporting your robot
• Controlling a brushless DC motor with no encoders
• UMich team works on perception and localization using cameras
• Multi-viewpoint robotic camera system creates real ‘bullet time’ slow motion replays

See all the latest robotics news on Robohub, or sign up for our weekly newsletter.

Source: Wikipedia.

Throughout my career I have had to ship various robots to different locations around the world. Here is a little bit about what I have learned about transporting robots.

The three basic ways for a robot to travel are by land, by air, and by sea.

Typically, shipping over land is the easiest option. You can find a trucking company (or train, though I have never used one) that will transport your robot. When you get a truck you can sometimes get a partial truck where you are given a certain volume to use, or you can get a full truck where the entire truck is dedicated to your payload. The nice thing with a truck is you provide them with a time, date, and location, and the driver will bring your stuff to you. Ground transportation generally is the least restrictive. You will need to follow Department of Transportation (DOT) restrictions (and other rules) for things such as max width and height of your load.

Transporting by air is good when you need to get something somewhere fast. This is especially true when you need to cross oceans. The downside is that this is also an expensive way to travel. Putting a large robot with support equipment on a plane can be pricey. You are also limited in what you can put on the plane … an airline might refuse to ship a gas/petrol powered robot or lithium batteries, for example.

Shipping by sea is a nice way to transport your robot across oceans (or long distances around a coast) if you have lots of time on your hands … Sending a shipping container (which is easy to pack, almost like a truck) from the North America to South America by boat can take an easy month. A big benefit is that you can ship lithium batteries across oceans this way. And shipping by sea is often cheaper than doing so by land or by air.

Often you will need multiple shipping companies. For example, you might have: a local truck to the port, the ship/boat company, a truck from the destination port to a large city, and then another smaller truck to your location. There are shipping agents that can help you arrange all of that. Also, for smaller robots (where small is relative) don’t forget about UPS and FedEx to ship your freight. You can look in your local yellow pages or on Google to find shipping companies and shipping agents near you.

Types of Trucks

When you are planning to ship by truck, you will need to consider the different types of trucks to choose from. Within each of these types there are also different lengths of trucks that you can request. You should be aware that truck drivers will usually want to inspect the loads to make sure they are secure. With many types of trucks, the truck driver will be the one that secures the load, and not you. When you have a truck come to your loading area, you should find out in advance how long it is to make sure the truck will be able to drive in and out of your area.

Pickup + Trailer – This is just a standard pickup truck that you can also get a trailer to tow behind it. This is the smallest and simplest type of truck mentioned here.

Tow Truck – These are the standard trucks that haul cars. It is easy and inexpensive to get a local tow truck and driver to help you move a robot. You will usually want to request a tow truck with a flat-bed and not one that drags a car behind it. Keep in mind that the driver from the tow company will be the one operating/driving the truck, and that the truck will usually have an open top, so your cargo will not be protected from the elements.

Box truck. Source: Wikipedia

Panel Truck or Box Truck – This is another easy to get truck. You have probably seen large versions of these trucks on the highway, or smaller versions in the city; they have a metal box in the back for transporting goods.

The small and medium sized versions of these trucks are easy to rent and you can drive them your self (as opposed to getting a truck with a driver). This is the type of truck I use most because I can rent and use them on my own schedule.

Flatbed truck. Source: Wikipedia

Flat Bed – A flat-bed is a truck has a flat platform instead of a box. These are good for carrying large loads and being able to get a forklift in from all sides. The downside is that your robot is not protected from the elements and is exposed (but of course you can use a tarp).

Low Boy truck. Source: Wikipedia

Low Boy – The carrying surface of a Low Boy truck is close to the ground, and it offers better clearance when transporting tall/large payloads. Low Boys can come apart in various ways that allow you to drive a robot onto them.

Tip

When doing a roundtrip shipment, a truck driver might hang around town waiting for you, and may try to get a few local hauls while waiting. It can often be helpful to pay the driver a little extra for them to help you in the field, even with non-trucking tasks. Many of the truckers I have met are good at solving field logistic issues and improvising to fix mechanical items. We have even asked truck drivers to help record video!

Crates

A good crate can make all the difference when shipping items. You generally want a crate that is elevated by multiple blocks so that it can be lifted by a pallet jack (or fork lift) from any of its sides. A common mistake people make is to build a crate with just a few slats that only allow forks to enter from one side.

When you build your crate, you will want to use stamped wood that is certified to be pest free so that countries will allow your wood/crate across their borders. There are many places (such as Hawaii’s Dept. of Agriculture) that will insist on inspecting the crate for foreign infestations.

You will also want to think about how to seal the crate. For this, there are various methods ranging from screws to latches, clips and climps. Ask yourself if you will have access to tools at your destination, or if will they all be in the crate that you need to open. Using climps or latches can be an easy way to secure a crate shut; these can be bought online from packaging and shipping suppliers.

There are professional crate makers that can do a beautiful job building crates. They often build crates for companies that ship to exhibits, and can help walk you through exactly what you need and make a crate that fits your robot perfectly. They will also have different supplies you can purchase, such as stamped wood for international shipping, foam sheets, various ways to seal the crate, and ways to secure your load in the crates.

Once your robot is in its crate, you will want to tie it down so that it is secure. I will often use wheel chocks or 2×4 lumber to help hold a robot’s wheels in place, and then use some screw-in eye bolts to help tie the rest of the robot down. Heavy items like batteries can often be removed from the robot and secured to the base of the crate. This will help prevent a heavy battery from coming loose inside your robot.

You may also want to label all sides of your crate “FRAGILE” and note the direction that the crate should face (“THIS SIDE UP”).

Batteries in the Air

If you plan on shipping batteries by air (especially lithium-ion) you need to plan in advance, because airlines are concerned about batteries exploding and catching on fire mid-flight.

If you built your own battery pack, then you have little chance of getting it approved to fly. It is possible to get prototype batteries certified to fly, but it is not easy or fun. If each cell or individual battery is certified to fly you might be able to take your pack apart and then ship it. If you have batteries that are safe to fly, you should attach documentation directly to the battery pack so that anyone inspecting has proof of their safety.

International Shipping

Shipping your robot internationally can be complicated. You may want to work with a shipping agent that has experience in international shipping. You will need to generate your manifest weeks or months in advance so that it can be approved – this will minimize problems with customs and shipping. Taxes and regulations vary from country to country.

There is something called a carnet that allows you to declare that the items you are bringing into a country will be taken back out with you when you leave. A carnet can help you to get through customs and avoid paying taxes. The downside is that it costs money to prepare the carnet. They are also not foolproof: once I tried to use a carnet to get my robot through customs at the airport and none of the officials there knew what it was … it took lots of people lots of time to figure it out.

If you want to avoid packing your robot, you should build flying robots! Just don’t let the FAA find out! (Note: For everyone who did not figure it out my bad attempt at humor. I do not endorse tricking the FAA.)

This is just a quick post on controlling DC brushless motors with no encoders. This post applies to brushless motors that typically use hall sensors for commutation. This post does not apply to the hall-less ESC (electronic speed control) motors that typically run at very high speeds and are used for things such as quadcopters and boats.

To go back to basics, brushless motors have three phases (typically) that need to be commutated. The motor controller typically knows how to commutate the motor by having a hall effect sensor on each of the three phases. The problem is, when starting from a stop (no motion) or when operating at “slow” speeds, the controller does not have all of the information it needs to optimally commutate the motor. To get that added information the controller wants to use an encoder for the higher resolution. Using the encoder, the motor controller can now know exactly where the motor is for better control. This means a few things:

• The motor can spin a little and figure out how to commutate without waiting for the 3 hall effect sensors to change. This improves the starting of motion.
• The controller can know the precise position so that it can servo on a position and not jerk/move as it tries to hold a position.
• You can now do position control.
• The commutation and torque/speed profiles are more efficient since the controller has position feedback and can do sinusoidal commutation instead of the more basic trapezoidal commutation.

So you are now in a position where you have just the halls and no encoder. What can you do about it:

1. Only operate at high speeds so that the hall sensors are sufficient for speed control (you might still have a high variability in your speed based on applied load).
2. You will need to tune the PID (or PI or PD) filter more than normally. The PID constants will often need to be much higher (I have seen 1000 times higher) to compensate for disturbances in the motor. You will probably also need the higher gains to help the motor start to spin.
3. This is a bit of a hack but on most hall sensors (assuming it can source enough current) you can tie two of the halls to the quadrature encoder inputs on the motor controller to get a rough uneven position control. That can also respond to changing loads.
4. Instead of issuing a “servo here” command to hold a position, you will probably need to disable motion (cut off power to motor). If you are in an application where backdriving a motor is fine or where your gearing provides sufficient holding torque this could be ok.

When you are purchasing your motor controller you should check if it can support hall based feedback only. Some controllers do better than others at handling the lack of encoder feedback.

www.franksworkshop.com.au/Electronics/Photoplotter/Photoplotter.htm

We would like to welcome our newest Robohub contributor, David Kohanbash, whose blog – Robots for Roboticists – covers a broad range of technical topics that is sure to interest makers and practitioners. We hope you enjoy!

Incremental encoders are good for speed control and can be used for position control when we have a homing routine to get absolute position, or the system is constrained to less than one rotation. One way an incremental encoder can also be an absolute encoder is if it is single turn. Usually an encoder on the back-shaft of a motor will be multi-turn, however if you have the encoder on the output shaft (or if it is a secondary position encoder) it can be single-turn.

Throughout this post I am focusing on digital/analog optical quadrature encoders. While there are other types of incremental encoders (with all sorts of fancy output options) these are probably the most common. These come as a standard option for many motors as well as in kits that you can snap onto a motor.

Quadrature encoders have at minimum 4 wires:
– Power (often +5V)
– Ground
– A+
– B+

A+ and B+ are the signal lines that generate the pulses that we use for determining position. There are several other signal lines that are often seen with encoders:
– I+ (or sometimes Z+)
– I- (or sometimes Z-)
– A-
– B-

I+ is known as the index pulse. For every full rotation of the encoder shaft there is one index pulse to help give an absolute reference in the rotation. This is often useful when homing a motor you can look for the index pulse.

The A-, B-, and I- are the inverse of the + versions of those signals. This is useful when operating in a high noise environment or where signal integrity is an issue.

If signal integrity is a concern (or an active issue) you can add a line driver to improve the signal.

In design reviews and in practice I often see people purchasing the highest resolution encoder that they can get. Often the cost of the encoder wheel does not change much based on the resolution.

Incremental quadrature encoders typically range from 100-1000 counts/rotation, however you can find encoders with many thousands of counts/rotation. Since they are quadrature and there are 4 state changes per each set of A & B phases, the resolution is 4 times the counts/turn.

In theory if you need 1degree of resolution per rotation, you need an encoder with 360 counts. Using a quadrature encoder this can be reduced to only 90 counts in the encoder wheel! If you have gearing on the motor this can be further improved to limit the number of encoder ticks required.

When you pick an encoder it can be tempting to select the highest resolution available, but you should stop and think first. Some controllers will have a hard time tracking position if the motor is spinning fast and there are too many encoder ticks per unit time. On the flip side if you have a slow-moving motor you might need the high-resolution so that you can see the change in motor position during a given time step in your controller.

Some other things that you need to consider are operating conditions and mounting. Operating conditions is fairly straight forward; can the encoder survive the temperature, vibration, shock, water, etc.. that it will need to endure. Mounting can be a bit more interesting. There are all sorts of options for encoder mounts. Some of the mounting options are hollow shafts, solid shafts, recessed shafts, collars, etc.. Often when ordering a motor if you can get one with a backshaft that will be the easiest way to connect the encoder (assuming you dont have the manufacturer adding it for you). If you are using a brake on the motor, the brake might need to connect to the backshaft, and you will need to be creative or get a pass-through on the brake to add the encoder.

In closing when selecting an encoder you should check the following:
1. Is an incremental (ie non-absolute) encoder good for this application?
2. Does your controller interface to the output format of the encoder?
3. What resolution is needed?
4. What environment will the encoder be operated in?
5. Mechanical fit & mounting.
6. How the electrical noise is (so you can get the differential channels)?
7. How long should the cable be (assuming it is attached and not just a connector)?

A final piece of advice is to use shielded cables for your encoder signals. This is especially important for long cable runs (where you might need a driver) and noisy environments.