If Legos could fly… - University of Washingtoncourses.washington.edu/art483/site/images/iflegoscouldfly.pdfIf Legos could fly… Keri Lindquist, Stefan Moore, Brian Smith & Luke

If Legos could fly…

Keri Lindquist,Stefan Moore,Brian Smith & Luke Woods

Andrew Davidson& Axel Roesler

Designing BehaviorsUW IxDWinter 2007

If Legos could fly… Keri Lindquist,Stefan Moore,Brian Smith & Luke Woods

UW IxDAndrew Davidson& Axel Roesler


Overview




Team

Keri Lindquist, Design StudiesStefan Moore, DXARTSBrian Smith, Computer Science & EngineeringLuke Woods, Interaction Design

Summary

boPET, a neturally bouyant lego mindstorm blimp, moves throughout the classroom space detecting distant obstacles and avoiding them buy turning to the opposite side. It is aware of its relative height and can move up and down to avoid being too close to the ceiling or at a height where the propellors could endanger spectators.

Motivation

Exploring the differences of air rather than land (fluid XYZ vs. static XY). Find-ing the possibilities and limitations in taking technology that was not intended for flying and adapting it to do so. Interacting with humans at eye height or above instead of foot height. Making a proof of concept for a flock of blimps.

Overview




Process




ProcessSeeds for design

“You can do any-

thing, just don’t make

them fly away…”

“How do you make

a rocket ship

out of a box of eggs?”

– Axel Roesler

Catalyst Stefan’s original proposal Luke’s original proposal




ProcessConcept development

The concept for our project was a combination of both Luke and Stefan’s project proposals. Both had ideas about using a blimp to take the Mindstorms brick out of its intended context - the ground - and bring it into the air.

Our behavior evolved in what seemed an infinite refining process. After explor-ing many concepts like the blimp as an interrupter, a satellite metaphor, an attention beacon, or a directional resource for a robot on the ground, our first project proposal described a flock of three blimps exploring the affordances of air while flying close to one another without colliding.

After discovering the expense of a single blimp, we realized we needed to downsize and only create one blimp robot as a proof of concept. Our next project proposal described our blimp as a “whispering” blimp that would interact with people by recording audio clips from one part of a room and replaying the bits of conversation in another part of it. But after weighing all the parts needed for our robot blimp by tethering them with string to the blimp, we began to see how big of a difference every fraction of an ounce makes in its buoyancy.

To cut down weight, we thought of using pre-recorded clips of someone speaking and play certain ones depending on the circumstances in which the blimp finds itself. Next we found that there is very little room in the Mindstorms software for pre-recorded sound clips and that the Mindstorms brick can only know its position in a room with the accelerometer, and even with that software, it is still very difficult.

After refocusing our efforts, it came to our attention that every draft in the room plays a big role in the path of our flying robot. We then came to the con-clusion, with the end of the quarter rapidly approaching, that getting the blimp to fly around the room and able to avoid objects and counter air drafts would be an accomplishment.

Sfhits in the course of our ideas as the project developed.




ProcessPhase breakdown

Phase 1: Lift Phase 2: Sense Phase 3: Control

Goal: to achieve neutral buoyancy Goal: to enable boPET to sense its environment Goal: to achieve some degree of autonomous control




ProcessBehavior sketches




ProcessKeyframes

From concept to implementation: moments that punctuated the collaborative design process.

Calculating lift Cutting grams Inflating the envelope

boPET at home in the studio Tools Planning the motor placement

At rest Attaching the NXT brick boPET in air




ProcessKeyframes

From concept to implementation: moments that punctuated the collaborative design process.

Testing the ultrasonic sensors boPET’s anthropomorphic stage Sanding down the wire to avoid cutting and splicing

Forces to cut the proprietary wires Soldering new wires Testing with LEDs in place of the propellers

Calculating acceleration Stitches boPET in air




Hardware




HardwareOverview

The blimp envelope is 7 feet long and made of mylar. We filled it with stan-dard-grade helium which negatively affected lift (12.5oz real-world vs. 15oz. theoretical).

Balsa-wood wings extend from the belly of the NXT brick and serve as motor mounts for our micro-DC motors and 3” propellers. A 2.25” polystyrene H-beam descends perpendicular from the middle of the brick in order to mount the motor responsible for z-axis control.

We shed as much weight from the setup as possible by removing some plastic components, and by stripping the outer insulation from the Mindstorms wires. Originally we had developed a balsa wood mounting frame that surrounding the NXT brick, but that too had to be scrapped in favor of direct-mounting.

The gondola is attached to the envelope by a fishing line harness on the NXT brick, wrapped around by a small piece of mylar which is then taped to one of the envelope’s seams.

This project was influenced by a commercially funded blimp project called ALAV (www.alavs.com). We contacted one of the project leads and reviewed their documentation to try and determine what our course of action should be. From them we learned quite a few things regarding weight limitations, balance, and the troubles of attempting to navigate a fluid environment.




HardwareMultiple Views

Bottom view Front view Three-quarter fromnt view

side view Three-quarter rear view Rear view




Software




const tSensors usR = (tSensors) S1; //sensorSONAR9V //*!!!!*//const tSensors usL = (tSensors) S4; //sensorSONAR9V //*!!!!*//const tMotor motorR = (tMotor) motorA; //tmotorNxtEncoderClosedLoop //*!!!!*//const tMotor motorCenter = (tMotor) motorB; //tmotorNxtEncoderClosedLoop //*!!!!*//const tMotor motorL = (tMotor) motorC; //tmotorNxtEncoderClosedLoop //*!!!!*//

/*NXT I2C register storagelocation Rd contents Wr contents0-7 v1.0 -8-f mndsnsrs -10-18 ACL3X3g -

0x400x41 command

0x42 X Tilt data -0x43 Y Tilt data -0x44 Z Tilt data -

0x45 X accel data LSB -0x46 X accel data MSB -

0x47 Y accel data LSB -0x48 Y accel data MSB -

0x49 Z accel data LSB -0x4A Z accel data MSB -

0x4B X_offset lo X_offset0x4C X_offset hi X_offset

0x4D X_range byte0 X_range0x4E X_range byte1 X_range

0x4F Y_offset Y_offset0x50 Y_offset Y_offset

0x51 Y_range Y_range0x52 Y_range Y_range

0x53 Z_offset Z_offset lo0x54 Z_offset Z_offset hi

0x55 Z_range Z_range0x56 Z_range Z_range

===================================================0x41 command===================================================

Command ActionASCII Hex

X 0x58 acquire X Calibration point

Y 0x59 acquire Y Calibration pointZ 0x5A acquire Z Calibration pointx 0x78 End X Calibration modey 0x79 End Y Calibration modez 0x7A End Z Calibration mode*/

const ubyte kAcclID = 0x02;const ubyte kAcclCommandReg = 0x41;

const ubyte kX_Tilt = 0x42;const ubyte kY_Tilt = 0x43;const ubyte kZ_Tilt = 0x44;

const ubyte kX_Accl = 0x45;const ubyte kY_Accl = 0x47;const ubyte kZ_Accl = 0x49;

const ubyte kX_Offset = 0x4B;const ubyte kX_Range = 0x4D;

const ubyte kY_Offset = 0x4F;const ubyte kY_Range = 0x51;

const ubyte kZ_Offset = 0x53;const ubyte kZ_Range = 0x55;

const ubyte kAccl_X_CAL = 0x58;const ubyte kAccl_Y_CAL = 0x59;const ubyte kAccl_Z_CAL = 0x6A;

const ubyte kAccl_X_CAL_END = 0x78;const ubyte kAccl_Y_CAL_END = 0x79;const ubyte kAccl_Z_CAL_END = 0x7A;

const ubyte kADPA_on = 0x4E;const ubyte kADPA_off = 0x4F;const ubyte kAccl_FACTcal = 0x52;

const tSensors kAcclPort = (tSensors) S2; // Connect sensor to this port!!byte replyMsg[2];float Zvel=0;float Zpos=0;

////////////////////////////////////////////////////////////////////////////////// Read the acceleration data from Accl sensor/////////////////////////////////////////////////////////////////////////////////

int Get_accl(byte axis){ int accl; byte acclMsg[5]; const byte kMsgSize = 0;

Software

After frustrating attempts to gather data from our accelerometer by programming in Mindstorms NXT, we switched to working with RobotC, which proved much more efficient and robust. Initially everything was written directly in Mindstorms, but we made the change to RobotC because most of our hard-ware is not officially supported by LEGO. This provided us with a more elegant interface to our sensors and motors. It also allowed us to easily implement some kinematic equations to calculate relative vertical position.

The code is broken into meaningful, but managable functions. Each function is responsible for either interpreting data or sending instructions. There are functions to read UltraSonic(US) data, control each motor, read the acceler-ometer, and convert vertical acceleration data into position. These functions work together to produce the behavior of the blimp. The behavior of the blimp can be broken down into the following states:

State 1: Startup, no US contacts, no acceleration, position within limit.State 2: Contact Left.State 3: Contact Right.State 4: Contact Left and Right.State 5: Position too high.State 6: Position too low.

Each state has a corresponding reaction:State 1: Travel Forward.State 2: Turn Right.State 3: Turn Left.State 4: Back up and Turn.State 5: Descend.State 6: Ascend.

Nxtasy offered some helpful hints when working with Mindstorms. Otherwise, Robot C has sample code in its software which was very useful as well.




accl = 0; Zpos += accl/20000000 + Zvel/100; Zvel += accl/100000; nxtDisplayTextLine(4, “%#.10f”,Zvel); nxtDisplayTextLine(5, “%#.10f”,Zpos); }}

// Loops that pings both sonar sensorstask ping() { while(true) { PingSonar(usR); if(SensorValue[usR] < 50) PlayTone(784, 10); PingSonar(usL); if(SensorValue[usL] < 50) PlayTone(880, 10); }}

// Main task that is automagically executedtask main(){ InitializeSonar(usL); // Sends the Sonar sensors some love InitializeSonar(usR);

nI2CBytesReady[kAcclPort] = 0; // Because the acceleration sensor wants love too SensorType[kAcclPort] = sensorI2CCustom9V;

// Begins each of the above listed tasks StartTask(ping); StartTask(accler); StartTask(rightSide); StartTask(leftSide); StartTask(center);

while(true); // added so program doesn’t exit after one pass StopAllTasks(); // completely and entirely unneccesary}

wait1Msec(2); // Wait till I2C communication ends

readI2CReply(nPort, replyMsg[0], nSonarReplySize); SensorValue[nPort] = replyMsg[0];}

// Controls the right side of the motor systemtask rightSide(){ while(true) { if(SensorValue[usL] < 50) motor[motorR] = 50; else motor[motorR] = -50; wait1Msec(1000); motor[motorR] = 0; wait1Msec(3000); }}

// Controls the left side of the motor systemtask leftSide(){ while(true) { if(SensorValue[usR] < 50) motor[motorL] = -50; else motor[motorL] = 50; wait1Msec(1000); motor[motorL] = 0; wait1Msec(3000); }}

// Controls the bottom fan of the systemtask center(){ while(true) { if(Zpos < -.02) motor[motorCenter] = -50; else if(Zpos > .02) motor[motorCenter] = 50; else motor[motorCenter] = 0; }}// Calculates current height based on acceleration data in the z directiontask accler(){ int Zaccl; float accl = 0; while(true) { wait1Msec(10); Zaccl = Get_accl(kZ_Accl); accl = ((float)Zaccl-1169.576); if(accl < 40 && accl > -40)

const byte kAcclAddress = 1; const byte kReadAddress = 2; const byte kCommandAddress = 2; const byte kCommand = 3;

// Build the I2C message acclMsg[kMsgSize] = 3; acclMsg[kAcclAddress] = kAcclID ; acclMsg[kReadAddress] = axis ;

replyMsg[0] = 0; replyMsg[1] = 0;

while (nI2CStatus[kAcclPort] == STAT_COMM_PENDING); { // Wait for I2C bus to be ready } sendI2CMsg(kAcclPort, acclMsg[0], 2); // when the I2C bus is ready, send the message you built

while (nI2CStatus[kAcclPort] == STAT_COMM_PENDING); { // Wait for I2C bus to be ready } readI2CReply(kAcclPort, replyMsg[0], 2); // when the I2C bus is ready, Read the reply

accl = replyMsg[0]; accl += replyMsg[1]<<8; return(accl);}

// Initializes Sonar to ping modevoid InitializeSonar(tSensors nPort) { static const byte kSonarInitialize[] = {3, 0x02, 0x41, 0x01};

SensorType[nPort] = sensorI2CCustomStd9V; sendI2CMsg(nPort, kSonarInitialize[0], 0); wait10Msec(5);}

// Pings sonar sensorvoid PingSonar(tSensors nPort) { static const byte kSonarPing[] = {3, 0x02, 0x41, 0x01}; static const byte kSonarRead[] = {2, 0x02, 0x42}; const int nSonarReplySize = 1;

byte replyMsg[1];

sendI2CMsg(nPort, kSonarPing[0], 0); wait1Msec(10); // wait 10ms, enough for echos to return to sensor.

nI2CBytesReady[nPort] = 0; // Clear any pending bytes sendI2CMsg(nPort, kSonarRead[0], nSonarReplySize); while (nI2CStatus[nPort]==STAT_COMM_PENDING)




Conclusion




Reflection

From expansive initial ideas, we narrowed to building a Mindstorm blimp with some degree of autonomy of movement and awareness of position or obstacles in its environment. Working on this seemingly simple task revealed much hidden complexity and room for innovation.

In Napoleon’s words, “one begins a battle and then one sees. Our initial strat-egy was proved to be a successful framework to work within, but we could not foresee the difficulties and opportunities until immersed in the design process.

Results

Though we had to scale back our original plan and re-frame our behavior, the Mindstorm blimp was a successful project in several respects. First, we man-aged to achieve neutral buoyancy and effectively balance the NXT brick on the envelope. Second, we developed or borrowed several ‘hacks’ that enabled the project: taking apart the NXT brick to cut weight, soldering and splicing new connections, wiring dc motors to the brick, using custom I2C controller bricks in Mindstorms, coding in Robot C , and enabling an unsupported accelerom-eter working to control the blimps Z-axis location. Third, we developed a piece that is captivating in the way its behavior reflects and reacts to its environment. The effect of air currents and human interruption on boPET enable endless variation in boPET’s behavior. Finally, it is interesting how the scale shift, from that of an ant to an agent that exists at human eye-level, encourages people to play with boPET and understand its sensing and control capabilities.

Conclusion Opportunities

Seeing one blimp in action foreshadows the array of opportunities that a small group of blimps would present for coordination and cooperation. We are still interested in pursuing flocking behaviors, land-air coordination and mapping, blimp-vision, and audio experimentation. To continue though, realistically, out-side financial support and more precise tooling would be imperative.

Documents

If Legos could fly… - University of Washingtoncourses.washington.edu/art483/site/images/iflegoscouldfly.pdfIf Legos could fly… Keri Lindquist, Stefan Moore, Brian Smith & Luke