Team Five/Journal
From Maslab 2007
| Maslab teams |
|---|
| Team 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 · 9 · 10 · 11 · 12 · 13 · 14 · 15 · 16 · 17 · 18 |
| Team Five’s Journal |
Day 1: Monday, January 8th
We built a robot! From here, we will relax for the rest of IAP, only making minor tweaks to our already awesome robot.
Anyway, the robot drives forward and prints messages. Sam mounted everything on the Pegbot, and we have already made modifications to the case. Specifically, you can't connect any of the external inputs (like VGA monitor) because the stock case gets in the way. A few minutes with the tin snips fixed that. We'll be back tomorrow to make our robot dimly aware of the external world. ~TR
Day 2: Tuesday, January 9th
In the lab
Wrote an IR test and a gyro test. Unfortunately, our battery is now dead, and the chargers are not due to arrive for another hour and a half. Hence the journal update. For now, I'm going to assume everything works perfectly.
Sam began to take measurements of the components and draw them up in SolidWorks. ~TR
9:00PM
We have power. I'm dorking around with the gyro, and if you give it a scale factor of 1.55, it seems to work pretty nicely. I'll give a longer test later. In a related story, I've decided that this is not a journal, it is a lab notebook. Which is probably the point, but I'm a little slow. ~TR
11:00PM
Discussed mechanical design and how the design will depend on the strategy (will we try to score goals or just collect balls?). Decided to build a system that will be conducive both to storing a large number of balls AND allow us to create a shooting mechanism in the future. Sam continued to measure and CADify while TR and Ben discussed how to CODEify the robot.
Day 3: Wednesday, January 10th
Late Evening
We have to do WHAT by tomorrow? Also, I spent most of my evening fighting with java, but once I had figured that out, writing a proportional wall-following program using 1 IR sensor was pretty easy. PD control doesn't seem to help, but I'm going to bed. I'll do more thorough test on that with the gyro. ~TR
Day 4: Thursday, January 11th
7:00 AM
Ben goes to bed after writing red ball finding code.
3:00 PM
After lecture, we dorked around with linking together the ball-finding code and charging code. Some success was had, after we discovered that Ben was using computer coordinates and TR was using mathematical coordinates. Everybody is still using the gyro's nautical version of angle. Checkoff 1 acheived!
Careers at NASA lie ahead for all of us. ~TR
Day 7, Sunday, January 13th
Afternoon
My computer is in total rebellion. I cannot get to the CVS repository, or even SSH to Ben's computer. The robot hates me, and it won't let me build. Even my external hard drives have stopped talking to my computer, and my keyboard and mouse won't work like they normally do. On the plus side, I figured out how threads work, and, in spite of the fact that the botClient is outputting everything on a single channel, it seems to work well.
The robot then ran headlong into a wall, dislodging the wireless card. I suppose that's about it for tonight, then.
Day 8, Monday, January 14th
3:00 PM
Woo hoo! Johnny5 wall follows, using the bump sensors when it screws up to fix itself. For now, there is no escape mechanism for when it's trying to get away from a wall and hits another wall, so that might be a good direction to go in for now. I tried to do this with thread, with little success. I have the basic idea, but it's toally not functions.
Johnny humped another robot. We'll learn about how to deal with the babies during tomorrow's swarming lecture.
Day 9, Tuesday, January 15th
6:00 PM
Team meetingage occurred, and many things were discussed. Mostly, we poked about with the mechanical design, and for now, we've scrapped a complicated robot. The idea will be to build a pretty functional robot, but with only the capacity to store 4 balls at once. We'll try to put sensors below to figure out how many balls we have (probably 4 short-range IR), and from there, we'll be able to decide whether to score or not. We also decided that going for balls against the wall is a bad idea, so the code will ignore that.
We've also figured out a bunch of interesting things about the camera. First, we added an extremely complicated Fourier analog low-pass filter to the camera, and Ben built a brilliant interface for tuning the cutoff frequency. It can be accessed by turning the focus knob on the camera. Second, we decided to put the camera at exactly wall height, because Ben doesn't want to do blue-line filtering. This will also get us a decent estimate on ball distance, but it means we can't see less than 14 inches ahead of us. From there, we'll probably just trust to dead reckoning, or maybe optical encoders to travel forward.
Plans for tonight: TR: fix all the broken threads (they all die for no reason, leaving Johnny blind and quivering), Ben, make the camera less stupid and less complicated, and Sam, start to built Johnny5 2. We might go to lab in a bit, but for us code monkeys, the monitors are bigger here. ~TR
8:00 PM
I uploaded my resume. My teammates are slackers. ~TR
10:00 PM
Well, after getting thoroughly stumped as to why my code randomly crashes, I decided to take Johnny into lab and actually figure out what was going on. Sure enough, I'm awesome, and the error appears to be in one of the wrappers the staff wrote. I'll email that off shortly, but in the meantime, surrounding everything with try/catch statements seems to work fine.
Woah! I just discovered that they already wrote the quad phase encoder wrapper for us! My work is done for the night! ~TR
Day 10, Wednesday, January 17th
4:00 PM
Ben and I are both thinking that doing anything more at this point is probably foolish. Ben has a vision algorithm that heavily relies on the robot never wandering off the playing field, and I've got a 3-thread architechture that seems simple enough that it should work. Ben's vision stuff sticks everything in buckets, assuming we're never going to see more than about 4 of any relevant feature, and whenever it finds a pixel, it just puts it in the nearest bucket (which is either a horizontal or vertical stripe). Once it's made one pass through the picture, it does a check on each bucket to see if the size is about right for whatever object it's looking for.
The control stuff has been greatly simplified. Most of the random crashing apparently stems from pinging 3 bump sensors at upwards of 400 Hz. Somewhat unsurprisingly, this floods the buffers on the OrcBoard. Hence the crashing threads. Fortunately, I've removed all the sensor threads, because everything except the camera is so fast I don't care about having it update in a seperate thread. I've now got a arbiter thread and a drive thread, and the camera will also get its own thread. That should simplify things a lot.
Now if only we didn't have to have this code run on a robot, we'd be done for the month. Oh well.
11:00 PM
$#@%, I left my power cord in lab. No Arrested Developement for me tonight. Looks like I'll have to resort to watching Idiocracy [1] on an actual TV and eating the 5 flans I stole from the ITA dinner.
Day 11, Thursday, January 18th
2:00 AM
There's a checkpoint today?
Also, I'm not signing these anymore, because I'm the only one who writes in this journal.
7:00 PM
We have a new robot! It's basically the same as the pegbot, but the sensors are all mounted better. This gave me and Ben a chance to play around with what we'd written, so while a first glance Plexibot is unimpressive, it's actually a big step. Ben's code appears to basically work, already we're going to have to calibrate it in actual game conditions. My code is riddled with sign errors, but that will slowly get fixed.
Anyway, we took it home, ate pizza, and I proceeded to fix most of the sign errors. By 2 AM, I had gotten a reasonable version of the wander and charge code drafted up, but Senior House is filled with red. I'll actually test that tomorrow, when I have a course. On to the mock competition!
Day 12, Friday, January 19th
2:00
Johnny 5 makes an ass of himself at the Mock Competition.
7:00
So, the problems of the mock competition have been mostly resolved. The main problem of not following simple commands was mostly due to poorly implemented interrupt architechture, but that's mostly been resolved. Johnny can now follow a sequence of uninterruptible commands and get interrupted by higher priority items (wallFollowing can be interrupted by avoidWall, trigger by the bump sensor). He can't quite come back down that chain, but that's what Friday nights are for, right? Besides steak, of course.
Why do these entries keep ending in food? I must be hungry.
9:00
What can I say? Some of use are better at ballfinding than others.
Day 13, Saturday, January 20th
OK, my code is nearly readable. I spent most of last night and today making sure my code was useable. Additionally, I actually implemented and tested PID control, including making up constants. Now, it'll actually stay on track without too much wandering, and the turns don't overshoot like woah.
Ben's working on a finite state machine that he found somewhere, and once we have that, moving my code into that framework should be pretty easy. The camera also doesn't report the Y value as a stupid version of the X value anymore.
4:00 PM
Team pictures have been added. I swear I'm working on the code.
Actually, I figured out a decent way to do FSM stuff, and the great code cleanup continues. More when it's actually functional and I can commit it to the repository.
Day 14, Sunday, January 21st
I'M AWESOME.
The FSM stuff from yesterday works well. Ben and I talked about it today, and there's probably a better way to do it, but nothing so convincingly better. We decided to do stuff with this, and we may change it if it become hard to read. Also, the bump sensors are sucking, so we decided to do something about that. After going into lab and demanding 5 IR sensors (funny looks and admonitions abound), we decided that vision and quad phase encoders might be able to work sooner than bump.
The reason I'm awesome is because after figuring out the last major bug in my architecture, Johnny now drives around my room without getting stuck on the input of one borked IR sensor and the quad phase stuff. The quad works ridiculously well to figure out if we're stuck, and by just backing up and turning ~70 degrees to the left, it can wander and not get stuck. Between that and the vision, we may not need bump sensors.
More work to come, but now, fried chicken.
Day 16, Monday, January 22nd
Major accomplishment of the day: wikiVandalism!
Day 17, Wednesday, January 24th
With 8 days left to impounding, we decided it was time to start acting like a proper maslab team. In that spirit, on Monday night, we talked to somebody completely uninvolved in the competition, junked all the strategy we had talked about the entire month, and started to rewrite everything based on mapping the world.
Actually, this is not as bad as it sounds. Instead of building a FSM that directly interacts with the sensors, we decided it probably makes a lot more sense to separate the perception and decision-making sides of the robot brain. That means that we have one thread that simply builds a model of this world, assiging confidence measurements to anything it sees. It's pretty simple - it only includes 1 wall, 1 ball, and 1 goal. However, this means that the decision-making side of the brain doesn't have to worry about trusting specific sensors in specific instances, only about how sure it is of the relevant features of the world. The confidence in these features decays fairly quickly (without input, they only last 15-20 seconds), but it means that when a IR sensor spikes or the ball drifts out of the camera view, we don't immediately forget about it.
To this end, Ben and I have spent a lot of time coding and discussing this stuff in the last 2 days. Currently, we have a model of the world based on odometry and timouts (i.e., the only sensor we're monitoring is the quad phase), but it knows enough to wander more intelligently that the previous FSM. For instance, we can do basic wall-following with only quad phase data by assuming there is wall in front of us every time we stop, so once we know that, we can turn and follow along it. It works fairly well, and in 48 hours, we tore apart everything and rebuilt back to where we were Sunday. And with a better architecture for improve.
Sam was also thoroughly prodded last night, so he spent the night at MITERS making a less blind robot.
This is far too exciting.
9:00 PM
Much progress has been made already! After showing up to Checkpoint 3 with 33% success (congrats Ben), we started to put things together. Surprisingly enough, it all works! The bump sensors work incredibly well, and the wall follow code finally works. Johnny can now move from one side of the practice field to the other without getting stuck. To be fair, he's still bad with right angles (screw case, but that's what we get for only using bump sensors), but it's not bad. However, we've got a really solid framework (as described above), and it's much easier to add to than the previous architecture.
Sam's work last night was good, what with the functional robot and all. We don't have ball collection yet, but that should be fairly simple to code up once it's done, so I'm not worried.
Ben, all your methods that check for existence are named constainsSomething. You might want to look at that.
Mock competition tomorrow!
Day 18, Thursday, January 25th
So, we did decently at the mock competition. Unfortunately, we decided not to use all of our code, and for some reason, I commented out the useful ball-charging code. So, yeah, my bad. Anyway, we're on track, and most of the stuff that remains to be done is fixes. The only major things that need to be done are a ball-collection mechanism for the robot (tomorrow or Saturday, says Sam) and scoring code (I'll have that done by the time we have a scoring mechanism). The ball charge code is OK, but needs a lot more testing before I'll believe it, and Ben should have distance stuff for that pretty soon.
Other than that, we need to test IR wall-sensing, mount the fixed-up bump sensors (they're now Nintendo switches so they don't break), and come up with better stuck detection (90 degree walls screw us!).
Day 20, Saturday, January 27th
Our bump sensors still suck. After trying to use the Nintendo buttons, they are still too unidirecitonal under the mountings we made, and if you hit the edges, they just break. Damn. We might have to make a bunch more, but I'm secretly hoping that IR works well enough to keep us away from most walls.
The code is looking pretty good - the higher FSM has all the behaviors I want in it (but I know it will need loads of tweaking) and the model is pretty complete. The only problem is without a completed robot to test it on, we're not really sure how well it will actually perform. This is getting worrying. Maybe we'll bring in reinforcements.
Day 25 the Last, Thursday, February 1st
OK, after staying up until 8 AM working, we have a reasonable bot. Johnny isn't using bump sensors, mostly because the IR works awesomely. We ditched the linear actuator and are just a giant vacuum. The final strategy is to collect balls for 4:30 and park on the porch. In 5 test runs last night, we managed to never score less than 8 points, with a max of 15. Final calibrations were done, and everything looks pretty good.
Impounding today. Our major weaknesses at this point is balls immediately around right angles and failure to navigate tight spaces. Neither of these are actually going to screw us (hopefully), but it will make for a less-than-optimal performance.
Let's see how we do tomorrow!
