comenzando desde cero (Starting from scratch)

[bigbadbob]

so with my last code, press the lights button once and release it.
serial should say lights on.
wait 8 seconds and see if spotlights come on.
press it again and release it.
serial should say lights off. wait 8 seconds and see if they go off.

the problem is that the master is trying to use two serial ports and the SPI bus for the ps2x at the same time.
there is a clash of microprocessor "interrupts" that are used by the libraries. (this is hard to translate.... )
rs485 will not solve this. your tx/rx wires are not long enough yet to need rs485.
I suggest you use two arduino's in the master. one to send commands and one to receive sensor data and display it.
this is the way I do it and I cannot see any other solution.

I'm not sure what you mean by "casco"... google translates it as "helmet"....
in english this means the thing a motorcyclist wears on his head but also means the head of your penis.
Something is being lost in translation.

[asesorplaza1]

Buenos días.

Aparte de los problemas de la interrupciones por causa de que Arduino está utilizando dos puertos serie, mas el bus SPI, efectivamente, tenemos un problema de traducción.

Con la palabra "casco", me refiero a la parte exterior del ROV, la carcasa impermeable, los tubos de los motores, la colocación de los focos exteriores, lo que sería el cuerpo del ROV, no a los motoristas, ni al miembro físico.

Buscando algo parecido en Ingles seria "the hull to the ROV"

Volviendo al problema de las comunicaciones.

No entiendo cómo puedo tener un Arduino dentro del ROV, y dos Arduinos en la superficie, y comunicar a los tres, supongo que sería utilizar uno como Maestro, que pasaría a ser el que está dentro del ROV, y los otros dos como esclavos, que son los que están en el puesto de control, si no es así, no veo como se puede hacer.

Otra posibilidad es, dejar como Maestro, uno de los -Arduinos del puesto de control como Maestro, por ejemplo el del mando, otro Arduino del puesto de control como Esclavo, el que recibe datos y los muestra en la pantalla, y otro Esclavo que es el que está dentro del ROV.

Seria estudiar las posibilidades que hay, pero siempre usando solo un Maestro, y hasta 132 Esclavos.

Estoy registrado también en un foro donde se dedican a la construcción de modelos de barcos, y me han hecho dos propuestas, un tanto deshonestas.

Una de ellas es, que como el programa es muy extenso, y bastante complicado, utilice la herramienta de programación Atom, y su complemento platformio, completamente compatible con el entorno Arduino, es una herramienta de programación profesional de código abierto.

https://docs.platformio.org/en/latest/w ... ormio.html

Pero no estoy muy entusiasmado con esto, puesto que supondría un retraso considerable, porque hasta que no sepa cómo funciona el programa, no puedo avanzar lo mas mínimo, y por lo que he visto, como decimos aquí, el programita se la trae, vamos que no es llegar y ya está, que necesita su curva de aprendizaje.

Y la otra propuesta es que para evitar problemas de velocidad de transmisión y capacidad de Arduino, cambie la placa por una placa Teensy, también compatible con el entorno de programación Arduino, pero con muchas más posibilidades que Arduino. Un procesador mucho más rápido, mucha más memoria RAM, ranura de tarjeta Micro SD, y un montón de cosas más.

https://www.pjrc.com/store/teensy41.html

He estado investigando un poco, en su foro, y he descubierto, que es la placa que controla el ROV Trident.

https://forum.pjrc.com/threads/27320-he ... hlight=rov

https://www.sofarocean.com/products/trident

Por lo tanto, no puede ser muy mala, que digamos.

Pero vuelvo a decirle lo mismo que con el programa, se pierde mucho tiempo con la curva de aprendizaje.

Un saludo.



Good morning.

Apart from the problems of interruptions because Arduino is using two serial ports, plus the SPI bus, we actually have a translation problem.

With the word "hull", I mean the outside of the ROV, the waterproof casing, the engine tubes, the placement of the outer spotlights, which would be the ROV's body, not the bikers, or the physical limb.

Looking for something similar in English would be "the hull to the ROV"

Back to the communications problem.

I do not understand how I can have an Arduino inside the ROV, and two Arduinos on the surface, and communicate to all three, I suppose it would use one as Master, which would happen to be the one inside the ROV, and the other two as slaves, who are the ones who are at the checkpoint, if not, I do not see how it can be done.

Another possibility is to leave as Master, one of the -Arduinos of the checkpoint as Master, for example the controller, another Arduino of the checkpoint as Slave, the one who receives data and shows it on the screen, and another Slave that is the one inside the ROV.

It would be to study the possibilities that there are, but always using only one Master, and up to 132 Slaves.

I am also registered in a forum where they are dedicated to the construction of models of ships, and have made me two proposals, somewhat dishonest.

One of them is, because the program is very extensive, and quite complicated, use the Atom programming tool, and its platform complement, fully compatible with the Arduino environment, is a professional open source programming tool.

https://docs.platformio.org/en/latest/w ... ormio.html

But I'm not very excited about this, since it would be a considerable delay, because until I know how the program works, I can't move forward the slightest bit, and from what I've seen, as we say here, the program says it, come on it's not to arrive and that's it, it needs its learning curve.

And the other proposal is that to avoid problems of transmission speed and Arduino capacity, change the board to a Teensy board, also compatible with the Arduino programming environment, but with many more possibilities than Arduino. A much faster processor, much more RAM, Micro SD card slot, and lots of other things.

https://www.pjrc.com/store/teensy41.html

I've been doing some research, in your forum, and I've discovered, which is the board that controls the ROV Trident.

https://forum.pjrc.com/threads/27320-he ... hlight=rov

https://www.sofarocean.com/products/trident

So, it can't be very bad, let's say.

But I say the same thing again as with the program, a lot of time is wasted with the learning curve.

Greetings.

[bigbadbob]

Yes, Hull is a better translation or if you want to be technical then "pressure vessel" is the part that contains the dry electronics etc.
Good luck with whatever way you decide to go.

my master has only the tx pin connected (via rs485) to the slave in the ROV.
my slave has rx and tx pins connected.
my display only has rx connected.
the rX from the slave (via the top side rs485 module) goes to the second microprocessor RX.
Master does not talk to display.
hope that helps.

[asesorplaza1]

Buenas tardes.

Entonces no utiliza un procedimiento Maestro /Esclavo, donde los dos Arduinos "hablan" y "escuchan" a la vez, o mas técnico, envían y reciben datos a la vez, como se define normalmente, donde hay un Arduino que hace de "jefe" o Maestro y otro de "súbdito" o Esclavo, sino que hace una comunicación en serie entre Arduinos, donde el Arduino que está en el interior del ROV, "habla", solo envía datos, a uno de los Arduinos del puesto de control, y solo "escucha", recibe datos, del otro Arduino del puesto de control, no utiliza la comunicación bidireccional, por lo tanto no hay "Maestro ni Esclavo", posiblemente ese procedimiento sea mas cómodo, y mejor para los tres Arduinos.

Lo que usted tiene sería algo así



RX (recibe) del Arduino de dentro del ROV, a TX (envía) del Arduino del puesto de control con el mando PS2.
TX (envía)del Arduino dentro del ROV, a RX(recibe) del Arduino del puesto de control con la pantalla, y a su vez TX de este Arduino del puesto de control a RX de la pantalla.

Un saludo


Good afternoon.

Then it does not use a Master/Slave procedure, where the two Arduinos "talk" and "listen" at the same time, or more technically, send and receive data at the same time, as is normally defined, where there is an Arduino that plays "boss" or Master and another of "subject" or Slave, but it makes a serial communication between Arduinos, where the Arduino that is inside the ROV, "speaks", only sends data, to one of the Arduinos of the checkpoint, and only "listen", receives data, from the other Arduino of the checkpoint, does not use two-way communication, therefore there is no "Master or Slave", possibly that procedure is more comfortable, and better for the three Arduinos.

What you have would be something like this



RX (receives) from the Arduino from within the ROV, to TX (sends) of the Arduino checkpoint with the PS2 controller.
TX (sends) from the Arduino within the ROV, to RX(receive) from the Arduino control station with the display, and in turn TX of this Arduino control station to RX screen.

A greeting

[bigbadbob]

yes, that is almost exactly what I have.
my display microprocessor is part of a "MinimOSD" head up display module (google it) that displays the sensor data on the same screen as the ROV camera video.
The MinimOSD has an Atmega8 processor with "arduino mini" bootlaoder already installed so I have written a sketch for it to display my data and leak warning etc. I also had to upload a new character set to the display chip but that is easy to do via the Atmega8.

[asesorplaza1]

Buenas tardes.

En vista de que los RS485, aunque mejoren la comunicación, no van a solucionar los problemas de comunicación, y no me han llegado aun, y por lo que usted me comenta, Arduino se hace un enredo con las comunicaciones entre los Puertos Serie, y el bus SPI, para el mando.

Cambiar de IDE de programación es un enredo para mi, por la curva de aprendizaje, y los tableros Teensy, no son fáciles ni baratos de conseguir en España.

Creo que la mejor solución es cambiarle el nombre al programa que está dentro del ROV, de “Esclavo” a “Interior del ROV”, y dividir el programa “Maestro“ en dos subprogramas, uno que se llame “Control del ROV”, que será el que maneje solo el mando de PS2, y otro subprograma que se llame “Sensores del ROV”, que será el que reciba los datos de los sensores y los envíe a la pantalla Nextion.

Porque si no, vamos a estar calentándonos la cabeza, los dos, para no conseguir solucionar los problemas que tengo ahora, y estoy viendo, que si Arduino se enreda ahora, que es la parte más fácil del gestionar el programa, solo los sensores y sus datos, y solo el mando, cuando se tenga que comunicar además con la pantalla Nextion, el Arduino se va a enredar más aun, y los problemas se van a multiplicar.

De todas formas, llevo mucho tiempo pensando, que la gente que se mete en un proyecto similar, una de dos, o tiene que tener toda la suerte del mundo y ningún problema de programación, cosa que yo dudo mucho, o no dicen la verdad de lo complicado del proyecto, ni de los problemas que tienen para desarrollarlo, y por supuesto, no dicen nada de las soluciones que adoptan para sacar el proyecto adelante.

Y ya lo he escrito en este foro en otro tema, sigo creyendo que soy el ser más tonto, y con menos suerte de la galaxia, por no poder solucionar los problemas que tengo para terminar el proyecto de una manera laboriosa, porque lleva trabajo, pero sencilla, porque no creo que sea necesario hacer una carrera de Ingeniero Superior en Mecatrónica, para hacer un ROV, ya que no estoy pretendiendo mandar un cohete lleno de pasajeros a la luna.

Así es que voy a dividir el programa Maestro en dos, y ya le seguiré contando mis penas en otro momento.

Un saludo.



Good afternoon.

Since the RS485, even if they improve communication, will not solve the communication problems, and have not yet come to me, and from what you say, Arduino gets a mess with the communications between the Serial Ports, and the SPI bus, for the command.

Switching programming ID is a tangle for me, because of the learning curve, and Teensy boards, are not easy or cheap to get in Spain.

I think the best solution is to rename the program inside the ROV, from "Slave" to "Inside the ROV", and to divide the program "Master" into two subprograms, one called "ROV Control", which will be the one that handles only the PS2 command, and another subprogram that is called "ROV Sensors", which will be the one that receives the data from the sensors and sends them to the Nextion screen.

Because if not, we're going to be warming our heads, both of us, so as not to get the problems that I have now, and I'm seeing, that if Arduino gets tangled now, which is the easiest part of managing the program, only the sensors and their data, and only the controller, when you have to communicate also with the Nextion screen, the Arduino is going to get even more tangled , and the problems are going to multiply.

Anyway, I've been thinking for a long time, that people who get into a similar project, one of two, or have to have all the luck in the world and no programming problem, which I doubt very much, or they don't tell the truth about the complicated project, or the problems they have to develop it, and of course, they don't say anything about the solutions they adopt to get the project going.

And I have already written it in this forum on another topic, I still believe that I am the dumbest being, and with the least luck in the galaxy, because I cannot solve the problems that I have to finish the project in a laborious way, because it takes work, but simple, because I do not think it is necessary to make a career of Superior Engineer in Mechatronics , to make a ROV, since I'm not pretending to send a rocket full of passengers to the moon.

So I'm going to split the Master program in two, and I'll keep telling you my sorrows some other time.

Greetings.

[asesorplaza1]

Buenas noches.

Muchas gracias por su tiempo, y por la aportación de soluciones, a mis problemas con el programa de control del ROV.

Siguiendo sus instrucciones, he dividido el antiguo programa “Maestro”, en dos subprogramas, uno solo tiene las instrucciones del mando, y el otro solo tiene las instrucciones de los sensores.

Pero lamento tener que decirle, que no ha cambiado nada, programa que tiene que recibir las instrucciones del mando, no hace nada.

Le adjunto los tres programas, por si usted tuviera suerte, y encontrase donde está el fallo, porque yo no veo, ahora que el programa está más claro, sin las instrucciones de los datos de los sensores.

Un saludo.


Good night.

Thank you very much for your time, and for the contribution of solutions, to my problems with the ROV control program.

Following your instructions, I have divided the old "Master" program into two subprograms, one has only the command instructions, and the other only has the instructions of the sensors.

But I'm sorry to have to tell you, nothing has changed, program that has to receive instructions from the command, does nothing.

I attach the three programs, in case you were lucky, and find where the fault is, because I do not see, now that the program is clearer, without the instructions of the sensor data.

Greetings.

[bigbadbob]

OK, good plan. now get yourself 3 nano's and you can use my working code after a few changes to the display sketch.


I see a problem straight away, you are sending debug serial data....
"Serial.println (F("\n Controlador encontrado y configurado con éxito"));" etc...
as well as Easy-transfer data down the same serial port to the ROV.
Easy-transfer will not like the debug stuff. you have to delete all serial.print and serial.println commands from the old master.

[asesorplaza1]

Buenas tardes.

Ya he suprimido los Serial.print, del programa que controla el mando de la PS2, la única duda que me queda, es como me va a indicar el otro Arduino, el estado de los focos, ahora esta así en el código.

Good afternoon.

I have already deleted the Serial.print, from the program that controls the PS2 command, the only doubt that I have left, is how the other Arduino, the state of the spotlights, is now so in the code.

Code: Select all

if (ps2x.Button(PSB_PAD_LEFT))                     // Lee el valor del botón Izquierda Izquierda al Esclavo
      {
        PSB_PAD_LEFTstate = (!PSB_PAD_LEFTstate);        // Lectura del estado del botón
        txdata.LEDHdlts = PSB_PAD_LEFTstate;             // Guarda que hacer con el estado de los focos, encendido / apagado
        digitalWrite(yelLEDpin, PSB_PAD_LEFTstate);      // Enciende el Led Amarillo
        if(txdata.LEDHdlts)
        {
        Serial.print (F("\n Focos apagados"));           // Imprime la frase "Focos apagados"
      }
      else
      {
        
        if (!txdata.LEDHdlts)
        {
        digitalWrite(yelLEDpin, LOW);                    // Apaga el led amarillo
        Serial.print (F("\n Focos encendidos"));         // Imprime la frase " Focos encendidos"
      }

Si quito este Serial.print, también, no me marcara como están los focos, si están encendidos, o si están apagados
Por lo tanto debería poner algo así en el programa llamado “02 Control Sensores y Pantalla”



If I remove this Serial.print, too, I won't mark it as the spotlights are, if they're on, or if they're off
So you should put something like that in the program called "02 Control Sensors and Display"

Code: Select all

Struct RECEIVE_DATA-STRUCTURE

Int LEDHdlts

Void setup

Void loop

If (LEDHdlts < 0)
{
Serial.print (F(“n Focos Apagados);
digitalWrite(yelLEDpin, LOW);
}

if (LEDHdlts > 0)
{
Serial.print (F(“n Focos Encendidos);
digitalWrite(yelLEDpin, HIGT);
}

Gracias, un saludo.

Thank you, a greeting.

[bigbadbob]

Yes, something like that, but remove it first and check that the ROV can be controlled by the controller.
Then once that works, we will need to make some changes to slave and display codes.
we still have a lot of work to do but I hope we are moving in the right direction one step at a time.