COVID-19 GPS/IMU Alternative

As concluded in my previous post, the Piksi Multi Receiver Kit was our most favourable solution to the problem of Vehicle State Estimation (VSE) and the gathering of position, heading, and velocity data. However, due to the effects of the Australian lockdown, there has been a degree of flexibility required with our plans. In terms of this subsystem, acquisition of the Piksi Multi has been put on hold indefinitely until the university reopens, as has the purchasing of any other devices that are not currently in our possession. Due to this, I have been exploring the avenue of using what I have available in terms of a GPS/IMU module for my initial programming of the data processing and testing required. When the Arduino and GPS module mentioned in my last post failed me, I looked to one of the most common computer devices in the world: the smartphone.

Android VSE

This project has relied upon the framework and phone application presented in the ROS android_sensors_driver package (Thanks to Jack McRobbie for originally suggesting it!) and my current github repository for this project can be found here and is still very much in its early development stages. ROS is still very new to me, but it has been rewarding to learn.

Initial Steps

Following the android_sensors_driver Connecting to ROS Master tutorial, the first steps were familiarising myself with roscore and and rostopic system, as well as configuring the phone app to communicate on the same IP address and port as my Linux Virtual Machine was using for roscore.

Starting roscore

Once this was successfully set up, I was able to see which sensors I had access to from the app. Please note that “fix” refers to the GPS.

rostopics available from the app

Furthermore, I could use rostopic echo <topic> to see what sort of data was available to me. rostopic info <topic> was also useful in determining the format of the message used and the data types of each variable.

The three topics I was interested in are shown below:

GPS Topic /android/fix

IMU Topic /android/imu

Magnetometer Topic /android/magnetometer

Basic Publisher/Subscriber Framework

Once satisfied I had familiarised myself with the idea of rostopics sufficiently, I began to research Publisher and Subscribers and how to implement a basic subscriber in rospy that I could use to subscribe to the topics of the sensors I required. My plan was to eventually create a program that would subscribe to the sensors I required, process the data to compute position, heading and velocity, and write it to a message that would be published for the SLAM implementation and Autonomous Control systems to access. For now, I wanted to start small and create a subscriber that would log the latitude readings from the GPS. The final implementation can be found in the NavSatBranch of the avse repository.

Successfully Subscribed to GPS through /android/fix

RQT Graph

Expanding to Include IMU and Magnetometer

The next challenge was to expand the original code to also accommodate the IMU and Magnetometer topics. This section is very much still a work in progress, but I have tried two separate avenues so far:

• Using the message_filters library to synchronise the data
• Using a server to create three separate subscribers that operate independently The server implementation is further along at this stage, and is currently my prefered option as it allows more redundancy in the readings. It also means that the system is not operating at its slowest update rate, and can estimate its current state via the IMU in between the GPS updates. The message_filters option will allow the implementation of sensor fusion, but is the slower option as the updates can only be as fast as the GPS updates. However, despite this, both are equally viable options and I will be developing both further as well as researching other alternatives.

Computing Position, Velocity, and Heading

The server implementation also has the beginnings of the calculations required to compute position, velocity, and heading data. However, this is currently incomplete and requires more research. Ideally, the system will be able to calculate this data from a variety of sources to increase the accuracy. As aforementioned, whether this is simply done by combining the data together or through relying on the fastest updating source and applying corrections from the other sensors, I have yet to finalise.

Accuracy Testing

Since falling back on using an android phone as our sensor suite for the meantime, the question has come up in regards to the accuracy of this device. The application of an autonomous vehicle requires reliable sensors that can either produce data to a high accuracy, or the data can be processed in a way to achieve this. Due to this, I have organised a series of tests. The first was to leave the device in a stationary location in clear view of the sky from a wide angle and record the GPS latitude and longitude readings over the period of an hour. Despite being stationary, the GPS still recorded fluctuations in its position, up to a maximum absolute value of 0.000030 from the mean in the latitude measurements, and 0.000036 in the longitude measurements.

Reading	Mean	Fluctuation	Fluctuation (meters)
Latitude	-38.23833949	0.00003017631	3.353764465
Longitude	145.0560592	0.00003561111	3.957783032

Stationary GPS Data

As our application depends heavily on relative position, I was unsure of how this would affect the accuracy of the data. If the measurements were fluctuating that much randomly, the data would be near unusable. I then charted the latitude and longitude data by order of occurrence, and determined that there was a pattern to the change in readings, most likely due to the movement of the satellites. This effect will need to be further researched.

Stationary GPS Data, Latitude in order of occurrence

Stationary GPS Data, Longitude in order of occurrence

My next avenue of GPS accuracy testing will be in terms of relative accuracy. This will likely involve taking the readings between two points with a known distance between them with a small time period. Other options also involve creating known paths, traversing along them, and recording the data to see how it would perform in conditions similar to low speed track conditions. As the COVID-19 situation does not seem to be lessening anytime soon, I believe it is important to ensure this avenue of research and testing is up to the task of handling the vehicle state estimation of an autonomous vehicle.