As discussed previously, we've got a hardware base selected. This didn't occur completely separate to the software selection, but for the sake of clarity, I wanted to discuss them in unique posts. So here's a quick overview on how we selected our software stack.
The intention of this system is to find obstacles in the path of the RC car, and plan a traversal process for each wheel. The main input sensor is the Kinect, from which we receive a stream of RGBA-D images at 30 Hz. This stream of images will need to be analyzed to determine the road surface that the vehicle is driving on, and any protruding obstacles that are significant enough to require the suspension to act. In order to do this, the depth image needs to be represented as a point cloud, where each 'pixel' is translated to a 'voxel' with an (X Y Z) coordinate. In the format of a point cloud (pc), many operations can be run on the data to help facilitate the extraction of useful outputs. This will be discussed more in-depth later on, as the Point Cloud Library operations have a lot of complexities of their own. For now, we'll maintain a high-level view of the PCL operations. The pc will get passed through some basic filters and then we will run a planar segmentation algorithm to extract the primary and secondary planes. After that, we will perform Euclidean cluster extraction to obtain the most distinctive form of the surface obstacles.
The point cloud will then be reduced to the useful data- where the road is, where any obstacles reside, how the obstacles are shaped, and what the relative velocity is. The velocity is relative because in this context it doesn't matter if the vehicle approaching the obstacles, or if the vehicle is stationary and the obstacles are approaching, which is the assumption we're basing our model on. With this data, we want to plan the traversal. In order to do this, the first question is which wheels are going to hit the obstacle. This will be answered using the relative path of the obstacle towards either of the two wheels (for now, we're restricting motion to a straight line so that we can treat the forward and rear wheels as a linear vector). Once this is established, we need to know the vertical height of the object, which should be easy to obtain from the geometric form of the point cloud. Then we need to know when exactly the wheels will impact the obstacle, which is simply a matter of velocity. The exact method of finding and maintaining a velocity measurement is a flexible matter, but we are hoping to use the persistence of the point cloud geometry to interpolate a velocity straight from the image stream. Basically, analyzing how the obstacle approaches the vehicle every 30th of a second.
Finally, we have the bulk of our input analyzed, and we know which wheels have to move, how far they must be raised, and how soon it must occur. The last step is simply translating that into a meaningful control output for the actuators, and transmitting it. This will be done through ROS nodelets which simplify the process of continuously pulling in data, analyzing it, and pushing an output. There will be a fair amount of optimization work to ensure that this can all run at 30 Hz (or, more realistically, 10-15 Hz) but that summarizes the general concept of our software!
In the future, we'll discuss the nitty gritty details of the PCL components, the ROS node optimization and how we will tune the control algorithm to prioritize chassis smoothness for different obstacle cases.
Ciao,
-Danny