UTD AUV Team - Status
Wednesday, June 30, 2010
More New Boards and Some Updates
¶ MichaelP @ 23:59, 0 comments
| We've been fairly busy, so here's a batch update on our new boards this year, as well as some miscellaneous information. | ||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||
Wednesday, October 14, 2009
Competition 2009 Results
¶ MichaelP @ 10:14, 0 comments
 | We got back from competition about 2 months ago, but I had been waiting for official scores to be posted. In any event, we placed fifth, behind Cornell (who finished every required objective, something extremely rare in this competition), University of Victoria, University of Rhode Island, and University of Central Florida. |
We each averaged about 2 hours of sleep in the first 5 nights, and it didn't get much better in the final night. We're still in the process of working out kinks in the new digital sonar board, something we spent most of our time on there, but we're hoping to have a new board revision done by the end of the calendar year. We had some success with vision tasks, including passing under the "barbed wire" a couple times (featured briefly in one of the 5-minute short videos, though AUVSI doesn't always manage to archive old content, so I won't link). The hydrophones were not placed optimally, although the bottom three were positioned similarly to prior years. We mounted seven, but only wound up trying to use a subset of them. | |
 | Pictured, left-to-right, are Rocky, Nathan, Chase, Michael, Carl, Kyle, and Chris. The grabber shown at the bottom was assembled in a couple hours (plus time for the adhesive to dry), and the front few were painted black so as to interfere with the vision less. Shown also are our two new VideoRay motors (to complement the 4 existing Seabotix motors) that increased our forward speed some, and our new Fischer bulkhead connectors. |
Tuesday, June 02, 2009
New Atmel Boards
¶ MichaelP @ 23:28, 0 comments
| We just finished testing our new small ATmega2560 boards: | |
 |  |
 | The communications are now done with USB, via an FT2232D, instead of the old RS-485 approach, and it is, of course, bus-powered. What's really novel, however, is that--with a good deal of extra software--we can reflash the chip in-system over the second interface on the FT2232, which saves us the trouble of opening the hull and risking leaks. This means we can try more experimental code. |
 | Of course, it wouldn't be complete without a really bright blue 30mcd LED, drawing 20mA straight off a microcontroller pin (and a few other less-visible LEDs). The board now takes up half the area of the old one, with 99 of the 100 AVR pins routed, and has some really slick 0.05" pitch Samtec headers (except the JTAG, which had to be standard). I'll try to post more once it's actually mounted on the tray. |
Wednesday, September 17, 2008
Success at Competition
Well, I was waiting for the final score breakdown to come out, but I think I'll go ahead and make a preliminary post. UT Dallas placed 2nd out of about 25 teams in 2008. U of Maryland took first, ETS took third, and U of Florida took fourth. After having done so poorly in 2007, we were looking forward to merely getting into the finals, but this was really a pleasant surprise. Our second-best ranking was in 2006, where we placed 5th out of a similar number of teams.
We surfaced almost every time we tried in the sonar region, and we never really missed it:
We had a few issues with backgrounding the client, and then not killing it before starting the next run, but we discovered those in time. This caused us to sort of appear to be stopped far away in at least one practice run. In another, I'm not sure if this was the cause, or it was something else, but it looked like it was getting pings from a bunch of places other than at the pinger (though not moving towards them, just turning).
We logged a ton of images this time, unlike the past two years, so we plan to get started on more image analysis type stuff this year. In fact, after the first couple days of practice, where we only had code to bring images into player and log them, we decided to write some stuff up to try to locate the bright orange buoy in the frame. We spent a lot of time messing with this on site and getting a homing algorithm working.
Once we determined that we were having some issues with darkening around the periphery of the frame, we started panning the vehicle around some to hunt for the buoy, and, just in case we missed after we went forward, we made a rectangular movement pattern afterward, just to be sure. We first tried this in the finals, and we not only hit it dead on, but we hit it a second time in that rectangular pattern. The buoy task probably added 3-4 minutes to the runtime, but it worked out in the end. Without the buoy task, we were typically taking 4:30 to 5 minutes to go from the dock to finish, grabbing the safe along the way.
I'll make another post when the scores come out. Also, here is the UTD news center story. We picked up a brief mention in Slashdot, too. ¶ MichaelP @ 12:40, 0 comments
We surfaced almost every time we tried in the sonar region, and we never really missed it:
 | This means surfacing at least 10 or so times during practice days, as well as in both qualifiers and in the finals. Our rate of grabbing the "safe" was closer to 80-90% of the times we surfaced. The passive grabber worked very well, but we were occasionally not quite centered enough, due to stochastic errors in the sonar processing board not averaging out sufficiently over sub movement. |
We had a few issues with backgrounding the client, and then not killing it before starting the next run, but we discovered those in time. This caused us to sort of appear to be stopped far away in at least one practice run. In another, I'm not sure if this was the cause, or it was something else, but it looked like it was getting pings from a bunch of places other than at the pinger (though not moving towards them, just turning).
We logged a ton of images this time, unlike the past two years, so we plan to get started on more image analysis type stuff this year. In fact, after the first couple days of practice, where we only had code to bring images into player and log them, we decided to write some stuff up to try to locate the bright orange buoy in the frame. We spent a lot of time messing with this on site and getting a homing algorithm working.
Once we determined that we were having some issues with darkening around the periphery of the frame, we started panning the vehicle around some to hunt for the buoy, and, just in case we missed after we went forward, we made a rectangular movement pattern afterward, just to be sure. We first tried this in the finals, and we not only hit it dead on, but we hit it a second time in that rectangular pattern. The buoy task probably added 3-4 minutes to the runtime, but it worked out in the end. Without the buoy task, we were typically taking 4:30 to 5 minutes to go from the dock to finish, grabbing the safe along the way.
I'll make another post when the scores come out. Also, here is the UTD news center story. We picked up a brief mention in Slashdot, too. ¶ MichaelP @ 12:40, 0 comments
Monday, July 28, 2008
sonar and grabbing successful
We've not been updating lately because we've been extremely busy, and it appears to have paid off. We have, for a couple weeks now, been homing on sonar and grabbing the safe successfully. These tests were completed entirely with sonar, as we lost our vision people, but we at least managed to log images using some great cameras we got from Datatoys last Fall.
Here are the videos. Note that some computers seem to have trouble showing them, so it may take a couple tries:
http://auv.utdallas.edu/gallery/main.php?g2_itemId=2573
If that exact link ever goes down, you can always just locate that album on the main gallery page:
http://auv.utdallas.edu/gallery/
Anyway, we're flying out to San Diego tomorrow, so we'll probably not be posting until we get back, but you can certainly watch the mailing list.
If anyone was trying to access the website in the last 24 hours or so, I apologize on behalf of whoever at the school decided it was wise to shut off electric power to the campus two days before competition!
¶ MichaelP @ 11:45, 0 comments
Here are the videos. Note that some computers seem to have trouble showing them, so it may take a couple tries:
http://auv.utdallas.edu/gallery/main.php?g2_itemId=2573
If that exact link ever goes down, you can always just locate that album on the main gallery page:
http://auv.utdallas.edu/gallery/
Anyway, we're flying out to San Diego tomorrow, so we'll probably not be posting until we get back, but you can certainly watch the mailing list.
Here's a picture of John and Michael tweaking one of our passive sonar boards.
If anyone was trying to access the website in the last 24 hours or so, I apologize on behalf of whoever at the school decided it was wise to shut off electric power to the campus two days before competition!
Finally, here's a picture inside the tube of the sub, though admittedly with the old tray; the new one is very similar, but with new boards on it, meaning less perfboard.
¶ MichaelP @ 11:45, 0 comments
Wednesday, June 11, 2008
New Boards
Well, the boards are starting to roll in, so I thought I'd provide a brief rundown on what's here so far. First up is the new relay board:
This board passes all the power in the sub, and is responsible for turning the sub on and off, as well as managing the competition-required kill switch for the motors. A number of improvements have been made, but the most important one is better protection for the AVR that reads the status of the switch, so we have fewer problems using it for the secondary function of starting the run while potentially disconnected. This is a step towards being slightly less reliant on a connection to start the sub: we may well get one shot at a run, instead of zero, even when we lack a decent wireless connection.
Next up is an interim sonar solution. It works reasonably well, but is targetted solely at 2008:
The two LEDs on top are power indicators, while the three arranged vertically each light briefly for a ping received on a particular hydrophone.
It is a signal conditioning board that allows relatively simple digital processing to measure time-difference of arrival. Finally, here's a shot of the bottom:
The boards were fabricated by Advanced Circuits, and were populated very rapidly by a great local company called CDS. We did modify a couple spots due to some design oversights, but it's turning out well overall. It's getting close to time to take these out to the pool now. ¶ MichaelP @ 17:05, 0 comments
This board passes all the power in the sub, and is responsible for turning the sub on and off, as well as managing the competition-required kill switch for the motors. A number of improvements have been made, but the most important one is better protection for the AVR that reads the status of the switch, so we have fewer problems using it for the secondary function of starting the run while potentially disconnected. This is a step towards being slightly less reliant on a connection to start the sub: we may well get one shot at a run, instead of zero, even when we lack a decent wireless connection.
Next up is an interim sonar solution. It works reasonably well, but is targetted solely at 2008:
The two LEDs on top are power indicators, while the three arranged vertically each light briefly for a ping received on a particular hydrophone.
It is a signal conditioning board that allows relatively simple digital processing to measure time-difference of arrival. Finally, here's a shot of the bottom:
The boards were fabricated by Advanced Circuits, and were populated very rapidly by a great local company called CDS. We did modify a couple spots due to some design oversights, but it's turning out well overall. It's getting close to time to take these out to the pool now. ¶ MichaelP @ 17:05, 0 comments
Monday, June 09, 2008
Gazebo
It's been a long while since an update, but we're alive. Really. Well, most of us are.
Anyhow, one thing that made significant progress last Fall was getting Gazebo up and running. It's a custom build of v0.5.2. Thanks again to CU Denver for the suggestion in 2005. Here's a screenshot, before I continue:
Shown in the picture is actually a default "world" packaged with Gazebo, but we've changed the model out to look/behave like our sub, down to the visual details of our hydrophones, Seabotix motors, and the aluminum framing. I unfortunately only have scale drawings of the center portion of the pool, which is not where we operate, so a more accurate environment is not in the foreseeable future.
The physics are something of a hack, since ODE lacked any sort of buoyancy calculations. It nevertheless seems to be qualitatively good, and therefore useful for testing out the clients. For that matter, the rendering of the water is somewhat silly, too, merely being alpha-blended billboards. Volumetric fogging would be the next step, but time is always short, so further updates will wait until the Fall.
There has not been time to add sonar support yet, but the main concern there right now is the robustness of the hardware, so, until that is nailed down, the simulator would have to remain very fluid. ¶ MichaelP @ 12:57, 0 comments
Anyhow, one thing that made significant progress last Fall was getting Gazebo up and running. It's a custom build of v0.5.2. Thanks again to CU Denver for the suggestion in 2005. Here's a screenshot, before I continue:
Shown in the picture is actually a default "world" packaged with Gazebo, but we've changed the model out to look/behave like our sub, down to the visual details of our hydrophones, Seabotix motors, and the aluminum framing. I unfortunately only have scale drawings of the center portion of the pool, which is not where we operate, so a more accurate environment is not in the foreseeable future.
The physics are something of a hack, since ODE lacked any sort of buoyancy calculations. It nevertheless seems to be qualitatively good, and therefore useful for testing out the clients. For that matter, the rendering of the water is somewhat silly, too, merely being alpha-blended billboards. Volumetric fogging would be the next step, but time is always short, so further updates will wait until the Fall.
There has not been time to add sonar support yet, but the main concern there right now is the robustness of the hardware, so, until that is nailed down, the simulator would have to remain very fluid. ¶ MichaelP @ 12:57, 0 comments
Tuesday, February 20, 2007
Finally some good work is getting done again...
Been a while since we have updated the news here. Rest assured, we have been diligently working to prepare for the 2007 AUVSI competition. The new boards for this years electronics suites are coming along quite nicely and should be in our hands and back from the board shop within the next few weeks.
Here are some renders of the newest additions to the AUV team arsenal. First is the FPGA board which will be utilized for sonar processing this year. It makes use of the Cyclone II FPGA for the design.
Next we have the ATMEGA2560 based micro-controller board, which will be our main controller for the AUV's other sensors, and sense-lines.
We should be getting these two designs back from the board shop soon and begin testing the designs out. ¶ Randy Rosales @ 22:57, 2 comments
Here are some renders of the newest additions to the AUV team arsenal. First is the FPGA board which will be utilized for sonar processing this year. It makes use of the Cyclone II FPGA for the design.
Next we have the ATMEGA2560 based micro-controller board, which will be our main controller for the AUV's other sensors, and sense-lines.
We should be getting these two designs back from the board shop soon and begin testing the designs out. ¶ Randy Rosales @ 22:57, 2 comments
Wednesday, November 15, 2006
Beginagain!
With the semester coming to an end, we need to start thinking about how all of our systems are going to physically be implemented within the constraints of a water-proof submersible.
To start this process it is neccessary to understand the feedback loop that occurs when planning such a vehicles layout.
Electronics determine system size -> system size determines hull shape and size -> hull shape and size places constraints on electronic system size...you get the idea.
These mechnical constraints were only solved by the prototyping boards insomuch as we use a mechanical connector that fits them and size the hull to fit them as well.
As many of you have seen, some designs fit on the prototyping board and some don't. In either case: when it comes to integrating these designs within the hull of our AUV, custom boards will be fabricated to optimize for space within the hull and allow for the specialized connections that will have to occur when running high power (motors, active sonar...etc) , along with the communication buses.
In light of these problems we are about to face, I propose we initiate peer design reviews. Each student will be responsible for completing a fully detailed schematic of their system. These schematics must detail exact parts, signals, and proposed mechanical connections. These schematics will then be reviewed by the rest of the team for soundness of design.
This peer review process will allow us to begin analyzing the big picture of how our electronics packages will all start to fit in the AUV hull. The problems we have will also surface when the overall picture is more clearly shown.
At the moment, we have the option of using last year's hull, improving on the existing hull, or creating an entirely new one. Decisions like these cannot be made on an individual basis and require the team to make a good decision.
In the next few weeks we will need to start having leadership meetings to discuss these topics and come to concrete decisions. Everyone will be invited to attend these meetings, and we will need to start making concrete decisions on topics such as hull design and mechanical layout of the electronics packages.
We all have a lot of work ahead of us. ¶ Randy Rosales @ 00:46, 0 comments
To start this process it is neccessary to understand the feedback loop that occurs when planning such a vehicles layout.
Electronics determine system size -> system size determines hull shape and size -> hull shape and size places constraints on electronic system size...you get the idea.
These mechnical constraints were only solved by the prototyping boards insomuch as we use a mechanical connector that fits them and size the hull to fit them as well.
As many of you have seen, some designs fit on the prototyping board and some don't. In either case: when it comes to integrating these designs within the hull of our AUV, custom boards will be fabricated to optimize for space within the hull and allow for the specialized connections that will have to occur when running high power (motors, active sonar...etc) , along with the communication buses.
In light of these problems we are about to face, I propose we initiate peer design reviews. Each student will be responsible for completing a fully detailed schematic of their system. These schematics must detail exact parts, signals, and proposed mechanical connections. These schematics will then be reviewed by the rest of the team for soundness of design.
This peer review process will allow us to begin analyzing the big picture of how our electronics packages will all start to fit in the AUV hull. The problems we have will also surface when the overall picture is more clearly shown.
At the moment, we have the option of using last year's hull, improving on the existing hull, or creating an entirely new one. Decisions like these cannot be made on an individual basis and require the team to make a good decision.
In the next few weeks we will need to start having leadership meetings to discuss these topics and come to concrete decisions. Everyone will be invited to attend these meetings, and we will need to start making concrete decisions on topics such as hull design and mechanical layout of the electronics packages.
We all have a lot of work ahead of us. ¶ Randy Rosales @ 00:46, 0 comments
Thursday, July 27, 2006
Camera fixed, Straight lines
I haven't gotten a whole lot of vision work done in the past couple of days, mostly because the camera's been producing bad output. We finally tracked it down to a corroded cable last night, and have replaced it with a new camera, hopefully with a better connector. The compass is still not behaving, but its output is looking a lot better. We can probably fix it by recalibrating it; if not, it is usable over about 3/4 of its range. Even without the compass, we can make it through the gate on the IMU alone (and maybe hit the docking station). Time to go down to the pool and get this vision thing done.
¶ kd5bjo @ 11:34, 0 comments
Tuesday, July 25, 2006
Vision, Sonar, and Compass
Sunday night, I swam laps with the sub for about an hour, and it only ever lost the line three times. Whenever it did that, though, it always picked up the adjacent one successfully. At the same time, Wes and Ian were unsuccessfully fighting with the sonar boards trying to read the time differential between two channels. Once they get that worked out, it looks like the sonar will be working properly.
The compass has also started reporting bad values, and we haven't been able to fix it yet. If the values were consistent, then we could probably use the compass, but at reduced effectiveness. The compass seems to have several different transfer functions and there is no way for us to know which one it is using this time. We also don't know if the problem is the compass reporting the value incorrectly or the AVR reading it incorrectly.
I was at the pool for about three hours yesterday, and discovered that the handheld PC that was loaned to us doesn't have a daylight-readable display, so it is mostly useless in the Texas sun. In the evenings, however, it is quite invaluable. I did some work on the compass yesterday, and it seems to be better. Unfortunately, that does not necessarily mean "useful". I also had trouble getting the vision system to recognize the test bins, but I believe that is because the pool is so shallow that it could never get the entire bin in frame at the same time.
Today's adgenda (for me) at the pool is:
I probably won't get all of this done today, but I will try. Once all of these steps happen, the vision system will be completely working, and we will be able to make it through the validation gate (and hopefully hit the docking station in the process). It also sounds like sonar is coming along nicely, so we should have a real contender here in a few days. Now the real question is whether "a few days" is before or after the competition. ¶ kd5bjo @ 12:02, 0 comments
The compass has also started reporting bad values, and we haven't been able to fix it yet. If the values were consistent, then we could probably use the compass, but at reduced effectiveness. The compass seems to have several different transfer functions and there is no way for us to know which one it is using this time. We also don't know if the problem is the compass reporting the value incorrectly or the AVR reading it incorrectly.
I was at the pool for about three hours yesterday, and discovered that the handheld PC that was loaned to us doesn't have a daylight-readable display, so it is mostly useless in the Texas sun. In the evenings, however, it is quite invaluable. I did some work on the compass yesterday, and it seems to be better. Unfortunately, that does not necessarily mean "useful". I also had trouble getting the vision system to recognize the test bins, but I believe that is because the pool is so shallow that it could never get the entire bin in frame at the same time.
Today's adgenda (for me) at the pool is:
- Get the sub travelling straight by any means necessary. This probably means using the IMU's rate gyro to control our yaw speed to 0, independent of our heading.
- Train the vision system on our test course elements in daylight. See how long it takes and how dificult it is with a washed-out screen.
- Follow the orange pipe. This should just work, but it will be the first time the sub has followed a non-straight line.
- Identify a bin in the camera frame. If necessary, use a surrogate bin that is a smaller target due to the shallowness of the pool.
- Get the bin-seeking control system working.
- Follow the orange pipe to a bin and stop at the bin instead of continuing along the line.
- When sufficiently centered over a bin, dive to the bottom, remaining centered over the bin.
- Drop markers on the bin.
- Automatically abort the vision system when we have no more markers to drop.
I probably won't get all of this done today, but I will try. Once all of these steps happen, the vision system will be completely working, and we will be able to make it through the validation gate (and hopefully hit the docking station in the process). It also sounds like sonar is coming along nicely, so we should have a real contender here in a few days. Now the real question is whether "a few days" is before or after the competition. ¶ kd5bjo @ 12:02, 0 comments
Sunday, July 23, 2006
Hectic Week
I'm sorry that I haven't posted something up here for a week, but we've all been running to get problems fixed. As I was doing that, Wes was testing the new faceplace for leaks, of which it had plenty. It took us several days to find and fix all of them. At some point, the computer decided to stop working. We still have no idea why, but something failed and it doesn't power up anymore. We put our replacement board in, and everything worked great, in the lab. Once we got all of the leaks worked out, we put the electronics back in, and the computer refused to stay up for more than 10 minutes. We didn't get that figured out until Friday night, when we did a successful depth control run.
Yesterday, we didn't get into the pool, but we did get a lot of work done. We fixed the camera cable (which still needs to be tested); we installed the kill switch; we got the marker dropper working; we fried a servo; we fixed a communications problem between the sub and the buoy; we got the hydrophones mounted to the sub. Today, we need to verify all of that, and do something that looks a little like a mission run. ¶ kd5bjo @ 10:36, 0 comments
Yesterday, we didn't get into the pool, but we did get a lot of work done. We fixed the camera cable (which still needs to be tested); we installed the kill switch; we got the marker dropper working; we fried a servo; we fixed a communications problem between the sub and the buoy; we got the hydrophones mounted to the sub. Today, we need to verify all of that, and do something that looks a little like a mission run. ¶ kd5bjo @ 10:36, 0 comments
Saturday, July 15, 2006
Computer recovery
Thursday evening, I discovered that the harddrive in the vehicle had died. Because of the uncertain history of the old drive, we already had a replacement drive on order; it should arrive early next week. Until then, we will be operating off of a spare that I had for a separate project.
I have spent all of today installing Gentoo on the new drive, and I intend to save a drive image as soon as everything works properly. We have restored all of the old functionality except for image capture. I am currently trying to get the capture software installed without stooping to installing X, but I will if I have to.
UPDATE: I have gotten the cameras to work; I will reboot the computer so that it's running off of wall power and grab a filesystem image so we don't ever have to go through this again.
While I try and get the computer sorted out, Wes, Danny, and a few others have taken the hull to make some final modifications (such as adding a kill switch). I took care of the depth sensor and Ethernet connection problems yesterday. Hopefully, we'll be back in the water tomorrow evening doing some testing. I will be back in the morning to do some finalization of the vision stuff. ¶ kd5bjo @ 03:01, 0 comments
I have spent all of today installing Gentoo on the new drive, and I intend to save a drive image as soon as everything works properly. We have restored all of the old functionality except for image capture. I am currently trying to get the capture software installed without stooping to installing X, but I will if I have to.
UPDATE: I have gotten the cameras to work; I will reboot the computer so that it's running off of wall power and grab a filesystem image so we don't ever have to go through this again.
While I try and get the computer sorted out, Wes, Danny, and a few others have taken the hull to make some final modifications (such as adding a kill switch). I took care of the depth sensor and Ethernet connection problems yesterday. Hopefully, we'll be back in the water tomorrow evening doing some testing. I will be back in the morning to do some finalization of the vision stuff. ¶ kd5bjo @ 03:01, 0 comments
Thursday, July 13, 2006
DPRG Picnic
Sorry for the lack of posts recently. We were all busy getting stuff ready for the DPRG picnic last Saturday, and I didn't have time to stop and write down what was done. On Friday night, the sub followed the swimlane stripe on the bottom of the Waterview pool perfectly. Various other things were tested, and Wes worked on sonar into the night.
Saturday morning, we packed everything up and headed to the picnic.Unlike previous years, we had the sub running in the pool within 15 minutes of arriving. There were no leakage problems, but the Texas sun limited our runtime to only an hour before things shut down because of being overheated. We took the sub into John's house, and opened up the tube to let it air out while we ate lunch. There were no heat problems for the remainder of the day, probably because it became overcast.
I practiced and demonstrated onsite vision system training, and got satisfactory results off of as few as three images. Several hours later, the vision system showed no signs of breaking down, despite changing lighting conditions. The actual camera is rotated inside its watertight enclosure, so it doesn't line up orthogonally with the vehicle frame when properly secured. I need to add a calibration parameter to the vision system to correct for this.
The sonar guys were trying to track down a glitch in the firmware all day with little success. I understand that since then, they have found and corrected the problem. In the late afternoon, the PIC programmer stopped working, and they retreated to the lab to get things going again.
I have been taking a break after the hecticness, and started working again yesterday by documenting the vision system for the paper and website. Most of the mechanical changes have been made, and we should be back in the water today. ¶ kd5bjo @ 13:50, 0 comments
Saturday morning, we packed everything up and headed to the picnic.Unlike previous years, we had the sub running in the pool within 15 minutes of arriving. There were no leakage problems, but the Texas sun limited our runtime to only an hour before things shut down because of being overheated. We took the sub into John's house, and opened up the tube to let it air out while we ate lunch. There were no heat problems for the remainder of the day, probably because it became overcast.
I practiced and demonstrated onsite vision system training, and got satisfactory results off of as few as three images. Several hours later, the vision system showed no signs of breaking down, despite changing lighting conditions. The actual camera is rotated inside its watertight enclosure, so it doesn't line up orthogonally with the vehicle frame when properly secured. I need to add a calibration parameter to the vision system to correct for this.
The sonar guys were trying to track down a glitch in the firmware all day with little success. I understand that since then, they have found and corrected the problem. In the late afternoon, the PIC programmer stopped working, and they retreated to the lab to get things going again.
I have been taking a break after the hecticness, and started working again yesterday by documenting the vision system for the paper and website. Most of the mechanical changes have been made, and we should be back in the water today. ¶ kd5bjo @ 13:50, 0 comments
Thursday, July 06, 2006
Vision Update
We got some good data in the pool yesterday, and I spent today getting the vision system controlling the motors. Tomorrow, I will try to do a complete end-to-end test in the lab with a dummy target, and then it'll be time to test the control systems in the pool. Vision looks to be on schedule, and barring any major catastrophe, should be operational to the point that it can actually score us points by the end of next week.
¶ kd5bjo @ 17:31, 0 comments
Wednesday, July 05, 2006
Water tests
Late yesterday morning, Wes and I took the hull down to the pool for some final leak tests. When we got back up to the lab, Michael was there working with the compass AVR code. The three of us worked most of the day fitting the electronics into the sub and getting everything working. (Side note: DMMs with low batteries read voltages higher than reality). We picked up a few things at Fry's to complete the last few connections, and spent another hour or two debugging problems with the wireless Ethernet equipment and power circuitry. Collin also showed up and got the light detectors working.
At around 21:30, we took the AUV down to the pool for a live power test. Full of electronics and batteries, it was heavy enough to sink until we removed 10 pounds of dead weight that had been attached to the frame. We were also still having some wireless connectivity issues. After about 15 minutes, we squashed the communications bug and put the sub in the water to test the systems. It maneuvers quite well around the pool, and will basically go straight on its own (open loop) if there aren't any significant currents in the water. After an hour of runtime, we pulled the AUV out of the water and took it back up to the lab.
The weight seems about right; the vertical motors can drive the sub underwater without a lot of effort. Most of this test was on the surface, but we did also perform some underwater maneuvering. After the test, the drive motor battery reported a 3/4 charge and the dive motor battery reported a 4/4 charge. The computer and logic battery reported a 2/4 charge, but it was powering the AUV for an hour and twenty minutes instead of simply the hour that the motors were running. All in all, it appears that our runtime for tests will be somewhere between 1.5 and 2 hours. ¶ kd5bjo @ 02:18, 0 comments
At around 21:30, we took the AUV down to the pool for a live power test. Full of electronics and batteries, it was heavy enough to sink until we removed 10 pounds of dead weight that had been attached to the frame. We were also still having some wireless connectivity issues. After about 15 minutes, we squashed the communications bug and put the sub in the water to test the systems. It maneuvers quite well around the pool, and will basically go straight on its own (open loop) if there aren't any significant currents in the water. After an hour of runtime, we pulled the AUV out of the water and took it back up to the lab.
The weight seems about right; the vertical motors can drive the sub underwater without a lot of effort. Most of this test was on the surface, but we did also perform some underwater maneuvering. After the test, the drive motor battery reported a 3/4 charge and the dive motor battery reported a 4/4 charge. The computer and logic battery reported a 2/4 charge, but it was powering the AUV for an hour and twenty minutes instead of simply the hour that the motors were running. All in all, it appears that our runtime for tests will be somewhere between 1.5 and 2 hours. ¶ kd5bjo @ 02:18, 0 comments
Tuesday, July 04, 2006
Compass, Player, Sonar,
Things are really coming together now. Most of the pieces work, and I think we'll actually get this thing in the water today. Michael got the compass reporting values, Wes and Ian got the DAC on the sonar board working, Collin has successfully detected light color and frequency, and I got most of the interior wiring done.
Today's agenda (for me, at least) is to get the computer on the sub back up, and talking to everything. Then, get this thing in the water. ¶ kd5bjo @ 11:48, 0 comments
Today's agenda (for me, at least) is to get the computer on the sub back up, and talking to everything. Then, get this thing in the water. ¶ kd5bjo @ 11:48, 0 comments
Monday, July 03, 2006
Compass
I managed to get the compass attached to the i2c bus without causing the AVR to hang, but I couldn't read the compass without the RS-485 protocol timing out. I attached the compass via the PWM signal, but have not been able to get satisfactory results. The theoretical resolution of the compass as it is currently configured is 2.7 degrees. This change also seems to have broken the motor controller status notification on boot; the motor controller still works fine. I haven't checked in any of the new code, because it still works less well than what's in the repository.
¶ kd5bjo @ 03:21, 0 comments
Sunday, July 02, 2006
Leaks, Motors, News
After a few minor fixes, the hull appears to be watertight again, as it didn't leak after a 1 hour test. Michael and I dubugged the RS-485 bus, which is now working between the testing PC and the AVR. We have successfully controlled the motors with the computer, and I seem to have stamped out the i2c bug (I hope). I am currently trying to get the compass working on the same bus as the motor controllers, which will probably take the rest of the night. Also, I got this news feed integrated into the front page of auv.utdallas.edu, the official website.
¶ kd5bjo @ 22:44, 0 comments
Lots of progress
Lots of work got done yesterday. I got the vision system mostly set up; it is generating values suitable to be fed into a control system for both pipeline recognition and bon detection. Pretty much all of the AVR code is written, but untested. The electronics are wired together on the plate that goes inside the sub, but there are some bugs that still need to be worked out. The sonar system seems to be going well, but I don't know any specifics on that. The hull got tested with various connectors on the bulkhead, and leaked a few mL of water over twenty minutes. Mike thinks he's isolated the problem, and we will be testing again today.
¶ kd5bjo @ 13:15, 0 comments
Saturday, July 01, 2006
Vision Update
Edge-detect no longer crashes on certain source images. The bug in edge-detect is a reference-tracking issue. Not wanting to debug the massive decision tree that produces the output, I have replaced all of the nontrivial memory management with the Boehm garbage collector. This doesn't solve the problem of the output being poor in edge cases, but it does keep the program from crashing on images it doesn't like, while still maintaining sufficient speed to run inside the vision pipeline.
For the record, attempting to mass free everything yourself using brk causes a segmentation fault. Ignoring free and execing the program after every frame works, but is too slow to be practical in a real-time problem, such as vision.
The new vision code will be in svn as soon as I can move the changes to a clean copy of the source from the one with all of the cruft from trying to deal with this problem. ¶ kd5bjo @ 09:19, 0 comments
For the record, attempting to mass free everything yourself using brk causes a segmentation fault. Ignoring free and execing the program after every frame works, but is too slow to be practical in a real-time problem, such as vision.
The new vision code will be in svn as soon as I can move the changes to a clean copy of the source from the one with all of the cruft from trying to deal with this problem. ¶ kd5bjo @ 09:19, 0 comments
Fwd: AVR Progress
From Michael, yesterday morning. I understand that he's was working on this most of yesterday, too; I don't know how far along he is right now.
(When I say "I", I've had a lot of assistance from Randy, Ed, and Solomon.)
I've implemented some stuff in the last 24 hours (nothing has been tested,
but it compiles) :
implemented for comms) :
(When I say "I", I've had a lot of assistance from Randy, Ed, and Solomon.)
I've implemented some stuff in the last 24 hours (nothing has been tested,
but it compiles) :
- RS-485 and STX/ETX
- motor control
- depth sense
- battery voltage sense
- a2d that is nonblocking (unlike the avrlib stuff)
implemented for comms) :
- marker dropper
- compass
- kill switch reading
- power control over camera bus
- device presence
- kill relay (???)
Friday, June 30, 2006
Some Background
For those of you who happen to stumble across this site without a proper introduction, perhaps I should let you know what this whole thing is about.
I am one of the senior members of the AUV team at the University of Texas at Dallas. We are preparing an entry for AUVSI's 9th International Autonomous Underwater Vehicle Competition. Fundamentally, we have to make a robotic submarine that performs several tasks underwater completely without human interaction. I will try to explain the various bits we need to do as I talk about the state of the various systems that try to accomplish each task. If you don't want to wait for that, you can read the official mission. ¶ kd5bjo @ 13:56, 0 comments
I am one of the senior members of the AUV team at the University of Texas at Dallas. We are preparing an entry for AUVSI's 9th International Autonomous Underwater Vehicle Competition. Fundamentally, we have to make a robotic submarine that performs several tasks underwater completely without human interaction. I will try to explain the various bits we need to do as I talk about the state of the various systems that try to accomplish each task. If you don't want to wait for that, you can read the official mission. ¶ kd5bjo @ 13:56, 0 comments
Welcome
With only a month to go before the competition, I am getting regular inquiries about the progress of the AUV. Rather than having to repeat myself all the time, I will try to post status updates here as often as I can. Our original plan was to have all of the hardware working by July 1. That seems to be unlikely to happen, but we should at least be in the water.
¶ kd5bjo @ 13:19, 0 comments
