Today I conducted the first test of the boat’s navigation and data collecting capabilities. On this first attempt, one of the leads that supplied power to one of the motors became disconnected without my knowledge, and caused it to drive itself into seaweed. The one propellor that was still spinning quickly became entangled in the seaweed, and unscrewed itself from the driving shaft. Analysis of the logfile showed that both the sensors and GPS module were sending/receiving correct data. Unfortunately, I lost the propellor in the seaweed, along with some essential fastening hardware. To remedy this issue, I improvised with some resources I had to fashion a “peg leg propellor”, pictured below.
This makeshift propellor was much less powerful than the stock propellor, so in subsequent tests with it attached, the boat always turned to the left whenever the right propellor was spinning. However, the boat seemed to be trying to approach it’s set waypoint. That test I believe served as a very rough proof of concept.
Over the break, I have made leaps and bounds toward the completion of my project.
Firstly, I have permanently installed all of the sensors I intend to include, and mounted them on the GPS shield. I have programmed and wired these sensors correctly so that they respond with environmental data when such data is requested.
Secondly, the compass sensor has been mounted to the inside of the boat. The environmental sensors still need to be attached so they hang in the water, but for the first on-water test, it would be appropriate to secure them with tape.
Thirdly, the electronic “brain” of the project has been sealed inside a container and made water resistant. The Arduino board is still accessible for additional programming and debugging, and a separate hole has been drilled in the “brain box” container for possibly controlling an external power source, like a solar panel.
Fourthly, the data logging capabilities of the device’s “brain” are fully operational.
All that’s left to do before the first on-water test is to wire up the motors, configure multiple-waypoint navigation, and create a program timeout safety protocol in case of a runaway boat. I am most certainly on track with my deadlines, and I will be ready to present on schedule.
The boat’s navigational device is now aware of its heading relative to a Latitude,Longitude coordinate. However, since this was only made possible through the use of the TinyGPS++ Library, I will have to reprogram the data logging and data sensing functions. I have also realized there is a problem with the electronic compass, in that it will give the wrong heading if it is not level. In choppy or any other condition but calm, this will be a problem, because the boat rocking, or even getting up onto a plane, will throw off the navigation. I believe the solution is to incorporate an accelerometer/magentometer combination breakout board, and use some 3d vector math to have the sensor always return the correct heading, regardless of how the magnetometer is tilting.
The navigation code I though I completed yesterday doesn’t work at all.
Today I completed the navigation code that should direct the boat to a specified target latitude and longitude. The wiring I did yesterday seems to work nicely, and I am not having problems running the motors, nor is the relay shield or motors overheating when run for extended periods of time.
Today I took the motor shield out of the boat, and instead I wired a relay shield to the motor and battery.
Today I learned how to control a motor shield, which I will probably use in my project in the place of the simple relay board. Since the R/C boat I am attaching the sensors to uses propulsion steering, being able to control each motor’s speed and direction is important.
Movie on 11-19-14 at 5.07 PM
As of right now, I have a ways to go before I am at a point where I’m comfortable presenting my work. So far, my goals are:
- Work out the kinks with the electronic compass, mainly the serial stopping bug
- Get a relay board attached to the R/C boat, and be able to control the boat’s motion
- Be able to orient the boat correctly
- Get the R/C boat to arrive at a waypoint, then a series of waypoints
- Attach a charging circuit to the battery
- Utilize a source of power that either offsets the device’s power consumption or just increases the device’s running time
- Solar panels incorporated
- Increase number of data types collected
- Include pH monitoring
- Include dissolved oxygen monitoring
- Get it out on the water
- Make sure it navigates and collects data properly
- Organize the data collected in a meaningful and visually pleasing way
- Output data to a file readable by google earth to plot the data (.xml?)
Today I experimented with a separate relay board that I think I will attach to the boat. The board will bypass the electronics that came with the boat. So far, I have been able to control a motor with the board, and I understand how the relay board works now. Later, I will probably switch from a 4-channel board to a 2-channel board, because I only have 2 motors to control.
[motor relay control video]
Today I decided that for the first boat design, I would just put the electronics inside an RC boat, instead of building my own pontoon style boat. I took the case off the radio receiving unit, and tried to examine how the motors were controlled. The remote for the boat is nowhere to be found, but I don’t think that will be too much of a problem. I have made a drawing of what I think to be what the connections on the motor relays are, so that I know what to attach my own motor controller to.
Over the past week, I have been experimenting with a new GPS Library, TinyGPS++, that has some project-critical functions built in, such as waypoint distance. With a little futzing about with the code, I was able to get the new library to work with the hardware serial ports on the mega, in the same way the old library worked, and coded something that will sound a buzzer when within a certain distance of a waypoint. I feel that going forward, I will want to use this library for navigation, as opposed to the old Adafruit library.
Today I was able to transfer all of the functions of the latest Arduino Uno sketch and make them work flawlessly on the Mega. I have a lot more free memory now, so I will see if that enables me to run more functions without it breaking, like the Uno did.
Today I continued the move over from the Arduino Uno to the Mega. I have attached the GPS shield to the mega, jumped the necessary pins, made the needed code edits, and done the required library changes, so now all i have to do is see if it works, and the migration will be done.
Today I started trying to make the code I have written so far compatible with the Arduino Mega. From what I have read, I only have to change a couple lines of code, jump some connections, and maybe tweak the SD library just a tad. I am switching to the Mega because I am concerned the Uno is not powerful enough, or just doesn’t have enough resources to perform the tasks I want it to do.
Today I saved a new version of the main sketch. Version 1.06 now only asks the GPS module for $GPRMC data, and successfully logs temperature sensor data. It also only logs every 30th incoming GPS and temperature data pair, since an about 1Hz logging rate makes for very large files.
It seems as if the Arduino is placing limits on what I can command it to do, but i’m not sure where those exact bounds are. Next I will try to include electronic compass data in the main sketch, which I may not need to log.
Today I successfully was able to get temperature data to log to the SD card, and found out that the finding distance function doesn’t work and also breaks things when I try to use it with another thing I implemented that makes only every 30th gps string log.
Today I wrote some code for determining the arc length across the earth’s surface for two points of latitude an longitude, using mathematics from http://mathforum.org/library/drmath/view/51711.html
Although the curvature of the earth will not interfere heavily with an approximated distance calculation formula, this method allows me to be nearly as accurate as possible, and works well with the latitude/longitude system we use.
Also, the temperature sensor should write data to the SD card now. I haven’t tested that yet though.
And I still need to adjust the GPS data logging rate. 1 log per second is a bit too much it seems.
After entirely too long trying to figure out proper GPS string manipulation in order to continue with my project, and after countless lines of code written and re-written, in turns out that the data I was looking for can simply be accessed using a method of the GPS object created at the start of the program. Unbeknownst to me, if I wanted the current hour out of the received GPS data string, I had only needed to write, “GPS.hour”, the epic solution to the problem that plagued my project for weeks.
Also, I have been able to make the temperature sensor function properly, and test to see if it was properly calibrated. It was properly calibrated, and I will soon get the temperature data to log to the SD card as well.
-Testing the temperature sensor
I have sourced an old boogie board which I plan to cut up and shape into my first boat prototype. I will bring it to school either tomorrow or monday of the following week.
Today I touched base with Jack Szczpanski and made plans for the actual shape of the drone. We came up with a semi-final idea of a pontoon boat with all of the sensors, motors, and solar panels attached between the two pontoons. Later this week I plan to make a foam prototype and get at least the temperature sensor onboard.