This is The Typewriter Repairmen's page for the 2012 National Underwater Robotics Challenge, a competition put on by Arizona Promoters of Applied Science in Education in Chandler, AZ.
The Typewriter Repairmen is a family robotics club. Jim, the Principal Instigator, is a "retired" mechanical engineer. He has worked with the local FIRST high school robotics team NERDS for the past four seasons as an engineering mentor, and discovered that it's about the most fun thing there is. Janet, his wife, has a Masters degree in Systems Engineering, and works at Ft. Huachuca. Jim's brother David is an Electrical Engineer at the University of Arizona's Steward Observatory, and also runs a side business Cathode Corner, which sells neat electronic gadgets. Jim and Janet's son Steve, who is nuts about robots, is also a mechanical engineer.
Link to the 2009 NURC robot notBob
Link to the 2010 NURC robot Babs
All through the project we have been posting videos on youtube.
Contact us at jforb427@gmail.com
June 2, 2012
Kevin spent several hours programming and debugging today. He had a problem with how the sockets handle data as FIFO, so he had to write a routine to purge the numbers so it would get the latest data. He wrote the software that parses the mission text file, and makes it control the robot. So far the heading and depth control functions work, as well as timed driving. We put Biff in the pool next door, and got him to maintain heading and depth as he drove for 10 seconds. We think that's quite an accomplishment.
See the video!
June 1, 2012
Gary and Kevin brought the robot down to Sierra Vista to play with it. David installed the compass in a raised housing, added a mission on/off reed switch, a front light, and a few other things. Kevin has been programming and has most of the basic stuff done so we can start working on the actual mission program.
We also sort of finished the technical report, but we found out we don't really need to do it since we're doign the autonomous portion of the NURC.
You can read the report here
May 29, 2012
The Tucson folks have been working on the programming more, and got the motors to turn under computer control. Yay! Also they tried the tether trick, and it works. So now we have an ROV. Next: making it autonomous.
The tether is just a piece of coax, which helps the WiFi signal get from the laptop's router, down to the robot's computer under the water. There is no direct connection, it works like having two antennas connected by a wire. These two antennas are placed near the antennas that need to talk to each other.
One problem they noticed is that the compartments leak water a little bit. I suggested a fix, which is to replace the springs holding the compartments closed, with nuts. Then we can apply sufficient force to seal the O rings.
They also got some video!
May 24, 2012
The Tucson folks have been working on the programming, and also wired up the compass. Word is that the computer can see the sensors, but is not yet driving the motors.
May 23, 2012
David has been working on the electronics, he made a perfboard mount and breakout board for the Arduino. Also Steve did some more work on the SolidWorks CAD model of the robot, including adding photos of some of the parts to make it look more realistic.
May 21, 2012
We finished the power wiring, and tried the computer running off battery power. It works! We connected a monitor and keyboard and mouse to the computer when it was installed in the robot, and captured a few images using the camera which was also mounted in the robot. Then we closed the enclosures, and gave it a floating test. The little robot gained a lot of weight! After removing all the ballast from the bottom, the right rear corner still sank. We removed the "dummy" battery we had made to take the place of the third battery, and we were able to get it to float level by adding some weight to the opposite corner. We decided to make a battery spacer, to move the batteries as far forward and to the left as possible, and this did the trick, we were able to balance the robot with about one Kg of ballast.
We are done working on it for now, Steve will drop it off in Tucson so David can finish the Arduino wiring, and Kevin can get to work programming. We may still need to add more flotation above the top of the robot, and more ballast to the bottom, to make it stable enough to work. We don't know how the compass will work being in the front electronics enclosure, we might need to put it further away from the motors and stuff. But for now we have what should be a useable robot.
May 20, 2012
Steve and I worked on the front housing today. We got the computer mount made, installed the pressure sensor that David put together, mounted one camera on the bracket that Kevin made yesterday. We installed the terminal strip and the inter-compartment cable. We did not get to the wiring yet. We also figured out how to wire the Arduino board, but we may leave it for David and Kevin to finish.
May 19, 2012
Finally got some more work done on the little robot. I made a plate to mount the speed controller board, and a tray to hold the batteries. I also figured out how to mount a power switch, so it can be operated from outside, with a large "push off" knob. Kevin and Steven visited this weekend, and we worked out a design to mount the computer, but haven't built the parts yet. We also have a plan to mount the cameras, and some ideas for the arduino and the wiring. We wired the motors and power supply to the speed controller, and tried it using a tethered vEx transmitter. It works! the motors spin.
May 5, 2012
Happy Birthday! I performed another pool test, the robot has ballast and sinks slowly, and doesn't leak. I made the propeller shafts, they're a bit shorter than previous ones. Something about motors hitting frame. The rest of the motors are ordered. I also took a few more pictures. We are working on the electronics mounting, first we need to finalize what stuff needs to be there, and how it will all be connected.
May 3, 2012
Today I finished the mounting for the other enclosure. We will probably get some different springs to play with to see how much closing force we can apply to the enclosures, and still make it possible to manipulate the latch. I also looked through the spare parts box, and found three extra propellers from Babs. There were two forward, and one reverse. Since the jig was last used to make reverse propellers, I made another one, so we have two of each. The blades are cut from sheet brass, and silver soldered to the brass nut in the jig. It's a pretty simple design. I also made some weights for the bottom of the robot, one each to go across the front and back just under the enclosures, and one for each side to go just above the skids. I also made two half length weights, and I'll probably make two each quarter and eighth to help make it easier to balance the robot as we add components.
May 2, 2012
FRC robots are over for the year. We've worked on a few things since the last update. The AUV frame is built, the electronics compartments are both built, and we have more ideas about software. But we still don't have a robot!
We built the frame from welded steel strap, as we have the past two ROVs we made. We made the enclosures using 1/2" thick aluminum plate, cut to size with a bandsaw, and turned in the lathe. They also use 6" diameter, 1/8" wall polycarbonate tube. This time we are trying something new for the enclosures, one end has a "plug" like we used on the ROVs, but the other end has a "cap". This design requires spring pressure to hold the cap in place, and also requires a smooth, flat finish on the end of the tube, since there is not much force holding it together. We had to lap the end of the tubes to give a good seal.
Kevin says: I started thinking about how the mission should be run. I attached a pair of files as an example on a possible implementation of it.
On the robot end, everything will be programmed in python, since it is fast, interpreted, modular, and extensive. The next question is how we can start getting to work. Thad (attached email) actually expressed interest in the gui, so I will draft some basic requirements for that and hand the project over to him in the next few days. That leaves 4 main tasks: main thread, mission control, robot interaction, and camera. The main thread will do all the communication between driver and robot as well as control the basic systems (start/stop mission) on robot. Control will parse mission control file and run it accordingly. Camera will snap images and apply desired filters to them. Interaction will talk to Arduino and move motors/return sensor information.
I wanted to keep the mission control as abstract as possible. It should store mission control information in files which it then parses and runs. See attachments for possible system. This will make it possible to not only define the larger mission tasks, but to also define how it moves around and stores information, which could prove to be useful.
Kevin also worked up a schedule for completing the software:
The competition is on June 8th-10th. That gives us 5 weeks from today. Unfortunately, we need to test the mechanical/electrical systems while programming, which makes testing the program a bit difficult. I suppose we need to finish the mechanical parts as fast as possible, create a simple program for driving out of the way, and test all mechanical systems in the next two weeks. Then we can focus on the hard part... Proposed Timeline: 5/5/2012 (Saturday): Final robot plans drafted 5/11/2012 (Friday): Mechanical assemblies finished 5/18/2012 (Friday): Electrical assemblies finished/installed 5/21/2012 (Monday): Robot driving under human control 5/25/2012 (Friday): GUI, main thread, basic camera, and Arduino interface thread complete 5/30/2012 (Wednesday): Mission parser, simple mission files finished/tested, camera filters complete 6/4/2012 (Monday): Mission complete, fix assorted bugs 6/7/2012 (Thursday): Extensive pool testing complete, ready for competition 6/8/2012 (Friday): Competition Feel free to add anything you want or shift dates, we should have this timeline completed by Saturday (along with other robot stuff). I have a repository set up on bitbucket.org, so I'll also include information on using that. Can people tell me what parts of the program they'd like to work on? There is mission definition (previous email), mission parser, main thread, vision processing, GUI, and Arduino interface. Thad has expressed interest in the GUI, we just ate lunch with Steven and he's okay with determining the requirements and organization of the vision processing thread.
January 24, 2012
We've been pretty involved with FRC, Gary and Kevin are helping the Bit Buckets, Steve is helping the Falcons, and Jim is helping the NERDS. We got the fitPC and played with it some, installed modern versions of Mint and Ubuntu on it.
Kevin spent some time thinking about the control system, and came up with this plan.
Browser: View camera feeds View sensor and actuator data View logs View mission order View tasks View processing tasks Control actuators Control logs Control mission order Control tasks Control processing tasks Control AUV power Notes: Should use javascript for most functions and have a method of authentication, since the server will be broadcast wirelessly. Has implementation for starting and stopping various threads and tasks. Can reboot system from here, probably upload new code, since python is interpreted. Interface Thread: Uses Pico to allow javascript to call functions Getter functions return information from main thread Setter functions relay information to main thread Notes: Simply passes information from the client side to the main thread. Client side retrieves information by requesting it, so interface thread needs to be able to grab information from the main thread and keep it updated. Should start on completion of loading the OS. Main Thread: Logs information Parent to other threads Can create and kill other threads Relay between threads Notes: Main thread should be relatively small and simply control the flow of information between the interface, camera, external functions, and decision making threads. The main thread should open on completion of loading the OS. OpenCV Thread: Collects camera images Applies various filters to images Calculates various attributes of filtered images Returns filtered images Returns attributes of images Notes: Just a wrapper thread for openCV. This is where most of the heavy computing comes from, so this thread should have a relatively high priority. Decision Thread: Starts mission Collects information from sensors and cameras Constructs world view from information Contains list of mission tasks Can start, stop, and pause missions Contains control loops or encapsulates them Notes: When the user enables the decision thread, it should take over control of the AUV until the user disables it via browser. An onboard switch should start/stop the mission. Communicates intentions to external function thread via main thread. External Functions Thread: Initializes and communicates to hardware Retrieves sensor information Applies filters to incoming sensor information (Kalman?) Controls actuators Stores actuator states Notes: Hardware interface thread, does anything it is told to do by main thread. Possibly contains control loops instead of Decision thread.
January 1, 2012
Happy New Year!
More work on the AUV design. We think we've figured out the design for the enclosures, they will mounted with springs holding them closed, and a simple strap securing the removeable end. We have a preliminary design for the mounting system for the electronics and batteries. The computer shoudl be here in a few days, and we have the materials to make the new enclosures. We still need to order the motors, and get to work in the shop building this stuff!
December 23, 2011
Since it's holiday season, we can get together to work on the AUV design. After thinking about trying to use notBob, we decided that we would be better off with a whole new robot.
This is the first draft. We plan to use four thrusters, a steel strap frame, two enclosures, a fit PC2i, several lipo batteries, and the Cathode Corner ESC4a four channel motor speed controller. The computer, cameras, pressure sensor, and one battery will be in the front compartment, while the speed controller and remaining batteries will be in the rear compartment. The two will be connected with a single serial line to send the computer commanded drive signals to the speed controller. This reduces wiring complexity, and allows us to add a kill switch to completely disable the drive system, while leaving the computer powered. The compartments will be made with a revised design compared to our previous ROVs, so that the tube and one end cap can be quickly removed for battery changes and other maintenance.
November 27, 2011
We're starting to figure out what we're going to do for NURC this year. There is something new, the autonomous competition. Steve, Gary, and Jim went to the RoboSub Autonomous Underwater Vehicle competition to watch last July. The Carl Hayden team was competing for the first time, and we wanted to see what it was all about, and cheer them on. It looks like a really good challenge, and it's great to see that the NURC this year includes an AUV element. We spent some time on Thanksgiving day discussing it, and we've decided that we want to give it a try.
We have done some preliminary requirements analysis, and we think that we should start by trying to make an AUV that will be able to maintain a controlled depth, maintain a controlled direction of travel, and have vision ability to both see markers on the floor of the pool, and buoys ahead.
Our initial plan is to play with notBob, because he has most of the stuff we need to get started. He is kind of heavy and slow and stable, and has room for two cameras in a housing that can see ahead and down. We can replace his rear floatation units with a single second SKULL, which will hold a computer and batteries. David has several 11.1v 5 Ah LIPO battery packs from another project. We are investigating some different small computers, with a size limit of fitting in a 6" polycarbonate tube.
Kevin has been learning about the basics of arificial intelligence. "....the same AI lab from University of Michigan also made a Procedural Reasoning System in C++. A PRS is a type of Belief-Desire-Intent agent that stores facts or beliefs about the external world in a database. The user adds knowledge areas that lay out procedures on how to react to certain inputs, and the system decides at runtime what knowledge areas to apply to a situation depending on information it gets from the external world. The best part is UMPRS is surprisingly small and well documented.