R2 at Destiny USA for Rogue One premier

R2 visiting old friends... making new ones...

All the while BB8 sat there chirping sadly....

Bad Motivator and Sound chip fixed

Syracuse Silver Knights Star Wars Night

Had an awesome time with the families at Silver Knights Star Wars Night on 11/18/2016
When we brought R2 up to the main entrance, we decided to get him all squared away before the kids saw him... so, I shoved the new motherboard into the system and I think we ended up shorting both the sound chips and the sabertooth foot drive controller out.

my daughter and nephew pushing R2 through downtown Syracuse... what a trip!

Turning him on... bam... nothing - light and dome controls worked though

Here is R2 looking at us and saying... "why me?"

Some great characters made an appearance... we had our R2 on this side and Kightshade's R2 (from Rochester) on the opposite entrance.

We could see the dark knight making is way through the crowd to get the droid.

I think this storm trooper tipped him off... the kids were very excited to see R2

This little guy almost knocked out the lower vent on the front... thank goodness it was easy to fix.

Here is the dark lord of the sith and a desert trooper from the 501st visiting... Knightshade's was running into issues with his drive system as well that night.

Knightshade's wife with his droid, and me with mine... notice how clean mine is :)

Darth is trying to explain to little kids that he is friendly.... right.

my daughter with a group photo  -she is the droid wrangler for the evening

Overall - great evening.... R2 worked out well although no sound or movement.... everyone loved their picture taken with him.

Ive lost my mind!

I was just thinking... sure charge the batteries while they are in the belly of R2 (they are in series as 24v btw) and I don't have to lift those suckers out!

right.....

I had it connected for like 6hrs and it was never finishing... I needed 24v charger - jackasssss, palm plant!

So... here we are ETA 3 hrs till the event with me panic charging the batteries for R2. :)

I also decided to cut the motherboard in half to reduce size and make it easier to pop in and out... last minute charley strikes again!

R2 readiness for Rogue One

Since February we have moved, lost pieces of R2 and BB8 like his head...

Now as we enter August, work begins on some key items for R2:

1. Migrate the Shadow Collision system to Raspberry PI 3 (its currently Arduino only)
2. Add some navigation travel using GPS for road travel... in the neighborhood.

I2C Communication Update

Fault in our stars: I2C Crashing either the sensor or master (SHADOW) controllers.

When working with the Sensor controllers, I believe I have swapped the wires out at least 4 times now.  Either swapping for better shielding, gauge or just plain different wire to combat issues with the I2C channels simply crashing either the MEGA or the NANO CPUs.

What I was doing was setting up the arduino nano's which were on sleds or shields that the CPU plugs into. and was connecting to I2C and common grnd/pwr from the arduino mega in the body.

The design

I2C was setup in a MASTER MASTER configuration where every device had an address on the channel.

REVISION 1: Force it down the throat

The code was using interrupts on the mega to simply listen and when something came across the wire it would listen and store the next variables into an array of bytes.

simple right? riiiight.

What would happen is the nanos would basically flood the shadow controller until all of a sudden it would lock up when trying to use the BLUETOOTH controller or it was in the middle of something else.

Many re-writes, pull up configurations as well as wiring scenarios...

Some of the outcomes were very poor or simply unresponsive sabertooth controller response (like delayed by several seconds) this was probably due to the mega having to stop what it was doing every 3 secs and listen on wire.

REVISION 2: Ask and you shall receive

The code now incorporates the mega participating still in a MASTER MASTER scenario BUT it asks only when I am doing collision avoidance from each of the foot controllers.

This appears to be more stable, after roughly 2-3 minutes though depending upon where the arduino is in the code it will then lock.  Only the SHADOW controller will lock though as the nanos keep pinging away!

Here is the code used and differences:

On each SENSOR device I have the following definitions to help me remember what address is what as well as for the system to use these addresses as needed.

// ==========================================// This function determines I2C addressing // ==========================================#define I2C_ADDRESS_SHADOW  0x1#define I2C_ADDRESS_LEFT    0x2#define I2C_ADDRESS_RIGHT   0x3#define I2C_ADDRESS_DOME    0x4#define I2C_ADDRESS_CENTER  0x5#define I2C_ADDRESS_VOICE   0x6#define I2C_ADDRESS_BODY    0x7#define I2C_ADDRESS_TCAADDR 0x70 adafruit multiplexer

Then I simply within SETUP()

  #ifdef LEFTFOOT // If this is the leftfoot sensor slave
    Wire.begin(I2C_ADDRESS_LEFT);
    Wire.onRequest (requestSensorData);  // interrupt
    partnum=1;
    #ifdef PIRSENSOR
      pinMode(DS1P, INPUT);
      delay(2000); // calibrate for about 2 seconds
    #endif
  #endif

Configure this for each foot and voice controller, when you uncomment comment variables this tells the compiled code which device it is controlling.

LEFTFOOT, RIGHTFOOT and VOICE are all I use currently.

What the above does is when a request from SHADOW is made, it will call the function requestSensorData which is below:

void requestSensorData()
{
  uint8_t Buffer[4];
  Buffer[0]=cm[0];  // Send the IR Sensor from front
  Buffer[1]=cm[1];  // Send the IR Sensor from side
  Buffer[2]=cm[2];  // Send the IR Sensor from back
  Buffer[3]= pir;   // Send the PIR Sensor from ankle
  Wire.write(Buffer,4); 
}

The above basically reads in each sensor from the CM array as well as PIR state of HIGH or LOW and sends it across the I2C channel when asked.

This has prevented a lot of the issues BUT there are still lockups that occur.

on the SHADOW, there is similar setup to assign SHADOW an address but here is the code for it to ask.

void getFootSensorData()
{
  if (isR2Automation)
  {
    currentTime = millis();
    int sensortable[]={0,0,0,0};
    if ((currentTime - lastDecisionTime) >= PingWaitInterval) // Wait for PingWaitInterval and then send results
    {
      lastDecisionTime = millis();
      Wire.requestFrom(I2C_ADDRESS_LEFT, 4);    // request 4 bytes from slave device I2C_ADDRESS_LEFT
      for(int i=0;i<4;i++)
      { 
        int c = Wire.read(); // receive a byte as character
        sensortable[i]=c;
      }
        leftfront =  sensortable[0];
        leftside  =  sensortable[1];
        leftback  =  sensortable[2];
        leftpir   =  sensortable[3];
      #ifdef SHADOW_SENSOR
        Serial.print("\n");
        Serial.print("Left Foot Sensors: ");
        Serial.print(sensortable[0]);
        Serial.print('\t'); 
        Serial.print(sensortable[1]);
        Serial.print('\t'); 
        Serial.print(sensortable[2]);
        Serial.print('\t'); 
        Serial.print(sensortable[3]);
        Serial.print('\n');
      #endif
      Wire.requestFrom(I2C_ADDRESS_RIGHT, 4);    // request 4 bytes from slave device I2C_ADDRESS_LEFT
      for(int i=0;i<4;i++)
      { 
        int c = Wire.read(); // receive a byte as character
        sensortable[i]=c;
      }
        rightfront =  sensortable[0];
        rightside  =  sensortable[1];
        rightback  =  sensortable[2];
        rightpir   =  sensortable[3];
      #ifdef SHADOW_SENSOR
        Serial.print('\n');
        Serial.print("Right Foot Sensors: ");
        Serial.print(sensortable[0]);
        Serial.print('\t'); 
        Serial.print(sensortable[1]);
        Serial.print('\t'); 
        Serial.print(sensortable[2]);
        Serial.print('\t'); 
        Serial.print(sensortable[3]);
        Serial.print('\n');
      #endif
    }
  }


}

Testing Dome Panel and Utility Arm animations

Testing new code to trigger utility arms and dome panels to open and close in sequence.

Here is a video of the panels in action:

Wiring Issues Resolved: Interference in the sensors

Sensor issues continued to plague the project

When combining the front PIR sensors and the IR Sensors connected to the single Arduino NANO per foot... everything seemed to come together.

We could detect and track human motion (heat) as well as sense distance to the object (sonar) and this was going as planned until...

When moving R2 forward, no matter the throttle speed etc. and changing directions, after roughly 30 seconds or more... both Arduinos in the feet would LOCK UP.  No more sensor data etc.

There were many possibilities to this:

1. I2C code was not setup correctly
2. Not enough pull up resistance on the I2C lines. (need at least 10k ohm pull ups connected between the vcc (5v) and the SCL and SDA lines between the master in the body and the feet runs.
3. The I2C lines were not shielded enough so any interference knocked out the Arduino.
4. issues with the nano being too near the foot motors (these were running at 24v now).

Video Log of the findings

1. The code:

Reviewed several different approaches to I2C for Arduino, one person even re-wrote the wire library and called it ITW. 

I re-wrote the sensor code as well as the master shadow code to allow for this as it had a error correction built in that if the Arduino loses I2C connectivity and locks, it will unlock it and continue communications.  This didn't effect it much other than I saw the Arduino reboot over and over when moving R2 around.

2. Not Enough Resistance

The built in pull ups were fine at this point, because connecting 10k ohms and using hardware pull ups didn't appear to correct the problem either.

3. Shielded sensor lines BINGO!

So I had narrowed the issue down to the connections between the sensors and the Arduino itself.  On the foot there are 3 IR sensors and 1 PIR sensor. 

Eventually I foresee 5 IR sensors (to track if its near stairs etc.) as well as better granular front and back sensor array.

Replaced the DUPONT 4 wire connectors with shielded CMR cable... this did the trick, the extra extra-shielding provided the needed interference blocking as well as allowed the Arduino to run without crashing. 

Learn more: http://www.awcwire.com/productspec.aspx?id=shielded-multi-conductor-riser


The fun part was re-running several of the wires once again...

Here is a great shot of the DUPONT wires coming off the left-side foot.

These wires pick up the electrical currents when applying power into the motor controls and feedback enough to cause the Arduino to lock up.

The new shielded CMR cable with 4 lines and 2 ground wires.  These were perfect as the PING and PIR sensor needed 3 lines and the HC-04 IR sensors needed 4.

Here is another look at the wire stripped to reveal its internal shielding individually around the 2 pairs.

Once stripped and connected, applied female 3 pin DuPont ends to each and connected to the sensor pins on the Arduino shield.  Here is a closeup of the cmr cable with the insulation removed.

Once complete we connected them back to the Arduino and then back to the sensors.

here is a great shot of the new cable connected to the PING sensor and going back into the foot and battery box.