REU Experiences Uncategorized

SRP Week 10

Blog 10: Week of 8/10/18


Andrew Brown again. This is actually the last time I will be reporting. It is currently 6:09 on Wednesday morning. I have been up since 2:15 because the bus to Omaha left at 3:00 a.m. I am sitting on my flight back to Sacramento! There will be about a 50 minute layover in Phoenix, and then the final leg to Sac. I’ll land at 9:00 a.m. west coast time. Mom will be picking me up! I have not had anything substantial to eat since dinner time yesterday, so I am hoping she and I will stop by McDonalds on the way home for some Bacon Egg and Cheese Biscuits – one of my favorite foods in the whole world!

This last week was easy. On Monday we had a poster presentation session for the engineering department. My expectation was that groups would come through and stop by everybody’s poster and listen to their presentation. Instead, people just came and walked around. If they were interested in your poster they might stop and ask some questions, but our posters were at the end of the line and not many people dropped by. I believe I only talked to three people. However, one of those people was a professor from the engineering department and I feel like we had a good conversation.

That evening was the goodbye banquet. Everybody from the REU program got all dressed up and we ate dinner on the bottom floor of the Cather Diner Center. At the dinner they announced the poster finalists for each lab. Shannon and Jason were the finalist for our group! If you two are reading this, well done you guys!

Tuesday was the big presentation day where everybody from the REU presented their poster. For me, this presentation was even less stressful than the first one because I was not a finalist. This meant I got to go around and see some other posters, which I really enjoyed. Some of the bio students are working on projects with some seriously life changing implications. I also got to talk to Xinkai for a while at the presentation, which I always enjoy.

After the presentation all of the NIMBUS REU students went back to the lab for some goodbye coffee and snacks. It was sad to say goodbye to everybody. It really was a great summer. We learned a ton, got to play with drones, and I think built some meaningful relationships. I hope to see many of the people from the lab and from the larger REU program again.

Misc *

Network Connections in Room 218

To HC4

VM Editor: bridged to VM net 1 // I210 GB Adapter

VM Settings: Network Adapter 5, Custom: VMnet 1


Vicon Related

On Windows: Renamed to “Vicon LAN” I217-LM

On VM:

  1. Network Editor: VMnet 8, bridged
  2. VM settings: Network adapter 2, custom, VMnet 8

Eth0 on Linux (

Vicon is at 10.1, cameras at 10.11-17


Hover Control Laptop Related

On Windows: “To HC4”                 I210 GB

On VM:

  1. Network Editor: VMnet1, bridged
  2. VM settings: Network adapter 5, custom, VMnet1

Eth3 on Linux







Procedures *

Crazyflie and Networking Related Procedures

Crazyflie setup process


NIMBUS Lab operates the crazflie 2.0 using the work of Whoenig and his associates from USC ACT Lab. Their documentation can be found at However, there are some wholes in this documentation. The purpose of this document is to walk the Crazyflie operator through the setup of the Crazyflie system, from downloading a virtual machine to navigating the holes in the USC Crazyflie documentation.

  • If you are working in room 218 you will probably want to skip to page 7 of this document to “Actually Operating the Crazyflies.” If not, you will probably want to start with “System Reqirements

  • If you want Internet on the desktop in room 218 look under “Possible Problems

  • The current distributed controller is a python script under:



  • Crazyflie PID controller is in Crazyflie firmware under


  1.          Instruction for compiling and flashing this firmware can be found at “


  • Host computer has Windows 7 as native OS

  • Host computer uses has VMware® Workstation 12 Pro

    • Version 12.1.0 build-3272444

  • Host computer uses Vicon

    • A Vicon network adapter is already present on the host machine under path “Control Panel\Network and Internet\Network Connections”

Possible Problems:

If you are working in room 218 it is likely that the USB Wi-Fi receiver on the HRI desktop will be too slow to download packages or load a website at a reasonable rate. If this is the case, you may want to bridge the Wi-Fi from your laptop to the desktop.

Setting Up Bridge Between Windows 10 Laptop to Ubuntu 16.04 VM

Setting Up Bridge on Windows 10 side:

  1. On your Windows 10 Laptop right click on the Wi-Fi icon on the bottom right hand corner of your screen

    1. You may need to click on the upward carrot on the bottom right hand corner of your screen to get to the Wi-Fi icon.

  2. After right clicking select “Open Network and Internet Settings”

  3. Select “Wi-Fi” from the menu on the right hand side of the “Settings” window

  4. Scroll down to “Related settings” and select “Change adapter options

  5. Plug one end of an Ethernet cable into your laptop and the other end into the Windows 7 desktop which is hosting Ubuntu 16.04

    1. If you do not have an Ethernet port on your computer you will probably need to use an Ethernet to USB adapter to connect to your laptop.

    2. You probably have a choice whether you want to use another USB adapter to connect to the desktop or if you want to connect the Ethernet cable directly to the back of the desktop – the second half of these instructions only apply if you choose to use the adapter. If you choose to connect directly with the Ethernet you will have to do more work with the network adapter on the Desktop, and this documentation will not walk you through that.

  6. You should see a new connection pop up in the “Network Connections” window when you have plugged the Ethernet cable into both computers.

  7. Highlight your current Wi-Fi connection and the new Ethernet connection together

    1. The Wi-Fi connection should say “” or the name of whatever Wi-Fi you are connected to.

    2. The Ethernet should say “Unidentified Network”

  8. Right click on the highlighted networks and select “Bridge Connections

  9. In theory you should now be bridging Wi-Fi to the Windows 7 computer, but normally I find you still have one more process to go through

  10. Unplug the Ethernet cable

    1. The Ethernet connection and bridged connection should disappear

  11. Right click on the Wi-Fi connection and select “Remove from Bridge

  12. Right click on the Wi-Fi connection again and select “Add to Bridge

  13. Now if you plug the Ethernet cable back into your laptop you should be bridging Wi-Fi to the desktop

  14. You should now have access to Internet on the Windows 7 host desktop

Setting Up Bridge on Ubuntu Side:

These instructions only apply if you are using a USB adapter to connect to the Windows 7 host.

  1. When you plug the USB adapter into the Windows 7 host you should notice a new USB icon show up on the bottom right hand side of your virtual machine. Click on this icon and make sure the USB is connected to your VM.

    1. If the USB is connected to your computer then when you right click on the icon you will have the option “Disconnect (Connect to Host)”

    2. If the USB is not connected to your computer you will have the option “Connect (Disconnect from Host)”. Select this option.

  2. Now in the top right hand of your VM click on the network icon. This will either look like the Wi-Fi icon or it will be two parallel arrows side by side.

  3. Select “Edit Connections

  4. Select “Add

  5. Make sure the drop-down menu says “Ethernet” and then select “Create

  6. Under “Device” in the resulting window select the device you just plugged in to your computer

    1. The device you just plugged in should be the only one that does not share a MAC address with one of the network adapters for your VM. To determine the MAC addresses of your VMs network adapters:

      1. In the upper right hand corner of your screen select “VM

      2. Select “Settings

      3. Select a network adapter from the menu on the left hand side of the window

      4. On the right hand side of the window select Advanced

      5. Note the MAC address at the bottom of the resulting window

      6. Repeat this process for each network adapters

  7. Once you have selected the correct device select “Save

  8. You should now be able to access the Internet from your virtual machine!

System requirements:

  • Ubuntu 16.04

  • ROS kinetic

Downloading Ubuntu 16.04 to VMware Workstation:

  1. Go to in your web browser.

  2. Select the 64-bit PC (AMD64) desktop image link on the website. An .iso file should begin downloading

  3. Make sure to note the file path of the .iso file

  4. Once the file has downloaded (which may take a while) open VMware and select the “Home” tab in the upper left hand corner.

  5. Now select the “Create a New Machine” option from the options in the middle of your screen.

  6. Follow the “New Virtual Machine Wizard” that pops up.

  7. On the second screen of the wizard select “Browse” and choose the .iso file you just downloaded.

    1. Tip: when you choose a user name and password for this virtual machine, unless you expect to store anything confidential, make the username and password as short as possible. You will need to use your password a lot so you do not want it to be long and you do not want to forget it – make it the same thing as your username.

  8. As you follow the wizard, when it asks you how many processor you want to give your virtual machine, select as many as is reasonable for your computer.

    1. If you are unsure what this number is Jean Paul or AJ might be good people to talk to.

    2. For the computer in room 218 select 8 processors.

  9. For selecting the optimum amount for RAM or memory talking to AJ or Jean Paul may be necessary.

    1. You will need 1.4 GB of ROM at a minimum to download everything necessary for flying the Crazyflie

    2. The desktop VM in room 218 has 16 GB allocated to the “CrazyflieDesktop” VM

    3. The desktop VM in room 218 also has 16 GB of RAM

  10. Once the wizard is finished you should be good to go.

  11. Go to “Home” again and select “Open a Virtual Machine”.

  12. Somewhere on your computer there should be a file with the name you gave your VM. Open that file and select the document of type .vmx. This should open your new VM.

Connecting Ubuntu 16.04 VMware Workstation to Vicon Network Adapter:

In order for your virtual machine to receive Vicon data it needs to join Vicon’s network. Vicon has a network adapter on the Windows 7 host. This is where the Vicon application sends all of the telemetry data it collects from objects in the room. You need to make a network adapter on your virtual machine in order to receive this information from Vicon. Finally, these two network adapters need a way to talk to one another in order that the VM can receive Vicon data from the host computer. This final piece is called a bridge. The network adapter on the Windows 7 end should already be set up on the host computer. However, you will need to set up the bridge and the Ubuntu network adapter yourself. The following steps describe how this is done.

Setting Up Ubuntu Network Adapter for Vicon

  1. Open your Ubuntu 16.04 workstation

  2. In the top left corner of your screen select “VM

  3. At the bottom of the drop-down menu select “settings

  4. Toward the bottom left of this window select “Add

    1. At this point you will probably need the administrative password to the Windows 7 host.

      1. The administrative password for the computer in room 218 is ‘Avery365bduncan’

      2. You may want to copy this password to you clipboard so that you can paste it instead of typing it as it is pretty long.

  5. Select “Network Adapter” from the list of options to the left of the window and click “next”.

  6. Select “Custom” and then choose an unused VMnet.

    1. You can tell whether or not a VMnet is used by looking at the “Device” menu under the “Hardware” tab of the “Virtual Machine Settings” window. If a VMnet is used it will be in parentheses after the name of one of the listed network adapters.

  7. Select “Finish”

Setting Up Bridge Between the Vicon Network Adapter and the Ubuntu Network Adapter

  1. Open your Ubuntu 16.04 workstation

  2. On the top left hand corner of your screen select “Edit

  3. Toward the bottom of the drop-down menu select “Virtual Network Editor

  4. Select “Change Settings” at the bottom right side of the window

    1. At this point you will probably need the administrative password to the Windows 7 host.

      1. Follow “a)” of step 4 of “Setting Up Ubuntu Network Adapter for Vicon”

  5. Select “Add Network” to the bottom right of the first list in the window.

  6. Now, using the drop-down menu in the “Add a Virtual Network” window choose the same VMnet you chose in step 6 of “Setting Up Ubuntu Network Adapter for Vicon”

  7. Select “OK

  8. Under the VMnet Information heading select “Bridged

  9. Now you have to use the drop-down menu after “Bridged to” order to select which Ethernet connection you want to connect to. In order to do this you will need to see which Ethernet connection the Vicon Network adapter is communicating with.

    1. Click on the Windows icon in the bottom left hand corner of your screen and type “Network and Sharing Center” in the search bar and hit ‘Enter

    2. In the top left hand side of the window that pops up select “Change adapter settings

    3. You should now see a list of all of the network adapters on the Windows 7 host machine. Hopefully one of these adapters is named “Vicon_LAN” or something similar which includes the name “Vicon”

      1. If not talk to AJ (thank you AJ)

    4. Underneath the network adapter you should see the network name and the name of the Ethernet connection that the adapter is using to communicate

    5. Note the connection that Vicon is using and then return to the “Virtual Network Editor” window and select the correct connection from the “Bridged to” drop-down menu.

  10. Click “Apply

  11. Click “OK

Accessing the Vicon Network from Inside the Ubuntu Virtual Machine

In order to use the network you just set up between Vicon and your Ubuntu VM you will have make a network connection from the inside of your Ubuntu VM. First you have to add the IP address of your Vicon network adapter to the “hosts” document on your VM. Then you will make a network connection which will allow you to use access Vicon data from your VM.

  1. Open a terminal in you Ubuntu VM (ctrl+alt+t)

  2. type: ‘cd ../..

  3. type: ‘sudo gedit etc/hosts

  4. In the top of the document paste type: “[Vicon Network Adapter IP Address] vicon”

    1. In order to determine the Vicon network IP address first follow steps 9 a) – c) of “Setting Up Bridge Between the Vicon Network Adapter and the Ubuntu Network Adapter”

    2. Double click on the Vicon network adapter

    3. Select “Details

    4. Use the IPv4 address in the “hosts” document

  5. Select save and close the “hosts” document

  6. In the top right corner of your screen click on the network icon in your Ubuntu VM

    1. The icon will either be the Wi-Fi icon or two parallel arrows pointing in opposite directions

  7. At the bottom of the drop-down menu select “Edit Connections

  8. Now select “Add

  9. Choose “Ethernet” from the drop-down menu and the select “Create

  10. In this window there should be a “Device” heading with a drop-down menu which will show you all of the available Ethernet or ens connections

    1. To determine which connection to use click VM in the top right corner of your screen

    2. Select “Settings” at the bottom of the resulting drop-down menu.

    3. Click on the network adapter that is connected to Vicon

    4. Toward the bottom right hand side of the window select “Advanced”

    5. In the resulting window note the MAC address used by the network adapter

    6. Return to the connection editing window and select the Ethernet or ens connection with the same MAC address as the network adapter

  11. Make sure “MTU” is set to “automatic” and Wake on LAN to Default

  12. Go to the “IPv4 Settings

    1. Change the drop-down menu under “Method” to “Manual”

    2. Click “Add under the Addresses heading.

    3. Under the “Address” header make a new IP address for you computer. Check the doc entitled “Network Connections in Room 218” on the NIMBUS website to make sure you are not using an address that has already been used

      1. The first three sections of your address must match the first three sections of the Vicon network adapter address. (probably 192.168.1.[your ID])

    4. Under the “Netmask” header use When you come back and look later the netmask may say 24. This is OK. Apparently 24 is the abbreviation for

    5. The Gateway is the same as the IP address of the Vicon network adapter.

  13. Go to “IPv6 Settings

    1. Make sure that “Method” is set to “Link-Local-Only”

  14. Select “Save

  15. You Should now be able to access Vicon data on your Ubuntu 16.04 VM

Downloading ROS Kinetic onto Ubuntu 16.04:

ROS Kinetic can be downloaded by following the steps at In step 1.4 enter the command for “Desktop-Full Install” into your terminal and then move on to step 1.5.

Patching Wholes in Crazyflie Documentation:

Communicating with Crazyradio

The Crazyflie documentors from USC ACT Lab mentioned in the introduction ( seems to make the assumption that you have kept up with their previous work. Therefore they do not include the instructions for setting up your operating system to work with the Crazyradio. Before attempting to communicate with the Crazyflie via Crazyradio follow all of the instructions in section 3.1 and the first block of commands in section 3.2 of previous Crazyflie documentation Note that the first block of commands in section 3.2 should say “python3-pyqt5” (not “python3-pyqt4”)

Troubles with Build

If the “./” command does not work do not worry. Keep following the instructions. The “python –sim will not work either. This is ok, keep moving.

Before running the “./” command you will need to use another command the documentation forgot to included. Run this command in the directory ~/crazyswarm:

‘git submodule update –init –recursive’

USC ACT Lab made the crazyswarm workspace out of a number of different trees. The initial git clone command does not grab all of the trees. Therefore we use the command above.

Now you can run the “./” command, but this also must be done in the parent “crazyswarm” directory.

Flashing New Firmware to Crazyradio

You will need to use the full file path as described in under the next heading.

Flashing New Firmware to Crazyflies

We have only used Option 2 Under “Crazyflie Preparation” in NIMBUS Lab. So if you decide to use Option 1, best of luck. Option 2 works well, but the filename needs to have the complete file path to the file you want to flash to the Crazyflie. In room 218, the file path for the nrf51 target is “/home/cf/crazyswarm/prebuilt/cf2_nrf.binand the file path for the stm32 target is “/home/cf/crazyswarm/prebuilt/cf2.bin”.

Problems with Tool Scan

The instructions say that the command “rosrun crazyflie_tools scan” will report the firmware version of the crazyflie. This may have been true when they first made the tool, but now reporting the firmware has been made into an option. The correct command to use is “rosrun crazyflie_tools scan -v”. The v stands for verbose.

Also, in order to locate a Crazyflie, the scan tool needs to know what address to search. If the tool is not finding a Crazyflie even though you know it is on, go to “~/crazyswarm/ros_ws/src/crazyflie_ros/crazyflie_tools/src/scan.cpp”. On line 12 make sure the address matches that of your Crazyflie (If you’re not sure what the address is, look under the heading Understanding Meaning of “id” Crazyflie.yaml files” two sections down).

Problems with yaml library

The first time you launch “hover_swarm.launch” it may be that you get an error complaining about yaml libraries. I am pretty sure the fix is download the correct yaml library:

‘pip install yaml3’

However I am not certain and have been unable to test to make sure that this is correct. Whether or not this is the exact right command I am certain that the problem has to do with missinig the correct yaml library. Use Google to look up problems with yaml libraries and how to download them.

Understanding Meaning of “id” Crazyflie.yaml files

“id” in the files “allCrazflies.yaml” and “crazyflieTypes.yaml” must be the same as the end of the corresponding Crazyflie’s address. For example, if my Crazyflie has the address “0xE7E7E7E701” then its id would be “01”. If its address is “0xE7E7E7E712”, then the “id” is 12.

Actually Operating the Crazyflies

  • Everything that follows assumes you are using “motionCapture” system (If you do not know what I am referring to, read under “Select Motion Capture System” in The “libobjecttracker” works as well, but this requires that every Crazyflie shares the same marker configuration and that each Crazyflie starts from a home position each time you start the Crazyflie server (“hover_swarm.launch”)

  • When making a Crazyflie object in Vicon it is absolutely vital that you make the object centered in Vicon’s coordinate system and facing forward in the positive x direction.

  • In order to successfully kill “”, after you hit ctrl+c you will need to pass your curser over the GUI.

Steps to getting Crazyflies in the air:

  1. Make sure the Crazyflies you plan to fly are selected by “”.

  2. Make sure all of the Crazyflies are on and that they have been turned off and on since the last time they were connected to the Crazyflie server (the crazflie server is launched when you launch “hover_swarm.launch”).

  3. Make sure the Crazyradio has been unplugged and re-plugged before launching “hover_swarm.launch” (not exactly sure why you have to do this, it may have something to do with the fact that we are using a virtual machine – either way, this step is vital).

  4. launch “hover_swarm.launch” by typing “roslaunch crazyswarm hover_swarm.launch” in the consul.

  5. Now you can make the Crazyflies hover with the Xbox controller by plugging the Xbox USB dongle into the computer and then pressing the start button on the Xbox controller.

  6. Make the Crazyflies land by pressing the back button on the Xbox controller.

  7. You can write a python script to control the Crazyflies using the library discussed on the Python API section of the USC ACT Lab crazyswarm documentation.

  8. In order to run the python scripts make sure you have saved the script in “~/crazyswarm/ros_ws/src/crazyswarm/scripts”.

  9. Go to the library where you have saved the script and enter “python [name of script].py”.

  10. In order to kill a python script you may need to enter ctrl+z instead of ctrl+c.

  11. When you kill a python script the Crazyflies will stop and hover where they are. You will need to land them with the Xbox controller by pressing back.

  12. You can also stop anything the crazyflies are doing by pressing “X” on the Xbox controller. The Crazyflies will just fall out of the air.

Trouble Shooting

  • If you get a timeout error when launching “hover_swarm.launch” try check these six things

    1. Make sure that the VM is connected to the Vicon network (click on the network icon in the top right of your screen and make sure “Vicon” is connected”.

    2. Make sure Vicon is not paused.

    3. Make sure as many Crazyflies are on as selected in “”.

    4. Make sure the all the Crazyflies have a blinking red light. If any one only has a solid blue light you will need to turn it off and turn it back on.

    5. Make sure you have removed and replaced the Crazyradio from the USB port since the last time you killed “hover_swarm.launch”.

    6. If you are still getting a timeout error, remove the Crazyradio, kill “hover_swarm.launch”, restart every Crazyflie, replace the radio, and relaunch “hover_swarm.launch”.

REU Experiences

SRP Week 9

Blog 9: Week of 8/3/18

Andrew Brown reporting in once again and this time for the last time. This week was the wrapping up week. It has been relaxing as stressful all at the same time.

On Monday I worked all day putting the final touches on my poster. It was due at 5:00 p.m., and I turned it in around 4:50. I was relieved to have finished and felt like I did a pretty good job, but I could not shake the feeling that I had missed something. On Tuesday I came in and examined the copy I had submitted. It was then that I noticed that I had subtracted two values in my central equation in the wrong order.

I spent the rest of Tuesday writing documentation for the work I did this summer and trying to write my paper due next Tuesday. On Wednesday we went to a group seminar in the morning. On the way back from the seminar Jason pointed out to me that Dr. Duncan had emailed us the week before letting us know that we had to present our posters to each other on Wednesday. I spent the hour left to me in the morning preparing for the presentation. I think it turned out pretty well. My presentation went a little bit over time, but I showed that I knew what I was talking about, which was good.

The rest of Wednesday and most of Thursday I finished my documentation (8 pages in all!). On Thursday afternoon I started working on my paper in earnest. I had tried to make some headway in the evenings, but the words just would not come. To add to this frustration, it took me two and a half hours on Thursday afternoon to figure out how to make my LateX document compile with the BibTeX included. After hours of banging my head against this wall it turned out that my problem was that I had white space in the document’s title – very frustrating.

Today I have spent all day working on my paper, and I have actually made some headway! Chandima has been helping me to wrap my head around exactly what I want to say and exactly how our distributed controller differs from a normal distributed controller.

This weekend I have to finish the paper, pack, and prepare for the poster presentations on Monday and Tuesday. The summer has been a great experience. I have learned a lot about what I am looking for in a research lab based off of the positive things I have seen here. The people in the lab make for a great work atmosphere, and the subject matter, drones, makes time spent in the lab interesting and rewarding. I was loath to leave home for the summer, but after living through my time at UNL, I do not regret leaving one bit.

I have no idea what my future holds, but I know this summer has been instrumental in preparing me for it, and I am excited to see what comes next!

REU Experiences

SRP Week 8

Blog 8: Week of 7/31/18

            Andrew Brown again, and I really dropped the ball on the blogs this week. It is Tuesday and I am doing my blog for last Friday. That being said, the week went really well.

Last week ended with worries that I would not be able to implement the new controller on to the Crazyflie firmware. Dr. Bradley came in on Monday to check up on my progress. I started explaining to him how I was still unable to locate the controller in the code. He sat down to see if could find it, and to my chagrin, I realized at that moment that I had already seen the controller but failed to recognize it. There were more spaces between the function call and the definition then I had expected – very lame.

Thankfully, however, Dr. Bradley realized that I was going to be unable to make all of the necessary changes to the firmware and the crazyswarm workspace in time to get data for my project. Instead of having me pursue firmware changes any farther, he allowed to me to write the distributed controller using the Python library already proved by USC ACT Lab. This took most of the rest of the week.

At one point, I accidentally only applied the controller to one of the Crazyflies. The purpose of this controller was to make all of the Crazyflies converge to the same spot. This was before I introduced a gain to the code, so the Crazyflie with the controller was flying full speed at the other. Dr. Duncan came in and allowed as how it was probably a poor practice to test our expensive scientific equipment by crashing it in to one another. I had gotten so used to the Crazyflies being tough, that I had forgotten that they are also expensive and that the lab had invested a lot in them. From that point on I was much more careful with them. Instead of allowing them to crash into each other, I would grab one out of the air before collision and see how the other reacted. The other Crazyflie wanted to be at the position of the Crazyflie in my hand, so it would fly toward me. I felt like a matador in the ring! The Crazyflie would zoom toward me. I would hold the Crazyflie in my hand out to the side, and the one in the air would zip by, turning to look at me as it past and then coming around for another pass. This would happen until I chose to grab it out of the air or until it tried to turn to fast and fell to the ground – super fun to say the least!

On Friday I was finally able to collect data and spent most of the day writing a MATLAB code to parse this data. I stayed into the evening Friday and came back in Saturday to finish up. I stayed in the lab until about five o’clock on Saturday and then stayed up late to finish up my poster. When I finished, I sent it to Dr. Bradley for feedback and then went to bed. I had all Sunday free!

On Monday I spent all day crossing my t’s and dotting my i’s on the poster and turned it in at the end of the day. Now we are very near the end of our time at UNL. I have all week to work on my paper and to document my work in the lab for the next person who works with the Crazyflies. This summer has been an awesome experience, but now I cannot wait to go back to Sacramento and enjoy my last few weeks of summer with family and friends!

REU Experiences

SRP Week 7

Blog 7: Week of 7/20/18

It is Andrew Brown again, and boy what a week. On Monday, Dr. Bradley came in to my little room to see my working Crazyflies and to discuss my next step. He said that I should get the Crazyflies flying in formation using the pre-packaged code that I have been working to implement this summer. We also agreed that I would prepare a lit. review and complete the introduction to my paper by Friday.

I spent the majority of Monday switching from the motion tracking system included in the prepackaged code to the object tracking system used by Vicon. This required a hardware alteration. For the motion tracking system, each Crazyflie had to share an identical Vicon marker layout with every other Crazyflie. With the object tracking system each Crazyflie must have a unique marker layout. However, if the markers are too close to one another, Vicon will not be able to distinguish one marker from another. Eventually I ended up adding extra carbon fiber rods to two of the Crazyflies to make them sufficiently unique.

By Wednesday I had the Crazyflies flying in formation! Dr. Bradley came in and he introduces me to the control algorithm we want to implement on the crazyflies. He said to spend only a day figuring out how to implement this new controller. I spent the rest of Wednesday, all of t Tuesday, and all of Friday trying to figure out where to put the controller. I made a little bit of progress, but I am still miles away from successful implementation.

Dr. Bradley said he would check in with me toward the end of the week, but he is really busy and did not have the time. Hopefully he will have some time to talk with me on Monday. I think I could implement the controller eventually, but it might take me months, and we do not have that kind of time. My paper and my poster are due within the next two weeks and I need results. At this point I cannot see how I will have them. If my results come from me successfully implementing the controller it will literally be a miracle.

I stayed up late Friday night completing my lit. review and introduction because I had spent much of my evenings earlier in the week working on my coding problems. Also, I forgot to do my blog post on Friday because I was busy doing other things in the lab. I really wish that the blog was due by the end of the weekend as opposed to at five o’clock on Friday.

I am not sure how next week is going to go, but at this point I am not overly worried. I will give my all trying to implement the controller. If this is enough to accomplish the task, yay! If not, I’ll trust that the Lord knows what He is doing and see where the chips fall.

I am still fascinated by the work. It amazes me that I have been working in a drone lab this summer.  What a great opportunity! I guess we will see what next week brings. Hopefully I return with a glowing report.

REU Experiences

SRP week 6

Blog 6: Week of 7/13/18
Andrew Brown reporting back one again! This week began with disappointment and was followed by an uneasy and discouraging middle, but it ended in victory!!!
As I mentioned last week, Dr. Bradley came in Monday morning to help me troubleshoot the crazyflie. After a few minutes of discussion, we decided that it would be best for me to move on from the old script and see if I could apply the new one. Dr. Bradley reasoned that the research aspect of this project requires the drone to do on-board trajectory planning, and because this new script allows the drone to do this while the old one does not, I should forget about the old script and apply the new one. Because of this decision it was my turn, once again, to sit and figure out how to follow the script and get the crazyflie in the air. I was looking forward to having someone else with more experience than I have help me trouble shoot the old script, so the fact that I had to leave behind this help and move into the uncertain realm of getting the new script run was quite disappointing.
Throughout the week my fears were mostly confirmed. There seemed to be all sorts of unexplainable failures to overcome such as: Why will not the radio flash the new firmware to the crazyflie? Why will not the “scan” tool find the new radio now that I have flashed it with new firmware? Why does will not my Wi-Fi bridge reset correctly when I unplug the USB drive? And worst of all: Why cannot I get Vicon to talk to my new virtual machine?
Little by little I discovered little tweaks and fixes and got each step in the new script working properly. I spent a full day trying to Vicon to work. Finally, I gave up and asked AJ for help. It took him ten minutes. I had forgotten to add Vicon to the “hosts” permissions file on the new virtual machine – very frustrating.
Liam was in and out of my little room on Wednesday and Thursday just to see what I was doing and offer trouble shooting suggestions. I have been grateful for his input. I have also sent a few questions to the creator of the crazyflie script, and he has responded! His input has allowed me to make the computer communicate with the crazyflie radio and to make the radio communicate with the drone.
Talking with Liam gave me an idea for why the computer kept giving me a timeout error when trying to connect to the drone. I ended Tuesday by getting the R-Viz GUI up, even though I still could not run the crazyflie. Finally, today I came in, gave the computer the correct positional information for the drone, and hit the hover button. The crazyflie lifted off the ground and hovered smack dab in the middle of the room just as it was supposed to! I ran and got Liam to come look. Shannon heard the commotion and came to see, and Carl arrived just as I was celebrating with Shannon and Liam. It was a great moment – all four of us standing outside of the room watching the crazyflie hover like a proud bird just learned to fly!
I hope to have two drones flying at once by the end of the day. This weekend I need to read some papers so that I can start on the actual research part of the project next week. I am excited and relieved finally to have broken through this crazyflie wall. I hope the next stage of the project goes smoothly so that I can write my paper and complete my poster without having to scramble too much last minute.

REU Experiences

SRP Week 5

Blog 5: Week of 7/5/18

Andrew Brown again! This week started in frustration, peaked with some excitement in the middle, and ended with hopeful, yet uncertain expectation. We ended off last week with the small computer having loaded all of the crazyflie software correctly, yet unable to make the drone hover because the computer hardware was out of date. With the help of Carl, I spent some time trying to find a driver that would allow the small computer to function correctly. Eventually, however, it occurred to me that we could simply upload the correct software onto the desktop connected to Vicon. Even though we would still be running through a virtual machine, this would minimize the number of times Vicon positional data had to pass in and out of a virtual machine. We believed forcing Vicon data to go in and out of more than one virtual machine was the root of the latency problems, so I was very hopeful that placing the crazyflie software directly on the Vicon virtual machine would fix the issue … but I was wrong. There was not change in the crazyflie’s behavior.

The benefit of this failure, however, was that we could check latency issues off the list. The next step was to look at the code. Dr. Elbaum and Dr. Bradley each came and talked with Riley and me for a little bit in order to point us in the right direction in terms of code analysis. Dr. Elbaum showed us the variable we probably wanted to track. He also introduced us to some terminal tools that streamline searching for specific words across many files and documents. Dr. Bradley gave us a lesson on the PID controller in order to help us better understand what the code was trying to accomplish.

Work on the crazyflie took a pause mid-week because we had a meeting where we learned that we have a lit review to write and a paper due by the end of summer. I really wish we had been told about these things in the first week, but I believe there is still plenty of time do a good job on the paper. Serios work on the crazyflie did not really resume until after the Fourth of July break on Wednesday.

Over the break I called my parents. While describing my work to them I remembered that there was a way to make sure all of the code and all of the drone’s firmware was reverted back to the exact version used by the script we have been following. I came back Thursday excited to give this a try. As I did the preliminary tests before getting the drone to hover, things seemed really promising. Inconveniences we were dealing with before I reverted the code had disappeared, and my heart beat fast as I gave the drone the hover command.

Nothing! The droned behaved exactly as it had.

I met with Dr. Bradley later that day and he gave me a clearer picture of what my research will be after I finally get the crazyflies working. He also made plans to sit down with me and help me do some trouble shooting.

Thursday ended with one more brief moment of hope. I figured out how to get the code to print the variables of the PID error function to the consul. This revealed that the author of the code input variables to the error function in the wrong order. I switched the variables, said a little prayer, and pressed hover. Nothing changed. I looked through code a little longer and then went home.

Today, Friday, I found a new scrip that has the drones to do most of the trajectory calculation as apposed to making the computer do these calculations. This script equired me to make a new virtual machine with Ubuntu 16.04, so most of the day was spent downloading the virtual machine, getting the new script to download correctly (thank you Shannon), and fighting with network connections. Dr. Bradley and I are going to meet on Monday to see if he can’t help me figure all of this out. I really hope he can.

The worst thing about this week is that I got carried away with the crazyflie stuff and forgot to submit this blog by five o’clock this afternoon. Dr. Duncan specifically told us on Wednesday that we had to have the blogs submitted by five o’clock on Friday. Hopefully I have not messed up to badly.

Socially things are still good. I would like to note that Amy is a soldering wiz!

Hopefully next week’s report will contain some good news regarding the crazyflies.

REU Experiences

SRP Week 4

Blog 4: Week of 6/29/18

Andrew Brown here again. Last week left off with high hopes as we planned to try a couple of different computers to mitigate the latency which we believe is the root of the drone’s failure to hover in place while under computer control. We got my computer to work easily enough, but we had the exact same problem as with the other computer. The next step was loading Ubuntu onto the old “Hover Control 4” computer. The lab used to use this computer with the CubeSat but has not done so for some time. The computer has an atom processor. According to my understanding this processor came before the i5. It is really really slow. The hope, however was that the operating system on to the “Hover Control 4” computer would be able to send and receive information through the usb ports faster than my computer because the operating system would be native and not on a virtual machine.

However, in order to use the slow computer to fly the drone we first had to load it with ROS indigo. In order to download ROS indigo, we had to download ubuntu 14.04. Each of these steps took a really long time because the computer is so slow.

Along with using “Hover Control 4” computer, we also decided to use the Vicon system in the smaller room. We did this for two reasons. The first is that the Vicon cameras are closer together in the small room, giving this system higher resolution that the one in the big room. The second is that Siya often has participants in the large room. These meetings take a lot of time, so we will be able to work with less interference if we use the Vicon system in the smaller room.

Unfortunately, hooking up to Vicon in the smaller room included many hurdles. We tried to hook up first via wifi. The wifi was too spotty so we decided to hook up via ethernet. I was not sure how to go about this. I tried for a while by myself and then got AJ to help me. He worked on it for a little bit but did not have enough time to figure it out. I worked on it some more and then got AJ to help me again. He got the slow computer to communicate with the virtual machine on the Vicon computer, but then he noticed that while I was trying to get the ethernet connection to work, I broke the Vicon connection. It took him about an hour to reconnect Vicon. He was very gracious and did not get very upset with me for causing him so much extra work. I am truly grateful to him. AJ also explained to me what he did to fix Vicon and showed me how to make the ethernet connection work. I learned a lot.

On Friday we finally got the drone to fly in the small room. However, it still would not hover. This is probably because the slow computer does not have the proper graphics drivers. I am not sure its hardware can support the nessicary drivers, so we may have to get a new computer.

Socially things are good. We, the undergrads, still get along well, and the grad students are still awesome. Also, we won this week’s intermural volleyball game. We are not 2 and “o”!

Overall it was a good week. I really hope we get a drone to hover next week.

REU Experiences

SRP Week 3

Blog 3: Week of 6/22/18

Andrew Brown reporting in! This has been a really exciting week and a really dull week all at the same time. The first half of the week consisted of more battling with ROS. I tried to improve the code I wrote last week, and I also began teaching myself how to make c++ write to a csv (comma separated value) file. In other words, I made c++ write to Excel. I also started trying to use some listing functions in c++. I was beginning to get the basics down, but I am not sure if I ever fully figured it out.

Finally, at about three o’clock on Wednesday afternoon I met with Dr. Bradley to figure out what my project will be. He put me with Riley, working on the Crazyflies! This was super exciting at first because it involved actual hardware and not just staring at a computer screen all day long. However, there were many bugs in the system, and we were/are not exactly sure what to do about any of them. Today, Carl came to the conclusion that part of our problem was that we were using the NIMBUS Wi-Fi, which is super slow. He connected us to the ethernet and the drone behaved a little bit better, but we think that the virtual machine is not able to communicate with the drone quickly enough for it to fly properly. In order to fix this, we will try two things – setting up my computer to control the drone because it may be little bit quicker than the one we are currently, and using a Chrome book which hosts Ubuntu natively instead of on a virtual machine.

Once we figure out how to make the drones fly properly Dr. Bradley is going to show Riley and me how to write a controller for a drone. After this, I get to write a controller for multiple drones – unbelievably cool!

Also, on the social side of things, a am very pleased. The other SRP participants are fun to spend time with. We really get along well. I am very excited to see what the next weeks bring.