Software-Entwickler gesucht

nero76

Moderator
Hallo,

wir suchen immer noch Software-Entwickler (C/C++) für unser 2-köpfiges Entwickler-Team. Falls ihr immer schon mal einen Roboter programmieren wolltet, ist das die Gelegenheit in unserem Team mitzuarbeiten (z.B. auch nur 1-2h abends). Meldet euch einfach hier im Forum :)

Ein Roboter ist keine Voraussetzung - die Software soll per Simulation (2D/3D) ausgebaut werden...( 3D Prototyp vorhanden ).

Gruss,
Alexander
 
Hallo Alexander,

ich bin zwar nicht der große Programmiere, würde euch aber trotzdem gerne Unterstützen, wenn möglich.

Was kann ich tun ?

Gruss stefan
 
Selbe Frage hier: was ist zu tun?

Da meine freie Zeit sehr unregelmäßig verteilt ist, würde ich lieber ein
Thema angehen, das nicht so zeitkritisch (dafür aber gerne umfangreicher
und programmtechnisch anspruchsvoller) ist.

Noch zwei Anmerkungen am Rande:
- erst mal einen herzlichen Dank an die Programmierer und alle anderen
"Hauptamtlichen". Inzwischen hat sich meine Mäher-Konfiguration etwas
vom original Ardumower entfernt, aber ich habe immens von diesem
Projekt profitiert.
- Ich könnte mir vorstellen, dass auch die Doku-Abteilung Verstärkung
gebrauchen könnte. Ich fände es nicht schlecht wenn dort jemand mithelfen
könnte, der nur wenig Ahnung von Hard- und Software hat. Ich als Elektronik
Frischling hatte manchmal Probleme, weil Wissen als bekannt vorausgesetzt
wurde, das bei mir nicht vorhanden war ;-)

Nachtrag: Ich vergaß - es gibt eine Todo-Liste:
https://code.google.com/p/ardumower/source/browse/trunk/ardumower/TODO.txt
 
Hallo,

für jeden Geschmack sollte etwas dabei sein:

Du bist der Planer mit dem Gespür für das große Ganze:
Finde heraus wie eine flexible Roboter-Software-Architektur auszusehen hat. Abstrakte Modellierungs-Themen wie "Subsumption architecture", "State machine with timers", "Class diagrams" sind zu beackern und zu diskutieren .

Du liebst Details und findest aus einer 1200 Seiten http://www.atmel.com/images/doc11057.pdf]technischen Spezifikation[/url] die gesuchten 3 Parameter heraus
Finde heraus wie der Arduino Due Timer programmiert wird, so dass die aktuelle tone()-Implementation nicht mehr mit der Arduino Servo-Library (include) kollidiert.

Du experimentierst gerne mit Hardware
Finde heraus, ob die Perimeter-Ausfallerkennung ( perimeter.cpp ) auch in der Mitte der Schleife funktioniert (signalTimedOut). Nutze die pfodApp-Plots hierfür ( "on" Plot ) und teste und optimiere den Code hiermit.


...to be continued...
 
AlexanderG schrieb:
Finde heraus wie der Arduino Due Timer programmiert wird, so dass die aktuelle tone()-Implementation nicht mehr mit der Arduino Servo-Library (include) kollidiert
Hi

This is tone implementation using Timer0 with TC0. Please have a try.
I can not try by myself with the whole project since the svn code don't start on due. (See my post in DUE porting section).

Code:
/*
 Tone generator
 v1  use timer, and toggle any digital pin in ISR
   funky duration from arduino version
   TODO use FindMckDivisor?
   timer selected will preclude using associated pins for PWM etc.
    could also do timer/pwm hardware toggle where caller controls duration
    */


// timers TC0 TC1 TC2   channels 0-2 ids 0-2  3-5  6-8     AB 0 1
// use TC1 channel 0 
#define TONE_TIMER TC0
#define TONE_CHNL 0
#define TONE_IRQ TC0_IRQn

// TIMER_CLOCK4   84MHz/128 with 16 bit counter give 10 Hz to 656KHz
//  piano 27Hz to 4KHz

static uint8_t pinEnabled[PINS_COUNT];
static uint8_t TCChanEnabled = 0;
static boolean pin_state = false ;
static Tc *chTC = TONE_TIMER;
static uint32_t chNo = TONE_CHNL;

volatile static int32_t toggle_count;
static uint32_t tone_pin;

// frequency (in hertz) and duration (in milliseconds).

void tone(uint32_t ulPin, uint32_t frequency, int32_t duration)
{
	const uint32_t rc = VARIANT_MCK / 256 / frequency; 
	tone_pin = ulPin;
		toggle_count = 0;  // strange  wipe out previous duration
		if (duration > 0 ) toggle_count = 2 * frequency * duration / 1000;
		else toggle_count = -1;

		if (!TCChanEnabled) {
			pmc_set_writeprotect(false);
			pmc_enable_periph_clk((uint32_t)TONE_IRQ);
			TC_Configure(chTC, chNo,
				TC_CMR_TCCLKS_TIMER_CLOCK4 |
				TC_CMR_WAVE |         // Waveform mode
				TC_CMR_WAVSEL_UP_RC ); // Counter running up and reset when equals to RC

			chTC->TC_CHANNEL[chNo].TC_IER=TC_IER_CPCS;  // RC compare interrupt
			chTC->TC_CHANNEL[chNo].TC_IDR=~TC_IER_CPCS;
			NVIC_EnableIRQ(TONE_IRQ);
			TCChanEnabled = 1;
		}
		if (!pinEnabled[ulPin]) {
			pinMode(ulPin, OUTPUT);
			pinEnabled[ulPin] = 1;
		}
		TC_Stop(chTC, chNo);
        TC_SetRC(chTC, chNo, rc);    // set frequency
        TC_Start(chTC, chNo);
    }

    void noTone(uint32_t ulPin)
    {
	TC_Stop(chTC, chNo);  // stop timer
	digitalWrite(ulPin,LOW);  // no signal on pin
}

// timer ISR  TC0 ch 0
void TC0_Handler ( void ) {
	TC_GetStatus(TC0, 0);
	if (toggle_count != 0){
		// toggle pin  TODO  better
		digitalWrite(tone_pin,pin_state= !pin_state);
		if (toggle_count > 0) toggle_count--;
		} else {
			noTone(tone_pin);
		}
	}
 
Zuletzt bearbeitet von einem Moderator:
Der Buzzer ist hier vielleicht etwas OffTopic, aber da hätte ich einen
Alternativvorschlag: Wäre es nicht einfacher den Ton mit einer kleinen
Schaltung zu generieren. Dann könnte man den Ton einfach per

digitalWrite(buzzer, ON);
digitalWrite(buzzer, OFF);

ein- und ausschalten und spart sich den Interrupt. Ich musste den Code
hier bei mir schon so ändern, weil ich noch ein altes Modul herum liegen
hatte, das genau das macht (übrigens ein Pfennigartikel).
 
Heiner

ist doch ein Gute Idee, dann kann man Anschließen was man will. Einen einfachen Tongenerator zum Piepen oder eine Sprachausgabe oder eine RGB LED oder.....

und Alex spart sich den stress mit dem Tone() Modul.

Stefan
 
Ich programmiere halt in C, da komme ich ohne Klassen aus, und habe keine fertigen Arduino Funktionen.

Was ich anbieten kann:
umrechnen von float Berechnungen in Festkommarithmetik, damit werden Berechnungen natürlich ungenauer, aber um den Fakter 10 schneller.
Diverse Fahrstategien damit sich der Roboter nicht festfährt, zB Hindernis an Schleife, wie ausweichen; bei Fahrt an Schleife dreht ein Rad durch, wie kommt er da wieder raus;usw

Des weiteren bin ich dabei zu versuchen die gesamte Karte mit A-Stern Navigation auf einen eigenen Kontroller auszulagern, da ich momentan massive EEPROM Probleme habe. Das könnte man dann auch hier verwenden. Anforderung sind für eine Karte mit 4000 Felder mindestens 8K SRAM und 4kB EEPROM, wobei EEPROM auch extern sein kann.
Wenn ihr geringere Anforderungen habt genügt ein ein kleinerer Kontroller, notweniges RAM = 1* Karte + 3*Karte für A-Stern, ich hab für A-Stern die Genauigkeit halbiert und komme so auf mindestens 1* Karte + 3*Karte/4

LG!
 
Beruflich programmiere ich in C (komplette Mobilsteuerungen für Rotary-Bohranlagen u.a. nach DIN EN 13849) ... hab von C++ nur hobbymäßig Ahnung. Wenn ich wo helfen kann, selbst wenn es nur Code-Review ist, bin ich gerne behilflich. Allerdings wird es aufgrund von Zeitmangel aber eher nichts, dass ich mich um ganze "Module" kümmern kann. Falls Interesse besteht, bitte mich direkt ansprechen ... :)

Gruß,
Jem
 
Hallo Alex,

wenn noch mehr an dem Projekt arbeiten sollen, sollten wir eine Möglichkeit haben uns besser Auszutauschen. Immer alles in einem Thema wir unübersichtlich. Entweder einen Bugtracker für Fälle wie diesen SEN_MOTOR_MOW und einen Eigen Bereich im Forum für die Entwicklung z.B. als Unterforum von Software.

Stefan
 
Hi,

Alexander super Idee, ich wollte da auch schon was schreiben hatte aber kein Schreibrecht.

Dann können wir besser sehen welche Fehler wo auftauchen.

Wie gesehen hab hast du schon mit der Umstellung der Software angefangen ? Ardumower1 ?

Gruss Stefan
 
@StefanM: ich vermute mal man muss mit seinem Google Account angemeldet sein, dann sollte man Bugs melden können.

Und ja, ich habe schon mal angefangen, den Code neu zu strukturieren. Sieht doch gleich viel aufgeräumter aus :)
 
Ok i will add some code here.
It is still useful to bugfix the "r48 like" code for the old ardumower fork since you rewrite all the code using class?
 
@Max: Everything that will improve the code will be useful - If you actually tested and improved the code on Due, it is even more useful. We can always add the required changes to the latest code too. So, patches are always useful :)
 
Oben