Resurrecting the dead

I am STILL not dead. Yup, it's been a long time since the last post. Had some very messy personal stuff to take care of. Like a jigsaw puzzle, I think I have a lot of the pieces put back together. Enough about the negative stuff. Let's get back to technology. I will be expanding the scope of this blog to not only include Arduino, but my adventures with Raspberry Pi and Orange Pi. Perhaps some Python development, Perhaps some Java. I will have to learn both languages and you, my dear and long-suffering readers, can follow along.

So, to recap- 
1) Blog will still be Arduino
Also
2) Raspberry Pi
3) Orange Pi
4) Python
5) Java

I have some work to do to re-establish a small development area, but I am working on that. I'm not sure if it will be interesting enough to include, but we will see.

I am also considering a Patreon account to help with the funding, so if I get that started, there will be some information in here and some in the Patreon account. I'm still figuring that out, but I need some funding to help these projects along.

I haven't even figured out what my posting schedule will be. I need to set up the development area first.

That's enough for tonight. Do have a good evening.

Power

Well, the timing issues are resolved to some extent. I was able to control direction and right or left wheel decisions. Unfortunately, it seems I now have a power issue.

I have a 9-volt battery powering the processor, so if the motors drag the battery pack down too much, the processor won't attempt a restart. I experienced that with a Basic Stamp and someone else (I wish I could remember who) told me what the problem was. Processors get their own battery from now on.

The problem that I have experienced is that the 9-volt battery pack, powered by six 1.5 volt AA cells, is a little weak to power two motors at the same time. This design calls for four motors to run simultaneously. I don't have the power for that.

I have a 12-volt gel-cell that I think would do the job, except it would over-power the servo motors. I may try a battery for an R/C race car and see if it delivers better power. The gel-cell is pretty heavy for this chassis and motor torque. In addition, I will build a bus for the power in an attempt to keep a larger-diameter conductor in the power circuit.

More news as it happens. In a future post, I will also talk about modifying the VEX Tumbler design.

Timing

Well, everyone says it's all about timing. Sometimes, it is.

In this case, the timing is down to milliseconds.

The project at hand is making a VEX platform run with an Arduino microcontroller. Should be simple enough. I looked up the specs for the VEX 3-wire servo motor and found that to control direction and speed is:
• PWM Input:1ms - 2ms will give full reverse to full forward, 1.5ms is neutral

• Dead Band:1.47ms - 1.55m

Simple enough- the dead band yields no revolutions, everything below the dead band turns the motor one direction and everything above turns it another within the 1ms and 2ms ranges. I selected a couple of pins for PWM on the Arduino and wrote some code using the analogWrite() command and worked within 1.00 and 2.00 ms. Or so I thought.

It didn't work.

I stripped the code down to writing directly to a pin with a particular value: analogWrite(10,1.50) and could not make it work. It just would not work.

Well, after getting some assistance, it appears the command should have been analogWrite(10,150) and the range was 100-250 with about 190 as neutral and about 180 to 200 as the dead zone. It's probably closer than that, and maybe I will research it further later, but for now, we are in the ballpark.

There will be more work to do- the motor runs faster in the 120-180 range than it does in the 200-250 range. It also runs in a different direction on each side of neutral, but one way is "forward" and the other is "reverse". I use the quotes because "forward" and "reverse" depend on which side of the chassis the motor is mounted. To move the robot forward, one motor runs "forward" and the other "reverse". at the same absolute value from neutral, the different directions run different speeds.

The result is that with the motors running different speeds, a straight line run becomes very difficult to maintain as the robot will turn in the direction of the slower wheel.

I have more work to do- running two motors draws more current than my circuit wants to deliver and this is a four motor platform.

And we missed the RoboRama because neither my son nor I had a running platform. Not even for show and tell or VEX unlimited class. I really wanted to get this VEX platform running; after all, VEX was kind enough to give it to me- I should get it running.

Pictures soon.

Your Host

Arduino VEX

No, I am not dead. And neither is this blog. Yes, there has been a lull in the action lately; OK, for a long time. A friend once told me that "That work junk sure gets in the way of a lot of stuff!" He was right. Work has been overwhelming lately. I won't go into details as that is out of scope for this blog, but work has sapped my creative juices for many months now. I put some big issues to bed and hopefully can do some creative things now.

I would like to thank you for reading my post. I hope to post more often in the future.

Last fall the Dallas Personal Robotics Group (dprg.org) visited Innovation First International( http://www.innovationfirst.com/ ). makers of the VEX Robotics Design System ( http://www.vexrobotics.com/ ).  We were treated to an outstanding tour of the facility, met the executives and were generally wowed and overwhelmed. The IFI folks were kind enough to hand out some valuable  kits as we left. It was my understanding that we (the DPRG folks) were to take the kits and stress them somewhat. It seems that the kids in competition won't stress the kits. It would appear that stressing a kit to the point of failure would keep a school VEX team out of competition, so I can see why they don't do it. Our competitions are different, without so much on the line, so IFI has asked us for some stress testing.

I am getting to an Arduino tie-in here...

In particular, the IFI guys were interested in VEX robots running on some other processors, including Arduino. As I am one of "the Arduino guys", I received a VEX Protobot kit. This solves a major problem for me in that I find the programming kind of easy, but the engineering is problematic for me. With a rolling platform in kit form, the hard work (for me) is done. All I have to do is wire it up and program it. Right.

So, the project needs a name. VEX-duino? Maybe not.

I used the Protobot kit to build the tumbler chassis. It is a steel chassis with four servo motors driving four wheels. It was a simple enough kit to assemble. I will cover more as I move along, but the robot is a tumbler with an Arduino microcontroller and the first task will be to build it for competition in the "Square Dance" event for RoboRama 2011a- a twice-yearly event offered by DPRG. Rules are here: https://docs.google.com/document/pub?id=1NqZZQ4MnlD9Y1EGsEvkvKFXNPVXpH45YAd_l338y-3o&pli=1

More on this project later.

Once again- thanks for reading!

Your host

IFI Field Trip

No, I am not dead; just having some trouble getting forward motion on the Arduino project. Work has kept me underwater for some time- I haven't been able to post to TheNonProfitDirector.blogspot.com for a few weeks. There will be posts there soon as there has been a lot of activity at work.

What happened today was an absolutely wonderful field trip to Innovation First International (IFI) in Greenville, Texas. IFI has multiple product lines at the World Headquarters in Greenville: Rack Solutions that designs and produces custom solutions for rack mount problems, HEXBUG and the VEX robotics platform. As a member of the DPRG field trip to IFI, we were most interested in the VEX line, but I would be remiss if I did not mention that they apply rapid prototyping to their development; extremely rapid prototyping that can shut down production equipment for a special run on the prototype for development. They also produce toys in the HEXBUG line that they conceive and develop in a month or so and then send the product overseas for tooling setup.

The VEX line is primarily focused on education; robotics education, that is. It's a terrific teaching tool that has roots in E-Systems and Erector sets. What has come out is an extremely flexible system of engineering a robot (or robots) that can be developed by a middle-school student.

IFI was extremely generous with their time and their products during our visit. They took the time to answer all of our questions and provided us with a guided tour of the entire facility. Before we left, those that were interested were allowed to take home Cortex and ProtoBot bundles.

I will be blogging here on the use of the Arduino with the ProtoBot. IFI has asked that we provide feedback to them if we take a VEX product with us. That's a deal that is hard to beat.

So, hats off to Bob and the gang at IFI- thank you for hosting us and providing a tour of your facility! It is my hope that IFI and DPRG will have a long history together.

Still alive and well

Just a short post to let you know this blog is still alive and well. Activity on the Arduino project has been swallowed up in work assignments. There is some urgencyin getting this class finished, so I am hoping ot have more fun and games posted soon!

Thank you for your patience!

More Arduino Reading Optical

Here's a code snippet for you, all dirty and messy. It will be cleaned up prior to inclusion in the class. Currently working on including the TSL230R Light-to-Frequency Converter with code shamelessly borrowed from:
http://roamingdrone.wordpress.com/2008/11/13/arduino-and-the-taos-tsl230r-light-sensor-getting-started/

I will probably use the code as-is. It handles this device as an interrupt process, and handling interrupts was an intention of the class.

I have this mystery phototransistor from Tanners. No datasheed can be found by several people working on int and Tanners sells the item "No data". It looks like a TO-18 case with a glass top, so I will assume that the connections are the same. It has a base pin, it would seem, which I thought was odd as I thought that that base was controlled by light. I have several, so I will experiment with a few, but I'm not sure how I will know if I have destroyed one or not. I think I may skip this one for another day and leave it out of the class.

----- Code 4 You  -------

/*
IR1
*

detects moving infrared with PIR. Upon sensing, checks light level with Light Dependent Resistor (Cadmium photocell) and then uses infrared rangefinding to determine range of object.

*/


int IRrangePin = 0; // select the input pin for the potentiometer
int inPin = 1; // select pin for IR detector (analog)
int LRpin = 2; //select analog pin for LDR
int ledPin1 = 13; // select the pin for the LED
int ledPin2 = 12; // second led
int ledPin3 = 11; // third led
int val = 0; // variable to store the value coming from the sensor
int dval = 0; // variable to store valud from IR detect
int Lval = 0; // Variable for use with LDR
int NewVal = 0; // Work variable



void setup() {
Serial.begin(9600);
Serial.println("Setup. ");
pinMode(ledPin1, OUTPUT); // declare the ledPin1 as an OUTPUT
pinMode(ledPin2, OUTPUT); // declare the ledPin2 as an OUTPUT
pinMode(ledPin3, OUTPUT); // declare the ledPin3 as an OUTPUT
pinMode(inPin, INPUT); // declare the Infrared detect pin as an INPUT
pinMode(LRpin, INPUT); // declare teh LDR pin as an INPUT
digitalWrite(ledPin3, LOW); // full on
}

void loop() {
dval=LOW;
detect();
val = analogRead(IRrangePin); // read the value from the sensor

/*
Serial.print("Proximity: "); Serial.println(val);
digitalWrite(ledPin1, HIGH); // turn the ledPin on
delay(val); // stop the program for some time
digitalWrite(ledPin1, LOW); // turn the ledPin off
*/
delay(val); // stop the program for some time
}


void detect()
{
delay(100);
dval = analogRead(inPin); // read input from IR detector
//Serial.print(dval);
if (dval>0)
{
Serial.println();
Serial.print(" Detection >YES. ");
digitalWrite(ledPin2, HIGH); // turn the ledPin on
LDR();
findRange();
}

if (dval<=0)
{
Serial.print(".");
digitalWrite(ledPin2, LOW); // turn the ledPin off
}
delay(200);
}


void LDR(){
Lval = analogRead(LRpin);
Serial.print(" LDR: "); Serial.print(Lval); Serial.print(" ");
analogWrite(ledPin3,(75+Lval));
delay(100);
}


void findRange(){
val = analogRead(IRrangePin); // read the value from the sensor
NewVal = val/100;
Serial.print("Proximity: "); Serial.print(val);

switch (NewVal) {

case 0:
//far away
Serial.print(" Too far. ");
break;
// break is optional

case 1:
//do something when var == 1
Serial.print(" Zone 1. ");
break;

case 2:
//do something when var == 2
Serial.print(" Zone 2. ");
break;

case 3:
//do something when var == 3
Serial.print(" Zone 3. ");
break;

case 4:
//do something when var == 4
Serial.print(" Zone 4. ");
break;

case 5:
//do something when var == 5
Serial.print(" Zone 5. ");
break;

case 6:
//do something when var == 6
Serial.print(" Zone 6. ");
break;

case 7:
//do something when var == 7
Serial.print(" Zone 7. ");
break;

default:
// if nothing else matches, do the default
// default is optional
Serial.print(" Unknown. ");
}

Serial.println();
digitalWrite(ledPin1, HIGH); // turn the ledPin on
delay(val); // stop the program for some time
digitalWrite(ledPin1, LOW); // turn the ledPin off
delay(val); // stop the program for some time

}