I need a FAIL SAFE

this went my first idea

easy widget with a feqently blinking ( changeing value ) maybe 5 blinks in a sek talk to a virtual pin . litle timer and .
if the robot is not geting the blinks = fail connection = stop motors

but if you do a button to hold is not working beacause if your phone lose conntact even you have a push button it will not go back its just on

i think a frequenly changing value is the option
thinking about the phone sensor accelerometer
then you have to hold your phone and move it a litle bit to get that " changing value "

Hmm, a sort of digital debounce for your phone to see if it’s alive. That could probably work, but if you put your phone or tablet in a sort of holder-thing on a table to drive the robot, it will not work. The heartbeat signal would be a better idea, but you have to invent something to send something and than receive a response. After that determine if the connection is alive and I’m not sure that can be done. Since you cannot send signals from the app to the hardware on a timer based something.

From the docs:

That’s why Blynk uses HEARTBEAT mechanism. With this approach hardware periodically sends ping command with predefined interval (10 seconds by default, BLYNK_HEARTBEAT property). In case hardware don’t send anything within 10 seconds server waits additional 5 seconds and after that connection assumed to be broken and closed by server. So on UI you’ll see connection status update only after 15 seconds when it is actually happened.

You can also change HEARTBEAT interval from hardware side via Blynk.config. In that case newHeartbeatInterval * 2.3 formula will be applied. So in case you you decided to set HEARTBEAT interval to 5 seconds. You’ll get notification regarding connection with 11 sec delay in worst case.

So it’s possible to change the frequency of the heartbeat signal. That way you can use Blynk.connected() to stop movement if you set it to a very fast frequency. I’m not sure the Blynk cloud server will like that, so I’d recommend using a rasperry pi local server for this or something similar. That way you are in full control of all your factors.

i could use more than one maybe accelerometer and light and gps and if all values dont change in time = stop motors

i think the heardbeat funktion is only from pi or arduino to server and not arduino to phone

what in now is you chan set the heardbeat to 1 sek

Thank you for letting us know who they are… I wasn’t sure before now.

a·nal·o·gy
noun
A comparison between two things, typically for the purpose of explanation or clarification.

RC vehicle = Line of sight realtime control, loss/interruption of signal tends to have vehicle out of control.

Mars Rover = Send short controlled movements to vehicle that will not run away when out of communication with controller.

I would have thought this was common sense and not an issue to blow a gasket over, but then it has been over 50 posts where others have tried to help, but stubbornness prevails.

There is NO easy code or solution… that is my entire point! A proper, functional fail-safe for a moving object controlled remotely will depend entirely on your infrastructure, robot style, control methodology and coding skills.

Stop asking for easy!! Make some actual attempts and show us some actual code that you have written and then maybe we can help.

Mate, go out get some fresh air, take a chill pill and move on to the next thread :wink: I can see that your batteries are burnt :smiley:

I have been chilling and watching movies all evening… no stress here :smiley: just low tolerance for those who demand without showing effort, respond in anger without thought and refuse to accept ideas when presented.

But you are free to write him some easy code if you want…:wink:

1 Like

Guys, c’mon. If you don’t like what someone has to say, move on to the next thread indeed :slight_smile:

We are all enthusiasts here doing fun stuff for their hobby (most of us anyway). Everybody has a point here. @Gunner makes a sane point, I haven’t seen any code yet and that would be handy.

It would certainly be an option to use all the Phones sensors as @stefan8484 suggests. I haven’t been really busy with that lately, but it could be a viable alternative. There are plenty of examples for using them in the Arduino library part.

I think however, it’s more important to check the connection from the robot to the phone than from the phone to the server, but in any given real time solution it’s best to check both. However, Blynk has proven to be rockstable and if you use a local server, as I indicated it gives you loads of advantages:

  1. Free energy, you can build all the dashboards, sharing and whatever you like
  2. You are in full control
  3. The communication, especially wired will have almost 0 latency
  4. The communication will be rock solid and stable, so you won’t need fancy heartbeat tricks
2 Likes

its just a rc singnal and how smart the moving object is is not important its just the way it recive data by radio signals …

no cable from eart to mars …no light or sound signals its a f…ing radio signal thats the point .

Haha I hear you! Oh nono I have my own code to fight with ;D

1 Like

@Fettkeewl @Lichtsignaal

And you both have made a great point… I have been trying to help this ‘character’ since the beginning, but it is time for me to give up on him. He is now fixating on non-relevant things like radio signals in a vacuum and completely ignoring everything important to his request. :confounded: Not to mention bad language!

I am also removing the notification flag so I don’t have to watch this mudslide anymore. But I will see you two again in a better thread :wink:

1 Like

thanks for your “help?!”

detachInterrupt()
Description

Turns off the given interrupt.
Syntax
detachInterrupt(interrupt)
detachInterrupt(digitalPinToInterrupt(pin));
detachInterrupt(pin) (Arduino Due, Zero only)
Parameters

interrupt: the number of the interrupt to disable (see attachInterrupt() for more details).
pin: the pin number of the interrupt to disable (Arduino Due only) 

See also

attachInterrupt()

attachInterrupt()
Description

Digital Pins With Interrupts

The first parameter to attachInterrupt is an interrupt number. Normally you should use digitalPinToInterrupt(pin) to translate the actual digital pin to the specific interrupt number. For example, if you connect to pin 3, use digitalPinToInterrupt(3) as the first parameter to attachInterrupt.
Board Digital Pins Usable For Interrupts
Uno, Nano, Mini, other 328-based 2, 3
Mega, Mega2560, MegaADK 2, 3, 18, 19, 20, 21
Micro, Leonardo, other 32u4-based 0, 1, 2, 3, 7
Zero all digital pins, except 4
MKR1000 Rev.1 0, 1, 4, 5, 6, 7, 8, 9, A1, A2
Due all digital pins
101 all digital pins
Note

Inside the attached function, delay() won’t work and the value returned by millis() will not increment. Serial data received while in the function may be lost. You should declare as volatile any variables that you modify within the attached function. See the section on ISRs below for more information.
Using Interrupts

Interrupts are useful for making things happen automatically in microcontroller programs, and can help solve timing problems. Good tasks for using an interrupt may include reading a rotary encoder, or monitoring user input.

If you wanted to insure that a program always caught the pulses from a rotary encoder, so that it never misses a pulse, it would make it very tricky to write a program to do anything else, because the program would need to constantly poll the sensor lines for the encoder, in order to catch pulses when they occurred. Other sensors have a similar interface dynamic too, such as trying to read a sound sensor that is trying to catch a click, or an infrared slot sensor (photo-interrupter) trying to catch a coin drop. In all of these situations, using an interrupt can free the microcontroller to get some other work done while not missing the input.
About Interrupt Service Routines

ISRs are special kinds of functions that have some unique limitations most other functions do not have. An ISR cannot have any parameters, and they shouldn’t return anything.

Generally, an ISR should be as short and fast as possible. If your sketch uses multiple ISRs, only one can run at a time, other interrupts will be executed after the current one finishes in an order that depends on the priority they have. millis() relies on interrupts to count, so it will never increment inside an ISR. Since delay() requires interrupts to work, it will not work if called inside an ISR. micros() works initially, but will start behaving erratically after 1-2 ms. delayMicroseconds() does not use any counter, so it will work as normal.

Typically global variables are used to pass data between an ISR and the main program. To make sure variables shared between an ISR and the main program are updated correctly, declare them as volatile.

For more information on interrupts, see Nick Gammon’s notes.
Syntax
attachInterrupt(digitalPinToInterrupt(pin), ISR, mode); (recommended)
attachInterrupt(interrupt, ISR, mode); (not recommended)
attachInterrupt(pin, ISR, mode) ; (not recommended Arduino Due, Zero, MKR1000, 101 only)
Parameters
interrupt: the number of the interrupt (int)
pin: the pin number (Arduino Due, Zero, MKR1000 only)
ISR: the ISR to call when the interrupt occurs; this function must take no parameters and return nothing. This function is sometimes referred to as an interrupt service routine.
mode:

defines when the interrupt should be triggered. Four constants are predefined as valid values:

LOW to trigger the interrupt whenever the pin is low,
CHANGE to trigger the interrupt whenever the pin changes value
RISING to trigger when the pin goes from low to high,
FALLING for when the pin goes from high to low. 

The Due board allows also:

HIGH to trigger the interrupt whenever the pin is high. 

(Arduino Due, Zero, MKR1000 only)

Returns

none
Example

const byte ledPin = 13;
const byte interruptPin = 2;
volatile byte state = LOW;

void setup() {
pinMode(ledPin, OUTPUT);
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(digitalPinToInterrupt(interruptPin), blink, CHANGE);
}

void loop() {
digitalWrite(ledPin, state);
}

void blink() {
state = !state;
}
[Get Code]

Interrupt numbers

Normally you should use digitalPinToInterrupt(pin), rather than place an interrupt number directly into your sketch. The specific pins with interrupts, and their mapping to interrupt number varies on each type of board. Direct use of interrupt numbers may seem simple, but it can cause compatibility trouble when your sketch is run on a different board.

However, older sketches often have direct interrupt numbers. Often number 0 (for digital pin 2) or number 1 (for digital pin 3) were used. The table below shows the available interrupt pins on various boards.

so now i going this way
give a interrupt for normal
and detachInterrupt if virtuall pin (accelerometer) changes …

will this work ???

I’m not sure how this will work. I can’t really see how an interrupt will help you here. The funtion of interrupt is, as it says, to interrupt the normal program routine and start doing something else.

I’m not even sure if interrupts can be used with virtual pins. I think it’s not even possible since interrupt is hardware based and a virtual pin is software based.

ok wrong way .
question is how to stop pin3 if virtual pin 1 stops changing values

Usually you do that if a pin (virtual or otherwise) changes once. E.g. from 0 to 1 or the other way around. This is all very difficult. If the vPin is either 0 or 1 (for example) the program is fine, but if it’s changing within a certain amount of time, something is wrong. You are gonna have to do something with simpletimer I think, but I still can’t see how to do this in practice.

I was wondering though, is this really a problem? We are trying to figure out how to stop the robot, but is it really needed to do so? Did you ever encounter problems with lost connections?

no just if i simulate a connection failure or close app and holding the joystick in a moving position wile driving