Week 6!

This week was quite a doozy. Both the grad student I work with and my PI were out all week. Naturally, I figured it was a good week to really sink my teeth into fixing the copy cat code. The first order of business was figuring out what header files and code blocks were astec specific (the older quadcopter platform) so that I could remove them. Mike helped me get access to some old astec files in case there was something helpful in there (unfortunately there wasn’t). Given that I have never worked with the astec platform, I got a little help from Siya who helped confirm that I correctly identified the header files were astec specific and pointed out a few methods in the code were that were related to the astec. Once that was out of the way, I was off bug hunting. I wanted to get catkin_make to compile before I started retrofitting the file. After several hours of trying to artfully edit the file to get it to compile, I decided it would be better for me to try the time tested “slash-and-burn” tactic. As a result, I effectively lobotomized the file. It was immensely satisfying and totally worth it because I got the catkin_make to compile. 

My next large problem was that ROS had a meltdown every time I tried to run the launch file. I had the distressing realization that I had literally no idea how this package was working as I could not find the main function/the main function analog. So I did some detective work trying to figure out why there was no main function nor any obvious file that had a main in it. After doing my best Sherlock Holmes impression, I found that main is a 7 line long python script that wasn’t in the CMake file. From there, I deduced that python files of this nature need to have execution permission for ROS to use it correctly. This was a simple fix, just a quick cmhod +x and the launch file worked! 

Elementary my dear Watson!

Quick bonus tip for y’all. If you’re not sure of your file has execution permissions, simply type ls -la in your Unix shell and see if the file has x permission in the list (looks like rwxrwxrwx if it does and rx-rw-r– if it doesn’t).

AJay, the author of the LQR controller that I am trying to integrate with this code retrofit, came back from a conference and helped me immensely. (To be clear, both Mike and Siya’s help were invaluable–thank you both!)  With his guidance, I got a crisp image of the shape of the problem that stood before me and some tools to help surmount the challenge. A short coding montage later, I retrofitted the code to (hopefully) work for the flamewheel. All that was left was to do was run the code. And here, dear reader, we come to my largest time sink of the week:


Fig A: The Source Of My Pain

The FPV Radio Telemetry Ground Module. (Ooooh, Ahhhhh). You see, tenacious reader, in all other instances that I have observed the flamewheel in action the operator simply plugged in the transmitter and everything worked just fine. Alas, this was not meant to be for me. When I ran my launch file the code refused to execute because it couldn’t find the transmitter. This would be perfectly understandable if the transmitter wasn’t plugged in. (It was).

My Linux VM recognizes that there is something plugged in. However, it doesn’t have a driver attached to it which is my current working theory on why the FPV Radio Telemetry Ground Module isn’t recognized correctly by the Linux VM. I plan on solving this issue next week.

Leave a Comment