Hello! It's been a while since I've blogged about my engineering experience, but that's because I've been too busy working to reflect on it. For anyone who talks with me regularly, or reads this blog often, you'll know about this one particular project that I've been working on and just finished.
Ladies and gentlemen, the Pathtracker!
As can be seen above, the mobile unit is a simple
plastic enclosure which houses the GPS, IMU, battery, and laptop computer. The
dimensions of the enclosure are quite large, 65cm by 54cm by 15 cm, but this
was mostly to easily facilitate a student project, and account for the GPS, as
it is 60cm long. You might be wondering why the GPS is so large, as the one in
your car is much smaller, and the one in your phone is smaller still. Well,
first off, our GPS has two antennas, one at each end. Secondly, ours is more
accurate than yours. While your phone's GPS has an accuracy of anywhere between
5-50 metres, (and that can be generous), our GPS has an accuracy of less than a
metre. Additionally, the reason it's so long is because our GPS takes very
accurate heading (directional) measurements, and the length between antennas is
vital to giving an accurate heading (less than 0.3° off).
Okay, so how does the Pathtracker work? Well, if
you haven't already seen it, please watch this little video.
We presented that at both the Preliminary Design Review and the Final Demonstration. It was made with the help of my very skilled and excellent friend, Marco Barrettara and does a great job of showing you what our concept is.
We presented that at both the Preliminary Design Review and the Final Demonstration. It was made with the help of my very skilled and excellent friend, Marco Barrettara and does a great job of showing you what our concept is.
Basically, the GPS and IMU, encased in the
enclosure, are powered up, and start transmitting their information to the
laptop. While the GPS tracks the latitude and longitudinal position of the
enclosure, the IMU tracks the motion between GPS readings, adding its motion
and rotation to that of the GPS. Now, while the IMU is very sensitive, it is
susceptible to drift. Basically, over time, the IMU's information becomes
unreliable as any errors in the readings accumulate over time as more readings
come in. That is where the GPS comes in. The readings from the GPS are used to
reset the IMU's information over time.
The images below should help illustrate my point.
The type of filtering, known as Kalman filtering, basically takes information at specific time steps and tries to find an average of the readings. Without filtering, as seen on the left, the black circles represent the GPS positions, whereas the blue path represents the path the IMU is reading. See how they don't line up? Well, ideally they would, but the IMU drifts over time, as mentioned. Now, the computer filters the information, using the GPS as reliable positions, and ideally the path on the right would be outputted.
So, if the GPS is used for reliable positioning,
why are we using the IMU? Well, there are several reasons for that. The first
is that we might not always have a GPS signal. Sometimes, due to trees,
buildings or some other obstruction, one can lose a GPS signal. In that case,
the IMU is used to fill in the gap, provided that segment of time is short. A
second reason is that the IMU refreshes faster than a GPS, allowing for better
positioning for an object moving at high speed and changing directions. A third
reason is that we are working toward eliminating the GPS from the system
entirely. While extremely accurate, the GPS is dependent on getting a signal,
and this requires us to be outside. The concept of interior navigation, while
not new, is novel enough to be a field of interest in navigation, and that is
what we are working toward.
So, after some research into this problem, and
discussing it with our professor, our team ordered some hardware. The GPS is a
Hemisphere V100, with two antennas and a high accuracy, mentioned earlier. The
IMU is from Analog Devices, ADIS16360, and worked very well for this project.
Contrary to most pieces of hardware nowadays which
are simply plug and play, our hardware required a bit more work and research.
None of the members of my team knew anything about working with this hardware,
so getting it to work was a considerable challenge. The GPS wasn't too bad, as
our professor's graduate student had a similar one, and it involves a serial to
USB cable. The IMU, however, took a bit more research.
Having a mass of 30 grams, and only a couple of cm long and
wide, the IMU, at first, appears to be a simple device. The IMU came with an
evaluation board, as seen on the upper left, and this helped interface the IMU
with the computer. The information from the IMU corresponded to one set of the
12 pins on the evaluation board. After conferring with my professor, and some
more research, I decided to use an Arduino Uno microcontroller to interface the
IMU with the computer.
Cheap, simple, and with a variety of functionality,
Arduino microcontrollers are a big hit in the world of electronics.
Additionally, the language used to program them is very similar to C++, a
common programming language, and is available for free at the Arduino website.
The Arduino's purpose was to program the IMU, in
order to access the information I needed, namely the accelerations and
rotations in the x, y, and z directions. After referencing the IMU datasheet, I
connected wires from the IMU evaluation board to the digital input/output pins,
seen as the black holes on the top and bottom right of the above picture. Once
there, I needed to connect the Arduino Uno to my computer, and for that, I used
a serial to USB cable.
The serial to USB cable is one which you all might
have in your house; it's the cable which connects a modern laptop with your
computer. Once I figured out what I needed, I just pulled the one out of my
printer and went to school, feeling like MacGuiver.
The next stage took quite a long time and I'm not
going to get into the really technical stuff because it might bore you, but
basically, I had to program the Arduino to send commands to the IMU, so that
the IMU would sent the information I needed to the computer. It took quite a
bit of work, but I really learned a lot about hardware, the Arduino software,
and had to brush up on my digital logic. Once that was complete, I had to
confer with one of my colleagues who was working with the Kalman filtering code.
Thankfully, most of the code was written and
provided to us by our professor's graduate student. The reason I say thankfully
is because while I learned about the inner workings of the code from both this
project and my robotics class, it would have taken us way too long to complete
and would have been an entire project unto itself. Even though it's the most
important piece of software, we still had to make changes to suit our purposes
and we went beyond it, hoping to update our data in real-time onto Google Maps.
So, my colleague spent most of her time, when she wasn't managing the project
and documentation, working with the Kalman filtering software.
My other colleague spent most of his time working
with Google Maps. Once I had the hardware working, and my first colleague had
the filtering software working properly, this colleague had to collect it,
organize it, and upload it to Google Maps, in real-time. When I say real-time,
I mean to say that the information had to be sent and plotted onto Google Maps,
as it was being collected. If you'd like to see some of our testing information, check out this link: Pathtracker. It's still a work in progress, but it will show you some of our testing data as it was registered by our hardware and uploaded to the website.
Some of this sounds easy, but it's not as easy as
you'd think, especially once you get into it. As I mentioned, none of us had
any experience in this beyond the theoretical, so it was really nice gaining
this experience. Sure, it caused us to be really stressed and worried about the
project, but we learned a lot and it came together toward the end.
The only thing I am upset about was the final
presentation. There were 4 teams in the class, and at the end of the year, we had
a presentation of our projects and the top 3 teams earned a cash prize.
Surprisingly, our team earned 4th place. This actually shocked me quite a bit.
While I am not going to say that our project was that super amazing, I didn't
think we deserved last considering the complexity of our project and how much
we accomplished.
It wasn't our presentation skills. My team did very
well, and with the video from above and some other visuals, we had a very nice
looking, and comprehensive presentation. Additionally, I love presentations and
fielded questions very well, if I may be allowed to say so myself. But, I think
the other projects had pizazz, had more interactivity, which made the judges
more inclined to vote for them. They said it was a close competition, but I am
still a little disappointed.
But, as I said, a lot was learned, and I very proud
of the project as a whole. Our team learned a lot, still remained if not
friends, than at least stayed on good terms, and the project was completed. I
await the final grade, but I expect it to be a good one.
For more information, please consult either the BDN
Pathtracker website, Pathtracker, or the school website which will host this
information for years to come, ENG4000. (Please excuse the simple nature of our website.
It was made very much toward the end of the course and was only used as a
repository for the information at hand, and the aesthetics were not so
important).
I am glad to be done. Both this blog post, and the
project itself. It has been a long term and I am looking forward to the summer.
Stay tuned as I have one more big project to post about.
After that, my posts will take on a bit more of a personal,
adventurous nature, so I hope you enjoy that!
-Thanks for reading!
No comments:
Post a Comment