Back to that theme. Something about using SQLite for object storage in the 2 dimensional world of the traveling autobot. The autobot receives location ID based messages from everywhere, the cameras, other cars, the traffic lights talk to it. So the autobot needs to draw on matches with these objects, matches by location, within location intervals, and objects placed there by on board sensors, as well as object messages coming from near by street lights.
Other matches are by parameter, or shape, so the database is built in with extra match functions, some using digital signal processing. So the tables also contain precompiled images for pattern matching. Objects have class, and these classes are known apriori.
All making for a good match with SQLite.
The vision sensors in these bots return many object styles, lane markers, curb sightings, other vehicles shapes, and people like shapes. The vision systems return these object at various levels of decomposition and identification. They are mainly information preserving in cases where objects are better matched against a known data base. It is more dangerous than identification on its own data. So, SQLite search and match functions, enhanced with DSP offers a universal base against which developers can develop the protocols for object identification.
So, standards developers can combine their efforts, defining a location based link layer, motion and class message components, table based storage customs, and ready to use autobot code.
No comments:
Post a Comment