hi Dirk,
also schauen wir mal was mitte juli geht...
schönen urlaub noch...
Druckbare Version
hi Dirk,
also schauen wir mal was mitte juli geht...
schönen urlaub noch...
Zu dem Problem mit den Bumpern der Code
Es funktioniert leider noch nicht ob wohl ich im vergleich zum letzten mal task_MULTIIO_BUMPERS(); erweitert habe.Code:/*****************************************************************************/
// Includes:
#include "RP6M256Lib.h"
#include "RP6I2CmasterTWI.h" // I2C Master Library
#include "RP6M256_I2CMasterLib.h"
#include "RP6M256_LFSBumperLib.h"
#include <string.h>
/**
* Bumpers Event handler
*/
void bumpersStateChanged(void)
{
if(bumper_left && bumper_right)
{
wifiControl.dir = FWD;
wifiControl.speed_left = 0;
wifiControl.speed_right = 0;
clearPosLCD(3,0,16);
setCursorPosLCD(3, 0);
writeStringLCD_P("stop");
moveCommand(&wifiControl);
}
else if(bumper_left)
{
wifiControl.dir = FWD;
wifiControl.speed_left = 0;
wifiControl.speed_right = 0;
clearPosLCD(3,0,16);
setCursorPosLCD(3, 0);
writeStringLCD_P("stop");
moveCommand(&wifiControl);
}
else if(bumper_right)
{
wifiControl.dir = FWD;
wifiControl.speed_left = 0;
wifiControl.speed_right = 0;
clearPosLCD(3,0,16);
setCursorPosLCD(3, 0);
writeStringLCD_P("stop");
moveCommand(&wifiControl);
}
}
// ... //
int main(void)
{
initRP6M256();
initLCD();// IMPORTANT:
lfsbumper_init(); // LFS & Bumper init!!!
// ---------------------------------------
I2CTWI_initMaster(100);
I2CTWI_setRequestedDataReadyHandler(I2C_requestedDataReady);
I2CTWI_setTransmissionErrorHandler(I2C_transmissionError);
MULTIIO_BUMPERS_setStateChangedHandler(bumpersStateChanged);
BUMPERS_setStateChangedHandler(bumpersStateChanged);
// ... //
while(true)
{
task_checkINT();
task_I2CTWI();
behaviourController();
//task_webserver();
task_MULTIIO_BUMPERS();
}
return 0;
}
Thorben W
Hi,
sollte Deine Eventhandler nicht
void MULTIIO_BUMPERS_stateChanged(void)
heißen ? den Du da aufrufst ist der für die alten Bumper.
Ich rufe beide auf den für "vorne" und den für "hinten"
Thorben W
ja Du rufst beide in der Main auf, Du sagst aber nur dem alten was er machen soll wenn Kontakt da ist.
Reicht nicht auch einer für beide? Probier ich dann mal aus
Thorben
Dirk benutzt ja in den Libs andere Variablen die abgefragt werden müssen, als die der alten Bumper.
Wie sollte das in Deinem Code funktionieren ? Kontakt vorn - ...fahre Vorwärts Kontakt hinten - ...fahre Vorwärts wäre ja dann Deine Programm Logik und das wäre ja unsinn. Du mußt also schon die Zustände aller 4 Bumper abfragen und je nach dem reagieren.
@inka:
Wenn du vorher schon mal was machen willst:Zitat:
also schauen wir mal was mitte juli geht...
Setz mal in der Demo (RP6Control_MultiIO_05) die I2C-Busgeschwindigkeit weiter runter.
Und zwar in 10er Schritten von 100 kHz auf 90, 80, 70. Jeweils neu kompilieren und testen.
Zeile: I2CTWI_initMaster(100);
@Dirk,
habe den wert versuchsweise auf 70, 50 und 20 geändert, das programm reagiert wie gehabt, wird also nach einer einmaligen anzeige der minIMU werte beendet und kehrt zu der "READY TO GO!" LCD-anzeige zurück...
@inka:
Dein Programm beendet sich selbst.
Was du probieren kannst:
1. Lade das Beispiel und die Libs nochmal komplett runter.
2. Prüfe nochmal den elektrischen Anschluß der MinIMU.
3. Ändere I2CTWI_initMaster(100) auf I2CTWI_initMaster(70).
4. Kompiliere das neu.
Wenn das Programm jetzt immer noch aussteigt, weiß ich erstmal nicht weiter.
@Dirk:
habe die dateien für M32 (RP6Control_MultiIO_05.zip) heruntergeladen, die dateien
RP6Control_MultiIO.h
RP6Control_Orientation.h
RP6Control_OrientationLib.c
RP6Control_OrientationLib.h
in meinem libverzeichnis durch die neuen ersetzt und die RP6Control_MultiIO_05.c mit unveränderten (neuen) libs neu kompiliert. Nach dem upload hat sich am ergebnis nichts geändert, das programm beendet sich nach einmaligem anzeigen der minIMU daten selbst.
das gleiche passiert nach der änderung von I2CTWI_initMaster(100) auf I2CTWI_initMaster(70).
die hardwarekontrolle beschränkte sich auf die nochmalige kontrolle der "abweichenden IO jumperstellung für die M32", das vorhandensein der VIN, GND, SDA und SCL leitungen/signale für die minIMU (deren verbindung zu den entsprechenden punkten an der BASE bzw. der M32).
Alles OK...
Würden die fehlen, würde ja die minIMU garnichts tun, oder?
dann habe ich versucht die im archiv enthaltene *.hex datei zu laden, nach deren start bleibt das LCD "dunkel", es wird nichts angezeigt.
das einzige was mir noch einfällt: könnte ich Dir das IO-board, die minIMU und den HDMM zum überprüfen schicken? Für porto hin und zurück komme ich selbstverständlich auf...
Hi inka,
als Schritt davor habe ich erstmal die HEX der Demo 05 geschickt.
Funktioniert die?
hi Dirk,
auch wenn ich (noch) nicht weiss, was die vielen zahlen im LCD bedeuten:
JA! die hexdatei funktioniert!
wo lag das problem?
Hi inka,
Ich habe keins identifiziert, außer der jetzt auf 70 kHz reduzierten I2C-Busgeschwindigkeit.Zitat:
wo lag das problem?
Die komplette Demo mit Source habe ich dir noch einmal geschickt.
Hi Dirk,
ich habe nun die dateien noch einmal getauscht, kompiliert, hier das protokoll:
und die kompilierte datei geht nicht!Code:-------------- Bereinigen: gyro_test_multi_io_05 in multi_I_O_test ---------------
Cleaned "multi_I_O_test - gyro_test_multi_io_05"
-------------- Erstellen: gyro_test_multi_io_05 in multi_I_O_test ---------------
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6ControlLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6ControlServoLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6Control_I2CMasterLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6Control_LFSBumperLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6Control_MultiIOLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6Control_OrientationLib.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6I2CmasterTWI.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/2012_lib_komplett/RP6uart.c
Compiliere: ../../../../mnt/netzserver_x/georg/workspace/multi_I_O_test/gyro_test_RP6Control_MultiIO_05.c
Verbinde Programmmodule ausführbare Datei: bin/gyro_test_multi_io_05/gyro_test_multi_io_05
Output size is 60,93 KB
Projekt-Schritte nach dem Erstellen ausführen
avr-objcopy -O ihex -R .eeprom -R .eesafe bin/gyro_test_multi_io_05/gyro_test_multi_io_05 bin/gyro_test_multi_io_05/gyro_test_multi_io_05.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin/gyro_test_multi_io_05/gyro_test_multi_io_05 bin/gyro_test_multi_io_05/gyro_test_multi_io_05.eep.hex
avr-objdump -h -S bin/gyro_test_multi_io_05/gyro_test_multi_io_05 > bin/gyro_test_multi_io_05/gyro_test_multi_io_05.lss
Prozess wurde mit Status 0 beendet. (0 Minuten, 2 Sekunden)
0 Fehler, 0 Warnungen
Hi inka,
scheint ja auch bei dir fehlerfrei zu kompilieren.
Ich habe bei der Demo natürlich nur die notwendigen Libs (RP6ControlLib, RP6uart, RP6I2CmasterTWI, RP6Control_OrientationLib) eingebunden.
Bei dir sehe ich noch die RP6ControlServoLib, RP6Control_LFSBumperLib und RP6Control_MultiIOLib.
Versuch doch mal, die nicht unbedingt nötigen Libs eine nach der anderen wegzulassen. Vielleicht kannst du ja was inkompatibles identifizieren.
das war ja offensichtlich mein trugschluss: ich dachte eine *.c datei, die bein anderen kompiliert wurde und lief, - wenn sie bei mir ohne fehler ebenfalls kompiliert wurde - wird/muss auch bei mir funktionieren...
ich habe die drei dateien nacheinander entfernt, erst beim entfernen der "RP6Control-MultiIOLib.c" funktionierte es, komischerweise wurde bei keiner der drei dateien, als ich sie entfernt habe, verlangt das projekt neu zu speichern. Und trotzdem wurden sie beim kompilieren verwendet. Man lernt nie aus...
also, weitergehts mit dem kompass!
danke für alle deine bemühungen, ich hätte es ohne den hinweis nie gefunden...
@inka:
Gut, dass es bei dir jetzt weitergehen kann! :)
Schlecht:
Jetzt gehe ich auf Suche, warum sich die Orientierungs Lib eventuell nicht mit der MultiIO Lib verträgt ... :evil:
Werde jetzt die anderen Libs nacheinander mit einbinden und gucken, was passiert. :nö:
Geschafft:
Alle drei Libs (RP6ControlServoLib, RP6Control_LFSBumperLib und RP6Control_MultiIOLib) nacheinander mit eingebunden, allerdings ohne eine Funktion daraus aktiv zu nutzen.
Ergebnis: Demo 05 läuft.
Also:
Keine Ahnung, was da gelaufen ist.
werde ich morgen auch noch einmal probieren...
Komisch: Warum sollte das Einbinden einer Lib ohne Nutzung von Funktionen aus der Lib sich so auswirken?
Naja, es gibt Dinge zwischen Himmel und Erde ... :-k
frage zu stromversorgung:
die beschreibung im RN-wissen sagt (mir) in dieser richtung nichts, deshalb, um kein schaden anzurichten folgende frage:
ich betreibe die IO-karte mit am RP6-akku. Jetzt blieb plötzlich die LCD anzeige zwar beleuchtet, aber ansonsten leer. Ein anschluss des loaderkabels am RP6 brachte die fehlermeldung, dass die spannung unter 5,2 V abgesunken ist.
- ladegerät in die RP6-buchse, es wurde geladen...
- RP6 einschalten geht nicht, weil der ladevorgang unterbrochen wird...
geht denn dass überhaupt - laden des RP6 akku UND weiter programme tetsten? Evtl. über die IO-board ladebuchse?
@inka:
Grundsätzlich ist der RP6 so gestrickt, dass man die eingesetzten Akkus nur laden kann, wenn der RP6 ausgeschaltet ist.
Grund: Die Ladegeräte für einen 7,2V Akku können über 10V erzeugen. Das wäre u.U. zu viel für den RP6.
Wenn man sich auskennt, kann man da auch andere Lösungen mithilfe des EXT-Anschlusses erreichen, siehe hier!
Was die MultiIO angeht, hat fabqu die Stromversorgung recht universell ausgelegt, siehe angehängten Schaltplan!
Man kann demnach an S2 einen eigenen Akku 7,2V anklemmen und den über B1 laden. Ist S2 dabei in der oberen Stellung (wie eingezeichnet), besteht während des Ladens keine Verbindung zur Rest der Schaltung.
Damit könnte man 2 Sachen machen:
1. Man kann mit dem Akku an S2 NUR die MultiIO versorgen. Dazu kommt S2 in die untere Stellung (nach dem Laden!!), S1 in Stellung "U". Der RP6 selbst wird dann von seinem eigenen Akku versorgt.
2. Man kann mit dem Akku an S2 die MultiIO UND den RP6 versorgen. Dazu kommt S2 in die untere Stellung (nach dem Laden!!), J_U-RP6 und J_UB werden aufgesteckt und die Akkus im RP6 werden herausgenommen (!!!).
Beide Schaltungen haben Vorteile:
Bei der 1. Lösung teilt sich die Stromversorgung auf 2 Akkus auf, hält daher länger.
Bei der 2. Lösung kann man durch eine höhere Kapazität des Akkus an S2 (>2700 mAh) eine längere Laufzeit erreichen.
ok, versuchen wir es:
ich möchte den RP6 über den eingebauten akku betreiben, die MultiIO über einen netzteil an B1. Folgende stellung der jumper/schalter:
J_UB, J_VCC - offen
J_URP6 - geschlossen
S1 - stellung UB
S2 - stellung oben (platinenrand
B1 - ein netzteil 9V (auch 12V?)
Ok ...
Vorschlag:
J_UB, J_VCC - offen
J_URP6 - geschlossen (oder offen - egal)
S1 - stellung U
S2 - stellung oben (platinenrand) fürs LADEN, sonst unten
B1 - ein netzteil 9V
ist der S1 dann in stellung UB, wenn der schalterhebel näher an B1 ist? Eine dedachte verlängerung des schalterhebels zeigt auf UB?
Ja, genau.
wenn ich dann den S2 nach unten, also vom platinenrand wegschiebe, geht dir grüne led aus (netzteil ist an B1)
Also, wenn S2 oben ist, dürfte nichts leuchten.
Kannst du mit einem Meßgerät die 5V und 9V messen?
siehe bild. Der S1 steht auf UB, RP6 ist ausgeschaltet. Kann ich den S2 falsch herum eingelötet haben, oder ist es nicht möglich?
Anhang 25971
das netzteil liefert 8,9V, + in der mitte, an der minIMU liegen an GND und VIN 5,03V...- S2 vorne, wie auf dem foto...
Nein, den S2 kann man nicht falsch einlöten.
Es wäre aber möglich, dass er "andersherum" schaltet (ähnlich wie S1). Jedenfalls müssen die unteren beiden Lötpunkte des S2 (also die zur Platinenmitte hin) verbunden sein, damit es klappt.
Nimm doch einfach die Stellung von S2, bei der die MultiIO mit Netzteil an B1 funktioniert.
WICHTIG: Es darf dann keine Verbindung mehr zum RP6 an VDD und +UB mehr geben!!! (Das ist mit der Schalterstellung, die du angegeben hast, aber auch so ok!)
so funktioniert es jetzt...
hallo allerseits,
bereits zum zweiten mal darauf hereingefallen: die spannung der akkus des RP6 fält unter den wert von 5,2V und egal wie gut das programm vorher lief, ab dann liefert es nur noch mist!
fragen:
- gäbe es nicht im zusammenhang mit dem IO board beim initialisieren des boards (also beim einschalten) eine möglichkeit die spannung einmal anzuzeigen?
- alternativ dazu könnte man ein mini-led-voltmeter einbauen und die spannung auch dauerhaft anzeigen. Die digitalen LED-spannungsanzeigen haben aber sehr große ziffernhöhe, kennt jemand andere, kleinere?
Hi inka,
ja klar. Du kannst am Programmanfang einmalig z.B. den LTC2990 abfragen und dir vbat ausgeben lassen.
Es ist auch möglich, einen unteren Grenzwert festzulegen und vbat regelmäßig in der Hauptschleife abzufragen.
Wenn der untere Grenzwert unterschritten wird, könnte man eine Warnung ausgeben und/oder den RP6 stoppen. Alles möglich ...
Hi Dirk:
in meinem programm habe ich eingesetzt:
Code:int main(void)
{
initRP6Control();
multiio_init();
initLCD();
//orientation_init();
// Voltage & current sensor test:
LTC2990_measure();
writeString("BAT Current: ");
writeDouble(cbat, 6, 1);
writeString(" mA\nBAT Voltage: ");
writeDouble(vbat, 4, 1);
writeString( " V\n ");
die funktion selbst ist:
die ausgabe beschränkt sich ber nur auf:Code:void LTC2990_measure(void)
{
LTC2990_run(); // Start measurement
mSleep(200);
LTC2990_read(); // Read data
LTC2990_calculate(); // Calculate values
}
was muss ich noch tun, damit er auch echt die spannung misst?Code:[RP6BOOT]
[READY]
BAT Current: 0.0 mA
BAT Voltage: 0.0 V
Hi Inka,
Du solltest vielleicht mal das ganze Programm einstellen, wie soll man denn da sonst sehen was Du vergessen hast.
Schon der fehlende Aufruf von I2CTWI_initMaster reicht um dir Nullen in der Ausgabe zu bringen. Warum Du die Funktion
void LTC2990_measure(void) erwähnst versteh ich auch nicht. Sie ist ja Bestandteil der Lib von Dirk und schon mit LTC2990_measure(); rufst Du ja die Daten ab. Ich habe mal schnell ein paar Zeilen geschrieben.
Jetzt hast Du Deine Ausgaben auf dem Terminal.Code:// Includes:
#include "RP6ControlLib.h"
#include "RP6I2CmasterTWI.h"
#include "RP6Control_MultiIOLib.h"
#include "RP6Control_I2CMasterLib.h"
/*****************************************************************************/
void writeDouble(double number, uint8_t width, uint8_t prec)
{
char buffer[width + 1];
dtostrf(number, width, prec, &buffer[0]);
writeString(&buffer[0]);
}
/*****************************************************************************/
void Ausgabe(void)
{
LTC2990_measure();
writeString("BAT Current: ");
writeDouble(cbat, 6, 1);
writeString(" mA\nBAT Voltage: ");
writeDouble(vbat, 4, 1);
writeString( " V\n ");
}
/*****************************************************************************/
int main(void)
{
initRP6Control();
I2CTWI_initMaster(100);
multiio_init();
/*****************************************************************************/
while(true)
{
Ausgabe();
}
return 0;
}
das problem lag daran, dass die zeile
I2CTWI_initMaster(100);
hinter der strom und spannungsabfrage, statt davor war...
danke...
Hallo ihr
ich versuche gerade die Snakevision am RP6 funktionsfähig zu bekommen.
Ist das richtig / ist das bei euch auch so, das der Transistor Q2 bei offenem Jumper ca. 4V auf die Base schaltet?
Thorben
- - - Aktualisiert - - -
Wie muss ich die Snakevision eingentlich anschließen? Die Signalpins sind ja klar.
Ich habe jetzt VCC (IC2 Pin 1) auf der Multiio an Pin 2 des vorgesehenen Steckers. Und GND an GND am Vorderen XBUS
Hallo
Vielleicht hilft dir das weiter:
https://www.roboternetz.de/community...t-Snake-Vision
https://www.roboternetz.de/community...t-Snake-Vision
Gruß
mic