My name is David Kohanbash and I am a Robotics Engineer. I love building, playing and working with Robots. I specialize in electronics and low level software. I get to play with lots of embedded computers, networking gear, sensors, motors, RF hardware, electronic design, and low level software. I also like mechanical stuff (sometimes). I have had the opportunity to work on robots for planetary exploration, farming, mining, lakes, manufacturing, and self driving cars. I have been building robots professionally since 2006 (and even longer unprofessionally). My focus is on professional robotics (as opposed to hobbyist robotics, which I also love). My blog is at robotsforroboticists.com, please check it out and say hi!
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.
Hydraulics are sometimes looked at as an alternative to electric motors.
I had somebody ask me questions this week about underwater photography and videography with robots (well, now it is a few weeks ago…). I am not an expert at underwater robotics, however as a SCUBA diver I have some experience that can be applicable towards robotics.
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.
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).
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.
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.
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
[divide]
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.
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.
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.
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.
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.
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.
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 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.
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.
| Device | Frequency | Wavelength | 1/4 Wavelength |
|---|---|---|---|
| WiFi 802.11 | 5.8GHz | 5.17cm | 1.29cm |
| WiFi 802.11 | 2.4GHz | 12.49cm | 3.12cm |
| GPS* | 1.227GHz | 24.43cm | 6.11cm |
| Radios | 900MHz | 33.3cm | 8.33cm |
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…
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.