Digistump Forums
The Oak by Digistump => Oak Support => Topic started by: Blitzfx on February 19, 2016, 11:02:07 pm
-
Hi,
Sorry if this is answered somewhere or if an email was already sent out but, is there a manual for getting started for the robot kit? (pledged $43 or more)
Everything came in the mail and I'm not really sure where to start :P
-
digistump.com/wiki/oak - click on Robot Kit near the bottom, it still has some specifics more for the Digispark Pro then the Oak but it is mostly universal for both
-
In your robot tutorial: http://digistump.com/wiki/digispark/tutorials/robot
where do these go? (http://puu.sh/ng26m.jpg)
-
I've not got the kit, so only guessing.
They look like encoder wheels to use with optical sensors so the oak could be set to analyse the speed and position of each wheel. Since they are not in the main instructions (although they can be seen in the bag in instructions photo), they must be optional parts for advanced play and experimentation. They look from photos that they attach on the opposite side of motor to the wheel... on the axle that sticks out with nothing attached. These axles line up with slots in the base which the encoder wheels presumably pass through. Not sure where the optical sensors mount, but hopefully that will become apparent if you get the encoder wheels in place (they sit round the wheels and trigger when the slots pass). Did you get optical sensors in the kit too?
-
I think you're right about the encoder but I wasn't 100% sure.
There's a weird extrusion from the motor chassis (facing outwards) but it's fully enclosed which makes me think maybe there's some capacitive sensor in there or something. I don't know.
This is what I have left basically:
(http://i.imgur.com/YBfHKpw.jpg)
(http://i.imgur.com/0ghwQRe.jpg)
(http://i.imgur.com/sLGeFWi.jpg)
No idea which motor goes to A and which goes to B. Instructions didn't say whether the left or right went to A / B
Now I have to go learn and find out how to program it. Not looking forward to it since I keep seeing all these firmware issues mentioned in the kickstarter updates and forums here.
-
So you have no optical sensors? Presumably that is why the encoder wheels aren't mentioned. Suspect the base, motors, wheels, encoders etc, are a pre-bought kit from elsewhere, and the electronics are supplied by Digistump and added to the base to make a robot kit. The reason the encoders are there is because they were part of the hardware kit Erik bought. Looks like Erik chose not to add optical sensors to the electronics parts he added, but you could always add those yourself.
Suspect the bulge on the motor casing is just the axle or part of the motor. Wouldn't expect capacitive sensor in there.
I did wonder if the little cut outs on either side of the encoder wheel slot where designed for the optical sensor to slip down over the encoder wheel from the top. Clearly in the Digistump tutorial, they put a cable tie across there instead to tidy up the cables. However this is just guessing since I can't see where the encoder wheels come to in relation to the slots in the base. Maybe try adding the encoders to the motor, then take a photo for us to see how that looks. maybe we can then work out between us how it should look.
-
The encoders aren't an interference fit so I'm not going to bother mounting them.
(http://i.imgur.com/MsAtEkk.jpg)
(http://i.imgur.com/bmBZJGb.jpg)
-
Yes encoders are included because they came with the robot kit parts from the factory, and we figure some people may want to make use of them, even though we didn't order them and don't use them in our build. Sorry for any confusion.
-
Yeah from the photos, I'm pretty sure the sensors would be designed to drop in from the top of the baseboard over either side of the encoder wheels.
Could be a nice upgrade at a later date assuming you can find sensors with the right dimensions to push into the slots.
Mike
-
No, there won't be any capacitive sensors in there - they are just plain DC motor shoved into a small gearbox (which probably slows them down) and which also changes one shaft into two - one sticking out each side. Do they turn in opposite directions by any chance? Or both the same way?
You could possibly make your own sensor for that out of a led and a light sensor - stick the LED on the middle side, and the light sensor on the side of the motor casing. You'd want to drop some glue on motor shaft then to make sure that encoder wheel doesn't move! lol
Pete
-
Have you been able to make it work using the example code? (basicrobot or the code from http://digistump.com/wiki/digispark/tutorials/robot)
I have found that the original code used 255 as max analog value, which is actually 1023 on the Oak. Quickly noticed that by measuring the voltage at the pin was 25 % of what was expected.
I will have to tweak the values a bit for forward and reverse, the motors are not going on at the same speed.
-
That doesn't sound right - range for analogWrite is supposed to be 0 - 255, with 0 being always off, and 255 being always on, and anything in between being the on/off duty cycle. So in other words, analogWrite(0,255) should be no different whatsoever to digitalWrite(0,HIGH). If you're getting different responses, then that is a bug that needs to be reported.
EDIT: Checked it out with a multimeter and 'scope - and you are spot on... it is not fully on when 255, but instead at 1023. A quick search of why points to a define statement in the ESP8266 core, so it was a deliberate choice (and annoyance to all documentation and code that uses the standard 255 as full on). https://github.com/esp8266/Arduino/issues/295 (https://github.com/esp8266/Arduino/issues/295)
Tweaking the values is normal - the motors are never perfectly matched. That's where the encoders can come in handly, as they give you the feedback as to how fast the motors are turning, so given the right code, you can get the motors to basically 'sync themselves'.
-
I been working mostly with Teensy and Arduino so 256 was actually strange for me ;)
Actually got some nice sensor for the encoder, a perfect match for the cavity, would only need screw hole to make it perfect. It's from an old spectrometer from the university, I will have to scavenge a few more.
The neat thing is I actually need to do a custom encoder for my work so doing it for the robot will be a useful exercice.
-
thanks for confirming that. Looks good. Just need to get some suitable part numbers options for a sensor upgrade, and then some code samples for everyone...
-
That's unfortunate. We have boxes of optos of various sizes we throw out from old projects that no-one needs anymore.
At this rate, why not just go all out and use stepper motors.
-
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?
-
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
-
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
-
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 (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.
// 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!
-
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
(http://puu.sh/nnb6e.png). 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 :P
-------------
Well it appears to have worked ;D
(http://i.imgur.com/MlIPV1V.jpg)
-
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!
-
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.
-
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 (https://github.com/esp8266/Arduino/blob/master/doc/reference.md)
-
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?
-
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!
-
I had 1.9.4 through the board manager and I wouldn't recommend trying to install it right now
-
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! :)
-
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.
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);
}
-
i was trying to program my board with the example robot code and it took me 3 tries lol
(http://puu.sh/npDJe.png)
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?
-
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);
-
@Blitzfx: No... it only broadcasts as an AP when in config mode - which it should only be in when you first power it up, or if it looses it's connection to Particle for a while. Rest of the time, unless your sketch programs it otherwise, it runs as a client only. I don't really think you can brick it by uploading code, unless the code itself bricks it. And Erik is still working on making that foolproof. I've had two fails. First one it recovered and started programming again. Second time, I pulled the power so it failed, and it programmed ok when I reconnected it.
@Russ: yeah... that is a bit of a rude awakening. If we had been programming ESP8266 boards via Arduino, we'd be familiar with it already, but not when coming from plain 'ol Arduino.
-
Well it appears to have worked ;D
(http://i.imgur.com/MlIPV1V.jpg)
Could you elaborate on your setup? I'm catching the obvious:
- green1: arduino TX -> oak pin3/RX
- orange1: arduino RX -> oak pin4/TX
- blue: looks like ground to pin1 or pin2
- green2: 3.3V arduino -> oak Vin?
- yellow: grounding arduino reset pin?
- orange2: arduino ground to oak ground?
Also, what did you do with this? Did you use it to restore or flash a sketch?
I'm looking to do something similar as I have an Arduino *now*, but my 3.3v UART doesn't show up until Sat :)
Thanks!
Edit: well, I just took the leap and went for it. After a bunch of errors with esptool.py not finding the board, I took a shot in the dark and switched my tx/rx pins. It worked! Re-looking at your picture, it looks like you're doing the same, actually. Am I right that this is the setup?
| arduino | oak |
|---------+-------------|
| gnd | gnd |
| 3.3v | Vin |
| TX -> 1 | pin 4/TX |
| RX <- 0 | pin 3/RX |
| | gnd to pin2 |
-
It makes sense as the arduino µprocessor is not involved in the process : you are just using the usb to serial part of the arduino board.
Just make sure the sketch running on the arduino doesn't do anything with the TX/RX pins.
-
Well it appears to have worked ;D
(http://i.imgur.com/MlIPV1V.jpg)
Could you elaborate on your setup? I'm catching the obvious:
- green1: arduino TX -> oak pin3/RX
- orange1: arduino RX -> oak pin4/TX
- blue: looks like ground to pin1 or pin2
- green2: 3.3V arduino -> oak Vin?
- yellow: grounding arduino reset pin?
- orange2: arduino ground to oak ground?
Also, what did you do with this? Did you use it to restore or flash a sketch?
I'm looking to do something similar as I have an Arduino *now*, but my 3.3v UART doesn't show up until Sat :)
Thanks!
Edit: well, I just took the leap and went for it. After a bunch of errors with esptool.py not finding the board, I took a shot in the dark and switched my tx/rx pins. It worked! Re-looking at your picture, it looks like you're doing the same, actually. Am I right that this is the setup?
| arduino | oak |
|---------+-------------|
| gnd | gnd |
| 3.3v | Vin |
| TX -> 1 | pin 4/TX |
| RX <- 0 | pin 3/RX |
| | gnd to pin2 |
Yeah I found that I had to swap the TX and RX around. Everything else is the same. You can connect the 3.3V to VCC as well . doesn't make much difference. Do not EVER connect the 5V from the arduino to VCC on the oak.
like deuxvis said, it's just turns the arduino into a simple UART converter and shuts off the micro. in other words, it just piggy backs off the onboard uart converter that would normally be used to communicate with the arduino.
The purpose of the yellow wire is to put it into persistent reset mode.
The blue wire is supposed to put the oak into bootloader mode or something I think. Forgot what he described it as. It's all here: https://github.com/digistump/OakRestore
-
Makes you stop and think for a few minutes, doesn't it! Yes, as Blitzfx and DeuxVis commented, the TX & RX are backwards for use this way as the TX and RX on the arduino usually refers to talking to the Arduino chip, not the USB-to-Serial UART that talks to it. So as long as you have the arduino programmed to do something that doesn't use the Serial pins, you can use it as a handy USB to Serial. Even easier, if you have a board like Blitzfx's, is to simply pull the processor out, and it doesn't matter what code it was running.
-
For others who stumble on this, I took my experience and a few hours of head scratching about why in the world TX/TX and RX/RX works for the wiring and wrote up a tutorial (http://digistump.com/wiki/oak/tutorials/serial_through_arduino). I hope it's useful to someone.
Thanks to @deuxvis for giving some helpful input/feedback in the github issue (https://github.com/digistump/OakCore/issues/56) I posted about this.
-
Great write-up jwhendry! Very nice, and well explained!
Just FYI, the reason that other people will haven't had problems with 5v on the IO is probably because the ESP8266 I/O pins are protected by a snap-back circuit. The chip runs at 3.3v, but just like the nrf24L01+, has 5v tolerant I/Os. From the datasheet (https://www.adafruit.com/images/product-files/2471/0A-ESP8266__Datasheet__EN_v4.3.pdf)(bottom of p17):
All digital IO pins are protected from over-voltage with a snap-back circuit connected between the pad and ground. The snap back voltage is typically about 6V, and the holding voltage is 5.8V. This provides protection from over-voltages and ESD. The output devices are also protected from reversed voltages with diodes.
-
@pfeerick: I caught that too when I asked at the github issue (https://github.com/digistump/OakCore/issues/56) I created to inquire about using an arduino for UART. Evidence (also found the datasheet) indicated it was fine, but the official docs say to use 3.3v so it had me spooked. While the ESP8266 has these features, I didn't know if whatever the Oak adds on top of it was? Anyway, I took the gamble and it indeed appears to be fine :)
Thanks for taking a look at the wiki and for the kind words!
-
No worries. I think the idea is to stick with 3v3 generally as it is a 5v part, but if you have just the one annoying sensor that has 5v I/O and you can't be bothered doing level shifting, you can cheat. Or things like the infrequent Serial Tx using a 5v UART. I'd be interested to see Erik's response to this, but I don't think the Oak (or Acorn really, as the Oak is just the carrier board) does anything that would alter the I/O voltage tolerances. The only problem would be that the Oak could accept 5v logic in, but would only be putting out 3v3 logic - so the device on the other side would need to accept 3v3 as being a logic high state. This shouldn't normally be a problem, but there will always be edge cases where it is, and specific sensors/parts that just won't work. Hence the level shifter board.
Hey, no problems! Glad to see someone else putting stuff on the wiki... more the merrier... gotta get all the good juicy info and ideas flowing!