I quickly realized that were I to use this for my projects I would need an efficient storage of bytes that I couldn’t find in the community libraries as well as a buffered serial write which also hadn’t been implemented to my knowledge. I created these libraries and decided to share them here if anyone would be interested in using them.

These are the properties of the SerialManager library:

• Provides a buffered write method that I have not yet found in other libraries (processor can work on other things while serial port pushes out a packet of data)
• Provides a built in checksum calculation which can reduce errors in transmission and can be tedious to manage
• Provides built-in packet header search and hides it in the library code so the user code becomes more readable (can be disabled for sending raw packets)

Example usage

#include <SerialManager.h>
#include <ByteBuffer.h>
 
SerialManager serial = SerialManager(256, 256);
ByteBuffer send_buffer;
 
int SEND_MODE = 0;
 
void setup()
{
  // initialize the serial communication:
  serial.init(0, 9600);
  serial.setPacketHandler(handlePacket);
 
  // Initialize the send buffer that we will use to send data
  send_buffer.init(30);
}
 
void loop() {
  serial.update();
 
  // If we are not busy sending then lets send something
  if( !serial.isBusySending() ){
    // Send some dummy data
    send_buffer.clear();
    send_buffer.put(17);
    send_buffer.putInt(300);
    send_buffer.putLong(-100000);
    send_buffer.putFloat(3.14);    
 
    // We can either send a packet with a header and checksum (niiice)
    if(SEND_MODE == 0)
      serial.sendSerialPacket( &send_buffer );
 
    // Or if we are sending to say a device that uses a custom protocol,
    // we can send a raw byte buffer to it
    if(SEND_MODE == 1)
      serial.sendRawSerial( &send_buffer );
 
    // Or if we just want to simply send one byte we can do that,
    if(SEND_MODE == 2)
      serial.sendSerialByte(16);
 
  }
}
 
void handlePacket(ByteBuffer* packet){
  // Here we could do anything we want to the data but for now we will just send it back
  send_buffer.clear();
  while( packet->getSize() > 0 )
    send_buffer.put( packet->get() );
  serial.sendSerialPacket( &send_buffer );
}

Download Library

ArduinoSerialManager.zip

Depends also on this library:
ByteBuffer

I quickly realized that were I to use this for my projects I would need an efficient storage of bytes that I couldn’t find in the community libraries as well as a buffered serial write which also hadn’t been implemented to my knowledge. I created these libraries and decided to share them here if anyone would be interested in using them.

These are the properties of the ByteBuffer library:

• Provides an efficient storage of bytes in a circular bytebuffer (stored as an array)
• Provides access to data from the head and tail of the buffer (get() and getFromBack(), putInt() and putIntInFront() etc.)
• Provides a nice way of converting bytes into larger datatypes, example: put(b1); put(b2); put(b3); put(b4); long data = getLong();
• Convenient method to have a one process write values to the end of a buffer and have another process handle bytes from the beginning of the buffer whenever it gets around to it

Example usage

#include <ByteBuffer.h>
 
/*
  Silly program that emulates buffered processing
  using a circular bytebuffer
 */
 
ByteBuffer buffer;
 
void setup()
{
  // Initialize the buffer with a capacity for 256 bytes
  buffer.init(256);
 
  // Init serial just to debug
  Serial.begin(9600);
}
 
int cnt = 0;
void loop() {
  cnt++;
 
  // Every 100th update
  if( cnt%100 == 0 ){
    buffer.clear();
    buffer.put(200);					// Put one byte at end
    buffer.putInt(2000);				// Put one int at end
    buffer.putLong(20000);				// Put one long at end
    buffer.putFloatInFront(200000);	// Put one float at beginning
  }
 
  // Every 100th update	(20 updates offset)
  if( (cnt+20)%100 == 0 ){
    Serial.println("Received following bytes");
      while( buffer.getSize() > 0 )
        Serial.println(buffer.get(), DEC);
    Serial.println("");
  }
}

Download Library

ArduinoByteBuffer.zip

So I found the following bug in the Arras Theme while going through the progress of upgrading WordPress from whatever to 3.0 and the Arras Theme from 1.3.5 to 1.4.2.

All pages started giving me this warning and unexpected behavior:

Warning: unserialize() expects parameter 1 to be string, object given in /var/www/siggis_projects/wp-content/themes/arras-theme_1.4.2/library/admin/options.php on line 86

If I take a look at what is in line 86 of options.php I see this:

$saved_options = unserialize(get_option(‘arras_options’));

It seems that previously, get_option() was returning a serialized object but isn’t anymore (this is why I prefer strongly typed languages).

The fix is simply to remove the unserialize() function from that line, resulting in this:

$saved_options = get_option(‘arras_options’);

Hope this helps !

Has the sequence of images in the “featured slideshow” of the Arras theme become too familiar ?

Then you might want to apply this tweak:

1. find and open home.php under /wp-content/themes/arras-theme
2. find line 30 or whatever line contains this text: “$q = new WP_Query( apply_filters(‘arras_slideshow_query’, $query) );“
3. add this statement in the next line: shuffle($q->posts);
4. That’s it !

The idea is to make a display system composed of a cloud of small radiocontrolled helicopters, each carrying a small lightsource. The ensemble of all of the helicopters with delicate position control and lighting has the possibility to become a totally new and unconstrained display technology.

This is a project that I have been working on with my girlfriend Carnaven. She was the lead designer for the first stage of concept visualization for this project (resulting in the video shown below) for the Senseable City lab at MIT.

Please visit http://senseable.mit.edu/flyfire/ for more details.

The project has currently finished the first design stage and has received some funding to begin physical implementation.

A screenshot from the video showing the helicopters rising up from the ground and their light creating an illumination effect on the ground surface (image source: http://senseable.mit.edu/flyfire/)

A snapshot of different 3D formations of the pixel cloud (image source: http://senseable.mit.edu/flyfire/)

The pixel cloud can be programmed to exhibit interesting flocking behaviors, simulating animal group behavior (image source: http://senseable.mit.edu/flyfire/)

The pixel cloud can simulate many different surfaces, this is how it is able to portrait a richer experience in for example displaying an outdoors scenery (image source: http://senseable.mit.edu/flyfire/)

The cloud can be used to render classic 2D images, activating dormant helicopter pixels when it needs more screen real-estate (image source: http://senseable.mit.edu/flyfire/)

When I started adding posts to my site the header list updated accordingly and everybody was happy, until at some point I noticed that the header menu was not updating according to new categories and sub categories that I was creating.

I tried all I could to fix this, thought that my categories had “bad” names and tried changing them back and forth.

It wasn’t until I started looking through the php code backing this theme up that I found the bug. Arras has a “hardcoded” maximum number of categories to show in the header menu (I have no idea why, nor why nobody has complained).

Solution:

• On your server, browse to the folder: /wp-content/themes/arras-theme
• Open the header.php file
• Browse to line 111 (that is the line number in my file, it might be different for whatever version you have). It is the line that contains wp_list_categories(‘number=11&hierarchical=1&orderby=id&hide_empty=1&title_li=’);
• Change the property number=11 to anything you want, I chose 111

We conducted an experiment that evaluated how people perceived a robot-mediated operator differently when they used a static telerobot versus a physically embodied and expressive telerobot. Results showed that people felt more psychologically involved and more engaged in the interaction with their remote partners when they were embodied in a socially expressive way. People also reported much higher levels of cooperation both on their own part and their partners as well as a higher score for enjoyment in the interaction.

This work received a best paper nomination at HRI2010

Related publications:

• Sigurdur Orn Adalgeirsson. Mebot, a Robotic Platform for Socially Embodied Telepresence. In Proceedings of the fifth ACM/IEEE International Conference on Human-Robot Interaction (HRI-10). ACM/IEEE International, 2010. [Best paper nomination]
  Link

In printed media:

• FrankfurterRundschau [March 30th, 2010]
  

In on-line media:

• Engadget – MIT’s MeBot makes telerobotics fun again
• BotJunkie – MeBot Brings Intuitive Movement To Telepresence
• CNET Crave – Robot avatar MeBot gives you wriggling bug body
• Hizook – MeBot: An Affective Teleconferencing Robot from MIT Being Presented at HRI 2010
• Coolest Gadgets – Mebot lets you talk to the little one on your desk
• Golem.de – Mebot – der gestikulierende Telepräsenzroboter
• DVice – MeBot, MIT’s most expressive telepresence robot yet
• RobotShop – MeBot a telepresence mini robot
• Hacking the Universe – MeBot
• Singularity Hub – MeBot, the Telepresence Robot With Body Language
• Ubergizmo – MeBot telepresence robot
• Technabob – MIT’s mebot is telepresence at its best?
• Technovelgy – MeBot Robot Avatar Telepresence
• Plastic Pals – MeBot

Update:

MCBMini V4 is now finished (see header image) and is actively being used for multiple new and old robots within the Personal Robots Group. See manual for more specs here: MCBMiniV4Manual.pdf

The development of robots that should have the ability to display rich expressiveness as well dexterity and movement in human-like ways requires an advanced motor control scheme that fulfills a certain set of requirements.    A few of the important specifications for motor control of robots that are developed in the Personal Robots group at the Media Lab are listed as follows:

• High update rate: For the robot to move in a compelling and human-like way, the behavior system needs to be able to stream updated target positions for the motors at a decent update rate. The motor boards need to be able to dynamically adapt to a rapid stream of changing target positions as well as possibly compensate by interpolation or filtering for slow update rates resulting from communication lag.
• High density: Robots that are intended to display social characteristics usually have rigid constraints on their structure imposed by aesthetics. These constraints usually don’t leave a lot of extra space for bulky motor controllers. Robots of this type therefore require high density controllers that can control multiple motors while taking up as little space as possible. A distributed architecture might be useful in this regard as it might be hard to fit all of the motor controllers in one big space but there might be smaller spaces available distributed around the robot.
• Scalability: Incremental design is a process of trying out a possible solution to a particular problem and individually evaluating the result through incremental prototyping. This process is particularly useful for designing robots and it requires a scalable motor control system as the number of motors is not a static quantity but can change through the design process. The motor control scheme needs to address this by offering an easy way to add or remove motors.
• Safe operation: Sociable robots are essentially designed to interact with people and therefore need to operate safely. Safety can be interpreted in several different ways, the normal operation of the robot needs to be safe for humans and that involves acceleration and velocity limits for joints as well as monitoring of motor currents and responding in a safe way to unexpected values. All failure modes of the robot need to be safe for humans so that if anything goes wrong, the robot will not cause harm. Lastly these robots are usually expensive machines and difficult to repair so the motor control needs to make sure that the robot doesn’t do harm to itself.
• Transparency: The design of complicated robotic systems usually involves a great deal of debugging. When implementing and testing out new systems, much of the development time goes into trying to understand the source of possibly erroneous behaviors of the system. It is very important that every stage of the robotic system be as transparent as possible, that is to say that communication of signals can be monitored by the designer at every stage so they can determine the origins of the error.
• Minimal wiring: Sociable robots usually have a very dense network of relatively low-powered motors. These motors are placed in various locations all over the robot and can be hard to access and especially tricky to trace wires to. The motor control scheme must be implemented so that it requires minimal wiring and an easy way to switch motors or boards out if they become unusable through wear-and-tear.

Composite image of the stack and the board design file (previous version)

For the specific needs of the MeBot project, I decided to build motor controllers that were very modular. The system operates in a master/slave mode where there is one central node that arbitrates all communication between the motorserver (a computer that controls the robot) and the actual motor control modules. The modules are all connected to a bus that provides motor power, logic power and data.

Master board: Arbitrates communication between host application and motor control boards

Slave: Every motor board can control two motors

Shows the communication scheme of the system. On top resides whatever program that wishes to move motors, this program is networked (wired or wireless) with the motorserver which is the computer that is directly connected to the robot. The motorserver communicates with the master board which arbitrates low-level bus traffic and caches all data. On the lowest level are the motor control modules which can control two motors each.

Multiple slave motorboards can be stacked on top of the master. This assembly has one USB master and two slaves. This stack is controlling two motors but can control four.

Related publications:

• Sigurdur Orn Adalgeirsson. Mebot, a Robotic Platform for Socially Embodied Telepresence. Master’s thesis, MIT, 2009.
  Link

“Located at the ground floor of the Graduate School of Design, the exhibition would have to be of sufficient size to transform the large lobby space. The projected opening of September would make this the opening exhibition of the new academic year of fall 2008. The exhibition would also last six weeks, and host a conference.

Working with the designers of the exhibition, the initial idea was to create a series of display cases within which LED arrays would not only provide illumination to its contents, but also demonstrate behaviours that suggest a curatorial path for the viewer. These resultant LightBoxes would be suspended in a larger environment – a taut, stretched fabric shell with text and images and also lit from behind. The design intent would be an otherwise dark gallery space encompassed by a softly lit shell. Within this wrapped environment would be a field of display cases interacting with the patrons.

For the single LightBox, proximity sensing with ultrasonic transducers was used so that the passing of a patron would activate the LED display, and become brighter as the viewer approached to view its contents. For the collection of LightBoxes, a higher-order intelligence was needed to
suggest connections with other LightBoxes, and therefore generate interest in the viewer to a prescribed, but non-explicit, trajectory. The curator would have several displays share similar qualities but have them ina linear sequence, or have them in another configuration, like a spiral. The viewer may even enter a sequence mid-stream, or one that bifurcates. This requires the LightBoxes to demonstrate a group intelligence, where neighbours and their contents are known.”

Simon Kim

Shows the mechanical design of the actual lightboxes

The MIT beaver enjoying the spotlight

Each sensor/LED controller board was connected to a bus for power and communications to a central control PC

System diagram for the control scheme

The box in place while structure is being assembled