Luteijn/Vortex: Difference between revisions
No edit summary |
|||
| Line 254: | Line 254: | ||
==== IRreceiver ==== | ==== IRreceiver ==== | ||
Since DFrobot also have a 'loose' IR-receiver module in their program, decided to just see if the example sketches for those would transfer, and they do. | Since DFrobot also have a 'loose' IR-receiver module in their program, decided to just see if the example sketches for those would transfer, and they do. | ||
https://www.dfrobot.com/product-366.html - A remote similar to the one pictured on the DFRobot product page actually came with one of my RTLSDR sticks, and seems to work well enough. | https://www.dfrobot.com/product-366.html - A remote similar to the one pictured on the DFRobot product page actually came with one of my RTLSDR sticks, and seems to work well enough, although the range isn't great, couple of meters. With a 'proper' remote control, e.g. from a TV, the range is fine, 10m at least when pointing at unit from across the house. Might be less if using reflections to try to control a roving robot. | ||
So, using the IRremote library you can read values from a remote controller: | So, using the IRremote library you can read values from a remote controller: | ||
| Line 326: | Line 326: | ||
The files to play can be put on the Vortex via usb, seems the little switch next to the micro-usb socket switches this between the mp3-players mass-storage and the arduino usb-serial interface. The number passed to the player is just the index into the (FAT?) table of stored songs. So, be careful of the order these are uploaded to the memory in. | The files to play can be put on the Vortex via usb, seems the little switch next to the micro-usb socket switches this between the mp3-players mass-storage and the arduino usb-serial interface. The number passed to the player is just the index into the (FAT?) table of stored songs. So, be careful of the order these are uploaded to the memory in. | ||
https://www.dfrobot.com/product-1121.html , documented at https://www.dfrobot.com/wiki/index.php/DFPlayer_Mini_SKU:DFR0299 is a mini-MP3 player form DFRobot. It is controllable over serial, and might be the same one as used in the Vortex. Would be good to figure out if the 'busy' signal is connected back to the arduino somewhere in that case. Player could also be a variant but the magic numbers more or less match (although the stop command 0x16 is not in the table. Perhaps Dec16 / 0x0A (standby/low power mode) was meant? | |||
Documentation for this miniplayer mentions the instruction format to be: | |||
{| class="wikitable" | |||
|+ Format: $S VER Len CMD Feedback para1 para2 checksum $O | |||
|- | |||
| $S | |||
| Start byte 0x7e | |||
| Each command begins with 0x7e ('~') | |||
|- | |||
| VER | |||
| Version information | |||
| Version seems to be 0xff from the example | |||
|- | |||
| Len | |||
| the number of bytes | |||
| Start, End and Checksum are not counted, | |||
|- | |||
| CMD | |||
| Commands | |||
| See command table, but | |||
|- | |||
| Feedback | |||
| Command feedback | |||
| 1: feedback, 0: no feedback ; need to test what this does, might mean 'echo' | |||
|- | |||
| Para1 | |||
| Parameter 1 | |||
| Query high data byte | |||
|- | |||
| Para2 | |||
| Parameter 2 | |||
| Query low data byte | |||
|- | |||
| checksum | |||
| Checksum | |||
| accumulation and verification, doesn't include start byte. Seems to be 2 bytes from the example given in the docs, but Vortex seems to just not need it put in. example given is 7e ff 06 09 00 00 04 ff dd ef | |||
|- | |||
| $O | |||
| End byte | |||
| End of command is signaled with 0xEF | |||
|} | |||
Code to calculate the checksum from the Library supporting the miniplayer: | |||
<pre> | |||
uint16_t DFRobotDFPlayerMini::calculateCheckSum(uint8_t *buffer){ | |||
uint16_t sum = 0; | |||
for (int i=Stack_Version; i<Stack_CheckSum; i++) { | |||
sum += buffer[i]; | |||
} | |||
return -sum; | |||
} | |||
</pre> | |||
====Eyes==== | ====Eyes==== | ||
Revision as of 12:52, 31 January 2018
Project "Vortex":
| Project Luteijn/Vortex | |
|---|---|
| |
| Status | In progress |
| Contact | Luteijn |
| Last Update | 2018-01-31 |
I've got four DFRobot 'Vortex' units. Basic programming via the official apps is possible, but rather limited. The WhenDo app is only available on iPad. Luckily, the internal Arduino clone can be directly programmed too. Unfortunately, not all the specs seem to be available, but there are some examples to work with, although they have a quite a bit of 'magic numbers' in them. These examples might disappear, so duplicating them here, with my own notes as available. The examples-coding is mostly done by "Andy Zhou <Andy.zhou@dfrobot.com>", although I did change some of the things to figure out what they do.
https://www.dfrobot.com/wiki/index.php/Vortex_Arduino_Coding_Tutorial_V1.0#Introduction
(Chinese page seems to have a bit better documentation, although English page might be easier to read and it is interesting to compare the differences)
Motor Control
Simple 'enable' and 'direction' pins for left and right wheels. Enable can be PWM'd or just full on. This example revs up the engines with PWM.
int E1 = 5;
int M1 = 9;
int E2 = 6;
int M2 = 10;
void setup()
{
pinMode(M1, OUTPUT); // directional controls, High is forward, Low is backward
pinMode(M2, OUTPUT);
}
void loop()
{
int value;
for(value = 0 ; value <= 255; value+=5) //foreward
{
digitalWrite(M1,HIGH);
digitalWrite(M2, HIGH);
analogWrite(E1, value); //PWM Speed control
analogWrite(E2, value); //PWM Speed Control
delay(30);
}
for(value = 0 ; value <= 255; value+=5) //backward
{
digitalWrite(M1, LOW);
digitalWrite(M2, LOW);
analogWrite(E1, value); //PWM Speed control
analogWrite(E2, value); //PWM Speed Control
delay(30);
}
}
Encoders
The two external interrupts are linked to encoders that track wheel movement, so it is possible to detect the Vortext is being pushed/pulled/turned, although I don't think these things indicate which direction the robot is pushed in...
#define pinInputLeft 0
#define pinInputRight 1
long leftPul,rightPul;
void leftCallBack(){
leftPul++;
}
void rightCallBack(){
rightPul++;
}
void initDdevice(){
pinMode(5,OUTPUT);
pinMode(6,OUTPUT);
pinMode(9,OUTPUT);
pinMode(10,OUTPUT);
noInterrupts();
attachInterrupt(pinInputLeft,leftCallBack,CHANGE);
attachInterrupt(pinInputRight,rightCallBack,CHANGE);
interrupts();
}
void motorDebug(){
digitalWrite(5,HIGH);
digitalWrite(6,HIGH);
digitalWrite(9,HIGH);
digitalWrite(10,HIGH);
}
void printPul(){
Serial.print(leftPul);
Serial.print(" ");
Serial.println(rightPul);
leftPul = 0;
rightPul = 0;
}
void setup() {
initDdevice();
Serial.begin(9600);
motorDebug();
}
void loop() {
printPul();
delay(500);
}
Analogue Inputs
six 'grayscale' detectors are placed around the bottom of the Vortex, to be used to track a line, maybe read simple codes from the floor.
2 (a2) 3 (a1)
1 (a3) 4 (a0)
5 (a6) 6 (a7)
This is the example sketch to dump the values read by the 6 little eyes.
void setup(void){
Serial.begin(9600);
}
int analogBuf[6] = {'\0'};
void loop(void){
analogBuf[0] = analogRead(3);
analogBuf[1] = analogRead(2);
analogBuf[2] = analogRead(1);
analogBuf[3] = analogRead(0);
analogBuf[4] = analogRead(6);
analogBuf[5] = analogRead(7);
for(int i=0;i<6;i++){
Serial.print(i+1);
Serial.print(": ");
Serial.print(analogBuf[i]);
Serial.print(" ");
}
Serial.println();
delay(500);
}
Wonder what's connected to A4 and A5, if anything.
LEDs
12 RGB (GRB!) leds can be addressed. Example from website causes Red and Green to be swapped. initialize library differently:
FastLED.addLeds<WS2811, DATA_PIN, GRB>(leds, NUM_LEDS);
IR example below uses some of the LED functionality.
IR obstacle detector
Seems to be somewhat flaky. Needs a bit more work to figure out. Also, the IR sensor might be useful to read IR remote controllers or beacons. This receiver seems to work at 38kHz, but probabbly also reacts to 36-40kHz. Remote controllers often work at 36kHz. Note that 2x 8µs delay doesn't give you 38kHz, but the digitalWrite itself also induces quite some delay (3-6µs), so seems this is bringing the total period up to around the 26.something µs we'd expect.
#define NUM_LEDS 12
// Data pin that led data will be written out over
#define DATA_PIN 13
CRGB leds[NUM_LEDS];
#define IR_IN 7//IR receiver pin
#define L_IR 8 //left ir transmitter pin
#define R_IR 12 //right ir transmitter pin
int count;
void leftSend38KHZ(void){//left ir transmitter sends 38kHZ pulse
int i;
for(i=0;i<24;i++){
digitalWrite(L_IR,LOW);
delayMicroseconds(8);
digitalWrite(L_IR,HIGH);
delayMicroseconds(8);
}
}
void rightSend38KHZ(void){//right ir transmitter sends 38kHZ pulse
int i;
for(i=0;i<24;i++){
digitalWrite(R_IR,LOW);
delayMicroseconds(8);
digitalWrite(R_IR,HIGH);
delayMicroseconds(8);
}
}
void pcint0Init(void){//init the interrupt
PCICR |= 1 << PCIE2;
PCMSK2 |= 1 << PCINT23; //pin D7 is int23
}
ISR(PCINT2_vect){//IR decoder interrupt
count++;
}
void obstacleAvoidance(void){
char i;
count=0;
leds[5] = CRGB::Green;
FastLED.show();
for(i=0;i<20;i++){ //left transmitter sends 20 pulses
leftSend38KHZ();
delayMicroseconds(600);
}
if(count>10){//if received a lot pulse , it means there's a obstacle
leds[5] = CRGB::White;
FastLED.show();
Serial.println("Left");
delay(100);
}
count=0;
leds[3] = CRGB::Green;
FastLED.show();
for(i=0;i<20;i++){//right transmitter sends 20 pulses
rightSend38KHZ();
delayMicroseconds(600);
}
if(count>10){//if received a lot pulse , it means there's a obstacle
leds[3] = CRGB::White;
FastLED.show();
Serial.println("Right");
delay(100);
}
delay(600);
}
void setup(void){
delay(2000);
FastLED.addLeds<WS2811, DATA_PIN, GRB>(leds, NUM_LEDS);
pinMode(L_IR,OUTPUT);//init the left transmitter pin
pinMode(R_IR,OUTPUT);//init the right transmitter pin
pinMode(IR_IN,INPUT);//init the ir receiver pin
Serial.begin(9600);
leds[4] = CRGB::Blue;
FastLED.show();
delay(2000);
leds[4] = CRGB::Purple;
FastLED.show();
noInterrupts();
pcint0Init();
interrupts(); //enable the interrupt
}
void loop(void){
obstacleAvoidance();
}
IRreceiver
Since DFrobot also have a 'loose' IR-receiver module in their program, decided to just see if the example sketches for those would transfer, and they do. https://www.dfrobot.com/product-366.html - A remote similar to the one pictured on the DFRobot product page actually came with one of my RTLSDR sticks, and seems to work well enough, although the range isn't great, couple of meters. With a 'proper' remote control, e.g. from a TV, the range is fine, 10m at least when pointing at unit from across the house. Might be less if using reflections to try to control a roving robot.
So, using the IRremote library you can read values from a remote controller:
#include "IRremote.h"
#define IR_IN 7//IR receiver pin
IRrecv irrecv(IR_IN);
decode_results results;
void setup(void){
Serial.begin(9600);
irrecv.enableIRIn(); // Start the receiver
}
void loop(void){
if (irrecv.decode(&results)) {
Serial.println(results.value, HEX);
irrecv.resume(); // Receive the next value
}
}
This was already useful to read codes from the remote of the AV-receiver we have at home and then play these back via a universal remote app on the smartphone that was missing some buttons. For some reason I couldn't find the 'learn' function in the app, but could enter the codes as read by this sketch easily.
MP3-player
There is an MP3.player integrated in the robot. It can be controlled by sending more or less magic commands over software Serial via pin 11. Pin 2 might be connected to the player too, but my tests so far never had anything received there (like an end of song reached, or even just an 'ack').
An example found on the DFRobot site:
#define MP3_VOLUME 0x10
#define TX 11
#define RX 2
#include <SoftwareSerial.h>
SoftwareSerial mySerial(RX, TX);// RX, TX
void setup()
{
delay(1000);
mp3Init();
mp3setVolume(30);//0~255
}
void loop()
{
mp3player(1);
delay(2000);
mp3stop();
delay(1000);
}
void mp3Init()
{
mySerial.begin (9600);
}
void mp3setVolume(byte vol)
{
uint8_t buffer[] = {0x7e, 0xff, 0x06, 0x06, 0x00, 0x00, vol, 0xef};
mySerial.write(buffer, 8);
delay(20);
}
void mp3player(byte data)
{
uint8_t buffer[] = {0x7e, 0xff, 0x06, 0x03, 0x00, 0x00, data, 0xef};
mySerial.write(buffer, 8);
delay(20);
}
void mp3stop()
{
uint8_t buffer[] = {0x7e, 0xff, 0x06, 0x16, 0x00, 0x00, 0x00, 0xef};
mySerial.write(buffer, 8);
}
The files to play can be put on the Vortex via usb, seems the little switch next to the micro-usb socket switches this between the mp3-players mass-storage and the arduino usb-serial interface. The number passed to the player is just the index into the (FAT?) table of stored songs. So, be careful of the order these are uploaded to the memory in.
https://www.dfrobot.com/product-1121.html , documented at https://www.dfrobot.com/wiki/index.php/DFPlayer_Mini_SKU:DFR0299 is a mini-MP3 player form DFRobot. It is controllable over serial, and might be the same one as used in the Vortex. Would be good to figure out if the 'busy' signal is connected back to the arduino somewhere in that case. Player could also be a variant but the magic numbers more or less match (although the stop command 0x16 is not in the table. Perhaps Dec16 / 0x0A (standby/low power mode) was meant?
Documentation for this miniplayer mentions the instruction format to be:
| $S | Start byte 0x7e | Each command begins with 0x7e ('~') |
| VER | Version information | Version seems to be 0xff from the example |
| Len | the number of bytes | Start, End and Checksum are not counted, |
| CMD | Commands | See command table, but |
| Feedback | Command feedback | 1: feedback, 0: no feedback ; need to test what this does, might mean 'echo' |
| Para1 | Parameter 1 | Query high data byte |
| Para2 | Parameter 2 | Query low data byte |
| checksum | Checksum | accumulation and verification, doesn't include start byte. Seems to be 2 bytes from the example given in the docs, but Vortex seems to just not need it put in. example given is 7e ff 06 09 00 00 04 ff dd ef |
| $O | End byte | End of command is signaled with 0xEF |
Code to calculate the checksum from the Library supporting the miniplayer:
uint16_t DFRobotDFPlayerMini::calculateCheckSum(uint8_t *buffer){
uint16_t sum = 0;
for (int i=Stack_Version; i<Stack_CheckSum; i++) {
sum += buffer[i];
}
return -sum;
}
Eyes
Besides 35 predefined eye patterns, it is also possible to upload your own eye patterns.
The default eyes can be set as follows:
#include <Wire.h>
#define I2C_LED_ADDRESS 0b1100000
#define I2C_WRITE 0x00
uint8_t serial=0;
void setup(){
Wire.begin(); // join i2c bus (address optional for master)
defined_eyes(6,1);
delay(2000);
}
void loop(){
defined_eyes(1,serial);
serial++;
if(serial>=35) serial=0;
delay(250);
}
void defined_eyes(uint8_t color,uint8_t serial) {
Wire.beginTransmission(I2C_LED_ADDRESS << 1 | I2C_WRITE); // transmit to device #4
Wire.write(color&0x07); // color bits: 1 blue, 2 green, 4 red
Wire.write(serial); //preset eyes 0~34
Wire.endTransmission(); // stop transmitting
}
void custom_eyes(uint8_t color, uint8_t eyeline[10]){
uint8_t index;
// right eye left eye
//1 2 3 4 5 25 24 23 22 21
//6 7 8 9 10 20 19 18 17 16
//11 12 13 14 15 15 14 13 12 11
//16 17 18 19 20 10 9 8 7 6
//21 22 23 24 25 5 4 3 2 1
Wire.beginTransmission(I2C_LED_ADDRESS << 1 | I2C_WRITE); // transmit to device #4
Wire.write(0x55); // color 55=custom eyes follow
Wire.write(0xAA); // ?? AA=color followed by 10 bytes, each defining one line
// other values cause eyes to light up in multiple colors, needs more work
Wire.write(color&0x7); //color 1-B,2-G,4-R of foreground
for (index=0;index<10;index++) {
Wire.write(eyeline[index]);
}
Wire.endTransmission(); // stop transmitting
void example_eyes() {
/* left eye of robot (right for onlooker) */
Wire.write(0x1f); // bottom row, all bits lit
Wire.write(0x1e); // 10 9 8 7 on, 6 off
Wire.write(0x1c);
Wire.write(0x18);
Wire.write(0x10);
/* right eye of robot (left for onlooker) */
Wire.write(0x1f); // top row all 5 bits lit
Wire.write(0x0f); // leds 6,7,8,9 on 10 off
Wire.write(0x07); // 11,12,13 on, 14,15 off
Wire.write(0x03);
Wire.write(0x01);
}