linienfolger

**Dirk** · 20.02.2014, 22:12

Hi inka,

das Problem ist nicht, dass es das nicht gibt (in der RP6RobotBaseLib):
setMotorPower(uint8_t left_power, uint8_t right_power)
setMotorDir(uint8_t left_dir, uint8_t right_dir)

Das Problem ist, dass der I2C-Slave diese Funktionen so nicht kennt.
Aber: Du hast ja auch schon die direkte IR-Empfänger-Abfrage in den Slave aufgenommen,- warum nicht auch diese 2 kleinen neuen Funktionen?

**inka** · 21.02.2014, 08:24

Hi Dirk,
ich bin keineswegs sicher, aber für die setMotorDir funktion würde ich folgendes ändern:

in der RP6Control_I2CMasterLib.c einfügen:

Code:

// Direction 
uint8_t left_dir; 
uint8_t right_dir; 
 
-------------------------------

/** 
 * Set Motor dir function 
 */ 
 
{
setMotorDir(uint8_t left_dir, uint8_t right_dir) 
I2CTWI_transmit4Bytes(I2C_RP6_BASE_ADR, 0, CMD_SET_MOTOR_DIR, left_dir, right_dir ); 
while(I2CTWI_isBusy() || TWI_operation != I2CTWI_NO_OPERATION) task_I2CTWI(); 
}

in der RP6Control_I2CMasterLib.h einfügen:

Code:

#define CMD_SET_MOTOR_DIR        13
-------------------------------------------
void setMotorDir(uint8_t left_dir, uint8_t right_dir);
--------------------------------------------

// Direction 
extern uint8_t left_dir; 
extern uint8_t right_dir;

in der RP6Base_I2CSlave.c einfügen:

Code:

#define CMD_SET_MOTOR_DIR        13

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

in der Funktion "void task_commandProcessor(void)" einfügen: 

case CMD_SET_MOTOR_DIR: setMotorDir(param1, param2); break;

**Dirk** · 21.02.2014, 09:27

Ja, sieht doch gut aus.
Kleine Änderung in der "Set Motor dir function":

Code:

/** 
 * Set Motor dir function 
 */ 
 
void setMotorDir(uint8_t left_dir, uint8_t right_dir)
{ 
 I2CTWI_transmit4Bytes(I2C_RP6_BASE_ADR, 0, CMD_SET_MOTOR_DIR, left_dir, right_dir); 
 while(I2CTWI_isBusy() || TWI_operation != I2CTWI_NO_OPERATION) task_I2CTWI(); 
}

P.S.: Vorsicht mit den Funktionen, die die Motorrichtung und/oder Speed direkt schalten: Man kann (z.B. wenn man bei voll Speed vorwärts auf voll Speed rückwärts umschaltet) den RP6 evtl. schrotten!

**inka** · 21.02.2014, 10:09

Hi Dirk,

Zitat von Dirk

Ja, sieht doch gut aus.

ok, danke, das void habe ich übersehen, mich wunderts sowieso, dass da so weing falsch war

. Also mache ich mich an die zweite funktion...

Zitat von Dirk

Vorsicht mit den Funktionen, die die Motorrichtung und/oder Speed direkt schalten: Man kann (z.B. wenn man bei voll Speed vorwärts auf voll Speed rückwärts umschaltet) den RP6 evtl. schrotten!

wie ist das zu vermeiden? Oder ist das so, dass das risiko nur mit steigender speed auch steigt?

Eine andere idee: solche änderungen am funktionsumfang der I2C_slave (und zusammenhängende änderungen an der RP6Control_I2CMasterLib) wie die IR geschichte, oder jetzt die motorsachen, wäre es nicht sinnvoll das irgendwo "offiziell", also z.b. im Wiki für die allgemeinheit zu sammeln? Ich wüsste selber nicht, ob ich heute noch alle infos zu der IR sache finden würde, müsste schon mehr suchen, als wenn es irgendwo zusammengefasst wäre...

**Dirk** · 21.02.2014, 10:47

Hi inka,

wie ist das zu vermeiden? Oder ist das so, dass das risiko nur mit steigender speed auch steigt?

In der Original-RP6-Lib wird die Speed nur mit "Rampen" verändert und z.B. bei Richtungswechsel erst die Speed reduziert, dann die Richtung geändert und wieder in die andere Richtung beschleunigt.
Wenn man ohne diese "Sicherheitsfunktionen" arbeiten will, dann muss man sich eigene Kontroll-Regeln einbauen.
Z.B.: Schalte die Drehrichtung eines Motors nur um, wenn die Speed des Motors < 40 ist. Wenn der Unterschied zwischen neuer (gewünschter) Speed und aktueller Speed > 30 ist, dann begrenze die neue Speed auf (aktuelle Speed + 30). Usw.

solche änderungen am funktionsumfang der I2C_slave (und zusammenhängende änderungen an der RP6Control_I2CMasterLib) wie die IR geschichte, oder jetzt die motorsachen, wäre es nicht sinnvoll das irgendwo "offiziell", also z.b. im Wiki für die allgemeinheit zu sammeln? Ich wüsste selber nicht, ob ich heute noch alle infos zu der IR sache finden würde, müsste schon mehr suchen, als wenn es irgendwo zusammengefasst wäre...

Ja, da wäre ich sehr dafür!
Meine (bescheidene) Vorstellung:
Dein aktuelles Linienfolge-Programm gehört ja eigentlich zu deinem großen Projekt "RP6 sucht autonom eine induktive Ladestation auf".
Ich fände es absolut klasse, wenn das ganze Projekt zu einem eigenen Wiki-Artikel würde. Du hast dich da mit so viel Energie den Hardware- und Software-Fragen gestellt, dass das ein "Lehrstück" für Viele sein könnte (das Interesse zeigt sich ja z.B. durch die große Zahl der Aufrufe deiner Themen!).

**inka** · 21.02.2014, 13:03

Hi Dirk,

Zitat von Dirk

das Problem ist nicht, dass es das nicht gibt (in der RP6RobotBaseLib):
setMotorPower(uint8_t left_power, uint8_t right_power)
setMotorDir(uint8_t left_dir, uint8_t right_dir)

bist Du sicher, dass es sinnvoll ist anstelle der asuro-funktion:

Code:

inline void MotorSpeed (    unsigned char left_speed,    unsigned char right_speed)
  { 
OCR1A = left_speed;    
OCR1B = right_speed;
}

die RP6-funktion:

Code:

void setMotorPower(uint8_t left_power, uint8_t right_power) 
{ 
    if(left_power > 210) left_power = 210; 
    if(right_power > 210) right_power = 210; 
    mright_power = right_power; 
    mleft_power = left_power; 
}

zu verwenden, statt das "moveAtSpeed()" direkt (und sichrere) zu verwenden?

das wird ja in der "RP6RobotBaseLib" sogar vorgeschlagen:
-------------------------------------------------------------
* IT IS A BETTER IDEA NOT TO USE THIS FUNCTION AT ALL!
* Use moveAtSpeed together with task_motionControl instead.
* YOU CAN NOT USE setMotorPower AND setMotorDir WHEN YOU USE
* task_motionControl! This will not work!
* -------------------------------------------------------------

oder geht es aus irgendwelchen anderen gründen nicht?

**Dirk** · 21.02.2014, 16:11

Hi inka,

bist Du sicher, dass es sinnvoll ist anstelle der asuro-funktion:
...
die RP6-funktion:
...
zu verwenden, statt das "moveAtSpeed()" direkt (und sichrere) zu verwenden?

Die RP6-Lib Funktionen sind auf jeden Fall sicherer.
Leider haben sie den Nachteil beim Linienfolgen, dass die Reaktion auf Änderungen der Richtung oder Geschwindigkeit etwas verzögert kommt.
Da ist man dann manchmal schon über die Linie hinaus geschossen.

Das ist sicher auch der Grund, warum in dem Asuro-Programm der direkte Weg gewählt wurde.

**RolfD** · 10.03.2014, 18:26

@Inka
Wenn ich das richtig sehe, postet ihr da verschiedenen Quellcode.. der eine was von der Base/I2C-Slave, der andere was von der I2C-Master lib?
Grundsätzlich gilt, es gibt Funktionen die die IO-Ports direkt steuern (böse/schnell) und es gibt welche die Rampensteuerung erledigen (gut/lahm). Letztere laufen auch als Task. Die Rampensteuerung auf der Base ist auf Grund des Trägheitsmomentes von Zahnrädern notwendig damit es kein Getriebesalat gibt.
Die I2C-Master Lib muss sich um die Details wie Rampen jedoch eigentlich nicht kümmern wenn sie Fahranweisungen gibt... da sich schon die Base/Slave darum kümmert. Die I2C-Master lib kann eh kein Port der Base direkt ansteuern. Baut man sich ein Linienfolger, lässt man die Software dafür besser auf der Base laufen - schon wegen der trägen Laufzeiten auf dem I2C Bus sammt en/decodierung der Motorbefehle und Übertragungsfehler... und verwendet die Base ports ADC0/1 für den Sensorabgriff. Alles andere ist von hinten durch die Brust ins Auge...
Gruß

**inka** · 11.03.2014, 07:13

@RolfD

keine grundsätze ohne ausnahmen

danke für die erklärung, ich bin mir der problematik mit dem getriebe durchaus bewusst, es kommt mir nicht auf schnelligkeit beim folgen der linie an, es hat sich aber gezeigt, dass der lauf bei diesem code sehr viel gleimäßiger als bei anderen meinen versuchen ist...

der linienfolger hier läuft später nicht allein, sondern ist bestandteil meiner induktiven ladestation und der Suche danach. Die Suche beginnt mit der groben orientierung nach einer IR-bake und der annäherung ans ziel, dann übernimmt der linienfolger und es geht wohl nicht - zumindest meines wissens nach - , dass innerhalb eines programms zwischen m32 und der base ohne weiteres gewechselt wird wo was läuft und wer den hut auf hat, oder?

**RolfD** · 11.03.2014, 08:58

Hallo Inka,
türlich geht das mit dem Hut wechseln... nur müsste die m32 ständig die Messwerte der Sensoren per I2C an die Base geben und die Base daraus Fahrbefehle basteln.
Es wäre auch denkbar, das man (die m32) der Base per I2C Modus Befehl sagt "fahr du die nächsten Meter aber achte auf die Sensorwerte auf dem I2C Bus".
Dazu müsste einiges an der base lib bzw. I2C slave umgeschrieben werden aber letztendlich bestimmst doch du, was die beiden miteinander aushandeln.
Immerhin sind das 2 unabhängige Prozessoren, und das verhalten dazwischen ist umsetzbar von master/slave über preemptiver Prozess und Steuerungskontrolle und noch komplizierteren Verfahren.
Da z.B. die m32 nichts von den Bumpern mitkriegt, diese aber mit in das Fahrmodel mit einfließen.. bzw. die Bumper die Fahrsteuerung beeinflussen, hast du eh schon eine Art "verteilte Intelligenz".
Das lässt sich auch gescheit ausbauen.
Gruß