Deprecated: (6.186) preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /afs/ on line 1550

Deprecated: (6.186) preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /afs/ on line 1550
Team Four/Journal - Maslab 2014

Team Four/Journal

From Maslab 2014
Jump to: navigation, search



No batteries ;( What do? Zzz Going over lecture = going over competition. HEY LETS GO FOR COLLECTING BALLS YES? :D

1526197 10152102423785700 389387801 n.jpg 1512679 10152102539610700 311967234 n.jpg

IMG 20140106 211640.jpg IMG 20140106 211648.jpg

No electronics hooked up yet, but kitbot base mechanically works.

Ubuntu has been force fed onto our slate, opencv 2.4.8 compiled, and the CV stuff we have already is running on it with the on-board rear camera.

No work on actual electronics yet.

screenshot from slate


2/3 team sick, 1/3 busy. We got a battery and made most of the connectors we need for kitbot. We have the Maple IDE working on two of our computers, and we're trying to get the maple libraries to work for our own makefiles, instead of the stupidly complicated ones that ship with libmaple.

Being sick is really not helping things.

Connecting to botclient is unbelievably simple. We'll probably spin off a process for every image we want to save, so the main system won't be hung up by the client or disk writes, if any are needed. It might be worth spinning off a process that writes out the image, then having a python daemon pick it up for simplicity (C and json is a bit of a pain). A ramdisk is easily fast enough to be used for passing images between processes, the SSD in the tablet might be too.

Reading sensor data for tomorrow's checkoff will probably be pretty trivial with the Maple IDE or libmaple toolchain, but it'd be nice to have sensors working outside of those two things, since both are a pain.


2/3 of our team has healed, 1/3 ?!?

Today in lecture we learned how to make an LED "Le broken" and how to sober up robots.

Maple programmed with a tiny thing that listens to serial and controls the motors based on input. We flailed at the short range digital distance sensors for a while and couldn't get them to ever detect anything close to them. Tried providing 3.3v from Maple, grounded to Maple, and scoped output. No reaction, the sensor always put out 3.3v on it's output. Very confusing

We also got our check-off whoo.


2/3 of us are getting magical laser training, 1/3 cadding "base and shit"

Aisha watched people talk about computer vision, Alex was like "lol imma not using that Java"

Aisha's tired today, got a safe battery connector thingy, and learned about MapleIDE and Solidworks.

Team making progress towards check-off tomorrow.

We're trying to figure out what the best mechanism for lifting balls is. Spiral, belt, or something else. The inability to just dump balls onto the top of the reactor is a pain. Whose bright idea was the overhang on the reactors?

Hooked gyroscope up, it definitely looks like it's working but needs some time for calibration. Made battery connector to lower the chance that we'll electrocute ourselves. Forgot switch, need to splice that in somewhere.


Messed around with CAD

Bot1.png Bot2.png


Discussing strategy, considering switching to making a robot that can reliably put balls into the bottoms of reactors and ignoring everything else. We could make a relatively fast robot with easily accessible electronics for debugging. Tiny-ness of robot would also lend itself well to breaking ties.

We've settled on a robot which purely moves green balls into the bottoms of reactors. We're completely ignoring trying to lift balls off the ground. The idea is to reliably collect green balls and get them into reactors, aiming for the points per unique reactor with a ball in it. By ditching all tall elements of our robot, we can hopefully have a faster and lighter robot, for moving more green balls and winning any tie breaking.


New strategy, two sides to put in balls of different colors. Other things are the same, multiple levels, 2nd for tablet, 3rd for electronics.


Worked on CAD, computer vision, sensors.


Kitbot reassembled with sketchy camera mount. Switch added to battery. Kitbot had a minor accident and had to be given a duct tape cast. Sliced away bits of kitbot preventing the wheels from spinning nicely. Computer vision software (still plenty of memory leaks) now sends basic commands, and kitbot can theoretically home in on a ball of a selected color (based on hue). Speed needs to be tuned, control system could use a lot of work. Kitbot has no way to pick up balls, so right now it'll just smash it's face into a ball and keep going. Probably what we'll be bringing to the mock competition since mystery hunt<ref></ref> will be eating time tomorrow up until we go in for the mock competition.

CAD is coming along, we should start cutting soon. Because our strategy no longer relies on lifting balls beyond the bottom layer of the robot, our design has been massively simplified and we can hopefully have most of our robot CADed soon. We're adding a rear roller w/ storage area to collect red balls, and a front storage area designed to hold up to three green balls and dispense them into reactors.

Some talk yesterday about giving our robot a tail. Actually turned serious for a little while before we improved the design. Some talk today about turning our bot into a nyancat. Nyancat is more likely than a tail, Aisha may be getting crafts for it in the near future.

Initial attempt to get our own lipo charger failed. Hobbyking site fail. Very annoying, need to fight with their support. Ordered one through Amazon so we'll have a reliable way to charge our lipo.


Mock competition, kitbot successfully found a ball and drove towards it. Better than nothing. We got a second DC geared motor with an encoder so now both wheels have encoders, and another motor without an encoder for our rear spinner. We probably need more motor controllers. Got rubber bands and stuff from lab. Rest of day lost to mystery hunt


Mystery hunt break continued


Spent a while messing with circuitry. Too bad none of us are EE. Now convinced that all the digital distance sensors don't work. Odds are that isn't actually true. Must be something we're missing, but it's annoying enough and already eaten too much time.

Working on getting ultrasonic sensors to behave. Made a rough timeline for hardware development.

Ultrasonic distance sensor still not behaving. EE really isn't our thing. Wired up both encoders. Worst case scenario we can make software-based "bump sensors", which will detect when the motors should be spinning and aren't. That would mean we're stuck on something and should back up and turn.


Got annoyed at the Maple's lack of sprintf. Wrote (some) of it. Now Maple has sprintf and all is right in the world again. Working on reading data from encoders.

Discovered stdio exists for Maple. Oops.

Meh, writing sprintf was fun.

Encoders were easy to set up.

Lots of progress on CAD:

Screenshot 2014-01-21 08.05.10.png

Now time to get a couple hours of sleep before going to lab for some sort of announcements. Why on earth is there mandatory stuff at noon, and why the heck did we get only a little over 12 hours of advance notice?

Oh, and a few details of the design. Instead of bothering with things that try to lift balls in clever ways, we're just collecting red balls and trying to place green balls in the reactors. We're not going to win, just to learn and make a robot that can hopefully reliably do simple tasks. The small corral is the holding space for green balls. We want to only grab one or so at a time and place it into the bottom parts of reactors. The large corral is a holding space for red balls. When a red ball is sighted, the robot spins and eats it with the rear roller. There'll be a speed bump at the entrance so that hopefully balls will stay inside the robot. Picking up a red ball is effectively gaining 6 points (we would have -5 from the red ball being on the field, and we gain +1 from holding a ball).

The back of the robot might become the front if we hit problems and we might just switch to purely collecting balls. Collecting balls is a much easier strategy to get a reasonable score than trying to score in the reactors, so it'll be the first thing we try for.

There will probably be four ball casters (or similar) in each corner, to keep the robot approximately level. Unfortunately the floor of the maze is apparently a stupid squishy mat (if they use the one that's currently in lab), which will make finding a replacement for ball casters much more unpleasant if they don't come in on time.

More progress on CAD, our CAD is pretty much done (excluding casters which shipped today).

Ss (2014-01-21 at 09.56.27).jpg


Fetched a motor controller from lab for roller motors.

Saved the lives of 5,000 ladybugs.

Realized that Vecna's namesake isn't common knowledge. Went around explaining it to everyone nearby who might care, and probably a few who didn't ([1]). Evil arch liches are awesome. Hopefully Vecna is actually named after Vecna.


Worked on cleaning up electronics mounts. Planning to do cut layout today and cutting + assembly tomorrow. Just in time for sponsor dinner on Friday.


Pulled all-nighter to to laser-cut, assemble, screw things on, plug things in, make rollers, pass out


2nd mock competition today in 26-100, team is sleepy, Alex fixes all the things


It's all a blur.


Bad ideas continues to make things blurry.

Aisha did ultrasonic stuffs.


Alex and Aisha are still playing with ultrasonics.


Assembly of electronic things, moving things around, added arduino and rainbow wires.


Seeding, Alex breaking and fixing things, MOAR CODE, team photo with cat ears, Michael's trip for nyan cat robot, maslab continues to devour lives.


We said f*** it all and made our robot into a nyanbot, because if we're going down, at least we're going down in f***ing style. :D






Personal tools