Robot Kit

[Blitzfx]

Been trying to load the code onto the oak but doesn't seem to work.

Now the LED has stopped blinking and I can't wirelessly see the Acorn thing anymore. Is it bricked now?
is there anything i can do with that pin 1/6 thing?

Also: https://github.com/digistump/OakRestore

Can I use an FTDI one instead of this CH340?

[driffster]

If it stopped flashing it should suggest your code did upload, if you loaded more or less the example code, which goes through the basic movements of the robot at 5 sec intervals  you should see the pin 1 LED turns on for at least 5 sec during that loop, which last about 35 secs. I would  remove the wing with all the connectors to the motor driver and battery and plug it in with usb power.  I had issue with my batteries being almost dead, the Oak had problems starting up.

Sometimes it would just never start the movement, but a reset (well removing and inserting back a battery) made it work.

Hope that helps

[Blitzfx]

plugged it into the robot with wing shield thing and it didn't do anything other than rotate one of the wheels forward every second. It was doing this before i even looked into programming it

[PeterF]

If you already have a FTDI based USB-to-Serial adapter... by all means... the advice for about getting a CH340/CH340G based one will be more for newcomers - especially as the real cheap boards may be using fake FTDI chips, thus more likely to be bricked or nagged by the FTDI driver nonsense.

With your Oak powered up, you can check if it appears on the Particle cloud dashboard - if it does - it isn't "bricked" - just the code isn't doing what you expect. https://dashboard.particle.io/user/devices

You could then do a simple test, and program the example code below. You should then get a blink from the user configurable led (not the main power one). You then know the Oak is working properly, and is accepting new programs - and you should be able to see status updates of this if you use the log view on Particle whilst programming - you will see start and success events.

Code: [Select]

// the setup routine runs once when you press reset:
void setup() {               
  // initialize the digital pin as an output.
  pinMode(1, OUTPUT); //LED on Model A   
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWrite(1, HIGH);   // turn the LED on (HIGH is the voltage level)
  delay(1000);               // wait for a second
  digitalWrite(1, LOW);    // turn the LED off by making the voltage LOW
  delay(1000);               // wait for a second
}

After that, I would reload the sample robot code, and double check your wiring... Let us know how you go!

[Blitzfx]

Didn't know that fake FTDI was a concern but thanks for the warning.

I went onto my dashboard and felt a little depressed at what i saw
. It's 27th Feb 10:08pm now.

I added the blink code to Arduino 1.6.5 anyway and at the end, it said
"Sending file to cloud, to flash to device... Device flashing started successfully."
Didn't say it successfully flashed it. Only started.

Right now only PWR is on. P1+ led isn't blinking anymore lol

I have an Arduino Uno lying around and looking into whether i can use that in place of a dedicated FTDI chip since I actually don't have one lying around. Otherwise I'll have to go on Ebay

-------------

Well it appears to have worked 

[PeterF]

Lovely! I don't think the Arduino IDE ever says it has successfully programmed an Oak, only that the process has started. You need to have the log view on the particle dashboard open to see that at the moment - I think somebody is working on improving that behaviour.

On the particle dashboard, you see the two icons on the left side (three if you count the logo as one!). The 3d cube is the overview / devices view, and the icon below (looks like a command prompt / terminal icon) is the log view (click on it to switch views). If you leave that view open, and start programming - you should see a a status message saying that programming has started, and another that says it is finished, and then messages saying that the device has disconneceted and is then connected again. I don't know how quickly it is programming for you... but I have had five minutes go by before it completes - with the Oak blinking it's light the whole time, so at least I know it's alive!

[driffster]

Well got my optic sensors up and running (on an Arduino).  I need to use interrupts to count the pulses, is there an interrupt number to pin number information somewhere for the Oak?

Meanwhile I uploaded some more code, but now my Oak stay online exactly 1 min before logging off and wont accept new code.

Now I got 0 Oaks working, got more of them unpacked, but I'll wait out for the next version.

[PeterF]

Driffster, did you also upgrade to v0.9.4, or are you on v0.9.3 still? I haven't been fortunate (!!) enough to have that sort of error - disconnect after loading a program... After the inital hurdles of getting it configured and programmable, my two Oaks that have been pressed into service are co-operating nicely.

Regarding interrupts, haven't used them myself yet, but according to the ESP8266 Arduino docs : "Pin interrupts are supported through attachInterrupt, detachInterrupt functions. Interrupts may be attached to any GPIO pin, except GPIO16. Standard Arduino interrupt types are supported: CHANGE, RISING, FALLING." [1]

---
[1] https://github.com/esp8266/Arduino/blob/master/doc/reference.md

[driffster]

Well I am using arduino IDE 1.6.7 and have the Oak 0.9.3 installed, it wont show an update to 0.9.4 in the board manager. Did you install 0.9.4 manually?

[PeterF]

Nope... didn't go near it, and it was pulled to due to unexpected issues. So sounds like you have the same setup as me - I'm on Arduino IDE 1.6.7, and stuck with v0.9.3 Oak, and (touchwood) haven't had that issue. Drats!

[Blitzfx]

I had 1.9.4 through the board manager and I wouldn't recommend trying to install it right now

[driffster]

Well I restored it and now it is back on the cloud and accept code again. Can go back to actually programming those encoders, tomorrow!

[PeterF]

One down, one to go!

Further on interrupts, I have the following code running on guinea pig... er... Oak #2... with a 'scope connected to Pin 1 for the output (although for less than 10hz signals, the LED will do), and its signal generator connected to Pin 2. Running a 5hz signal at 50% duty, interrupt is firing fine, and LED on P1 is blinking happily. Seems pretty reliable... is only seemed to miss one pulse at the start, and hasn't missed a beat since. Pushed the sig generator all the way up to 10khz, and interrupt still seems to be firing properly. Now to tell it to program again and see if it breaks

So I can state that interrupts do appear to work fine!

Edit: And that whilst the Oak did respond to the programming request... it didn't seem to be loading any code (P1 wasn't blinking to indicate data packets downloading), so I disconnected the scope/sig generator (so nothing plugged into the Oak), and power cycled it. It registered on Particle again, and started programming when I told it to.

Code: [Select]

volatile int state = LOW;

void blink()
{
    state = !state;
}

void setup()
{
  pinMode(3,INPUT);
  pinMode(1,OUTPUT);

  attachInterrupt(digitalPinToInterrupt(3), blink, CHANGE);
}

void loop()
{
    digitalWrite(1, state);
}


[Blitzfx]

i was trying to program my board with the example robot code and it took me 3 tries lol



Im a bit worried this will brick it one day. .

Also, it's not broadcasting itself on wireless anymore, but it still connects to the particle cloud.
Can you see yours on the wireless network?

[Russ Barr]

It look to me that the analogWrite() function takes a number between 0-1023 not 0-255 since this is not an 8 bit PWM.  You must change all 255 to 1023 in the code where analogWrite is used. Even where there is a direction change  analogWrite(0, 255 - botSpeed);  this needs to be  analogWrite(0, 1023 - botSpeed);