Getting in the air

Author: Jonah Siekmann

A few weeks ago, I started putting together various different quadcopter builds and comparing cost, efficiency, and lifting power. I’ve come up with a few builds that I think are pretty solid:

I also had two drones laying around in my dorm that I’d built the previous year, and I figured I could use those to do some tests on how long they could stay in the air with a payload of a given weight, since that would give us concrete data on what specs might or might not work.

However, to do that I needed to rewrite the flight controller I’d written previously, because the old version used rate mode – which means that the quad didn’t know which way was up, and it was up to the user to make sure it stayed pointing in the right direction. To carry a payload (and eventually navigate autonomously) I needed to make the quadcopter autolevel – meaning the flight controller needs to know which way is up, and can stay pointing up (instead of say, pitched 30 degrees forward). 

So for the last few days, I’ve been putting together a new flight controller paired with an IMU (instead of a standalone gyroscope) and trying to get that working. I had an issue that kept me grounded for about half a week where the MPU6050 (the IMU I’m using) wouldn’t start up unless the Arduino Uno was plugged in through USB – I’m still not sure what exactly was causing that, but I wired it up to a UBEC and it worked fine.

Today, I flew the drone with a payload roughly the same weight as the RFID reader we’ll be using – about 750 grams. The drone flew surprisingly well with the extra weight, although it was still very difficult to manage – the PID values are tuned for a drone about 750 grams lighter. Here’s a picture of me trying my best to keep it in one spot (hence the facial expression):

However, I encountered an issue where it seems like the Arduino Uno shuts off randomly, while leaving the motors spinning – usually resulting in the drone flying into a wall or nearby bush. This isn’t a very desirable outcome when carrying a sensor package worth almost $500, so I need to figure out what’s causing that before we do any testing with it. I have a feeling it’s due to a crappy solder connection on my part, so over spring break I think I’ll just rebuild the whole thing and see if it keeps happening.

-Jonah Siekmann, URSA researcher

Building a Drone

Author: Jonah Siekmann

For this project, we’ll need to construct a drone that will carry the RFID reader around a crop field. It’ll need to remember the locations of every new RFID ‘Dogbones’ moisture sensor it encounters, and store the GPS coordinates so that it can return to the sensor later. We’re not sure yet how much weight it’ll need to carry, which leaves a lot of the the specs of the drone up in the air. We’ve come up with a general parts list, however, which includes the following:

CC3D Flight Controller

750KV Motor (x4)

30A ESC (x4)

4000mah 3s battery

12×4.5″ propellors

650mm frame

Arduino Uno

GPS module

RC Transmitter/Receiver

Our idea for flying the drone autonomously involves hooking up the Arduino to the CC3D flight controller’s RC receiver pins, and simulating the 1000-2000us pulses that the flight controller would expect from a receiver with the Arduino. This way, the CC3D flight controller does all the low-level attitude hold and hovering work, while the Arduino is free to read the GPS sensor and control the position of the quad by pretending to be an RC receiver.

We Broke It

Author: Brett Stoddard

Today the RFID team fried the Cottonwood when we supplied it with 12V instead of 5V. 

A new, better system was purchased and should be getting to us soon.

RSSI Moisture Test 1

Author: Brett Stoddard

Hello all, today the RFID team figured out how to use the Cottonwood to communicate with the Dogbone tags. To celebrate, we measured the Dogbone tag’s RSSI value in wet and dry conditions. This was done to see if RSSI value could be used as an indicator of moist conditions.

RSSI value is a measurement of received signal strength. It’s an acronym for “received signal strength indicator”. It’s often used in WIFI signals. Here is a good article from MetaGeek that explains it further: http://www.metageek.com/training/resources/understanding-rssi.html

For this test, we read multiple RSSI values when the tag was dry first. We then wet a piece of paper behind the tag and recorded the RSSI values again. The picture below shows our setup. It should be noted that while wetting the tag we might have disturbed the system which would mean that our results will need to be backed up with further, more precise testing.

wet_dry_test_setup

 

To receive the RSSI data, we sent an “Inventory Command with RSSI” command from the Arduino to the Cottonwood. The command was sent as a character array { 0x44 , 0x03 , 0x01 } and was taken from the Cottonwood’s datasheet. We got back a message that contained the RSSI value in the third byte of the response. Below is a table with the RSSI values measured in wet and dry conditions.

This is the table of the data. As you can see the Q value average was higher than the Q value average in dry conditions. A higher RSSI in wet conditions could be attributed to the presence of water tuning the signal.

In conclusion, there might be a slight correlation with moisture, but further testing is needed. Also, the distance between the antenna and tag is a large factor in the RSSI value and should be taken into consideration before implementation.

Powering up!

Author: Chet Udell

We received our Cottonwood UHF RFID reader today and are powering it up as we wait on our moisture RFID tags to arrive from SMARTEC.