Init and reading sensor error handling

[Gabor Schilten]

Hi,

I am trying my service not to crash when a sensor eather isn't there at all, so the init would fail, or the sensor would later stop functioning.

What is in your opinion the best way to ensure the loop keeps running when eather init or read commands fail?

Thank you.

Gabor

[Ytai Ben-Tsvi]

There's no reason why a service would crash as result of a problem with a sensor. It's probably something with the way your software handles the sensor not being there. What sensor is this? What does your code look like?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.
To post to this group, send email to ioio-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

[Gabor Schilten]

Hi Ytai,

Thank you for responding this fast.

I had problems when I tried to initialize SR04's and read their data later on, if the initialization wasn't succesfull, the value reading just hang.

I solved that with the timer, really nice.

However, i'd like to have a clear status of all my sensors at all times. If a sensor fails, I'd like it to be re-initialized, but as long as that fails, it's a waste of time querying that sensor for data don't you think?

So I introduced a boolean for everyone of them, and try find out how I can be sure the sensor works or not.

Could you give me some pointers?

Op zaterdag 29 augustus 2015 18:34:00 UTC+2 schreef Ytai:

[Ytai Ben-Tsvi]

Not sure what you mean by re-initialized, this sensor doesn't seem to have any initialization associated with it.

Anyway, if you want the readings to take place in parallel, just create a separate thread for each sensor and have those threads report their readings (possibly with timestamps) to a centralized location where you can have another thread pick them up.

[Gabor Schilten]

Thanks. Started to do that yesterday evening.
Looking promising.
What way do you advise to share readings to the main service from these threads?

[Ytai Ben-Tsvi]

The simplest way is probably to have an array of sensor readings, where each thread writes to a single index. Lock the array whenever reading/writing so you don't run into race conditions.

[Gabor Schilten]

Will get that tested.

Lidar sensor is now running in its own thread, and so are the ultrasonics (all in one thread because I poll them after each other with some time between to prevent pickup from each others pings.)

Will finally do a new test run tomorrow! finally looking more stable now.

I have to look into closing the threads when connection is broken, that isn't working ok now.

Have to reset the app (service) to make it work again after a connection lost.

But that's for next time ;)

Op zondag 30 augustus 2015 18:29:58 UTC+2 schreef Ytai:

[Gabor Schilten]

Multithreading works like a charm, as you said.

Still tuning the disconnects to make it flawless, but getting there.

Opening another post about max amount of inputs.. have an interesting project.

Op zondag 30 augustus 2015 22:27:16 UTC+2 schreef Gabor Schilten: