Where to go for algorithmic programming advice?

Forums › Off topic › Where to go for algorithmic programming advice?

Talkiet

4786 posts

Uber Geek

Trusted

#238242 8-Jul-2018 14:13

Not sure it's worth detailing here, but I have a problem and I'm not having a lot of luck thinking of a way to solve it. It's to do with essentially 1D edge detection on a set of 16 temperature values, trying to detect an object crossing that 1D line... The programming is easy, but I'm stuck for ideas about how to classify each edge of the object reliably.

Any good forums that would be suitable for this (as opposed to generic programming assistance?)

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

hio77

'That VDSL Cat'
12999 posts

Uber Geek

ID Verified

Trusted

Lizard Networks

Subscriber

#2051503 8-Jul-2018 14:26

Can't help on the issue itself but is this that tire circuit still?

#include <std_disclaimer>

Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.

Sharesies

Trade NZ and US shares and funds with Sharesies (affiliate link).

Talkiet

4786 posts

Uber Geek

Trusted

#2051508 8-Jul-2018 14:34

hio77:

Can't help on the issue itself but is this that tire circuit still?

Yep, instead of a 3 single point IR temp sensors (MLX90614) I have build a 2.4Ghz connected battery powered 16x4 IR array sensor module with a Nano at each wheel. Currently each wheel sensor averages the 4 values for each of the 16 columns and sends back a 16 byte data structure (so half degree resolution up to 128C) to a Teensy 3.5 in the digital Dash and logger unit.

That's all fine for visualisation, but detecting what of the 16 cells are Tyre, and what are spill on each side is proving non trivial. I haven't even coded a first attempt up yet but absolute thresholds, and a fixed range of points are non-starters as I need this solution to allow for mounting variances and perhaps even moving tyres (if steering or suspension movement moves the tyre within the FOV)

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

frankv

5678 posts

Uber Geek

Lifetime subscriber

#2051602 8-Jul-2018 17:33

I'm struggling to get what you're doing. AFAICT, you have a row of 4 IR sensors across the inside of the wheel arch? And, as the wheel moves due to steering or suspension, it is aligned with one or more of the sensors.

Soooo.. presumably the highest temperature from the array is the temperature of the tyre?

Talkiet

4786 posts

Uber Geek

Trusted

#2051620 8-Jul-2018 18:22

frankv:

I'm struggling to get what you're doing. AFAICT, you have a row of 4 IR sensors across the inside of the wheel arch? And, as the wheel moves due to steering or suspension, it is aligned with one or more of the sensors.

Soooo.. presumably the highest temperature from the array is the temperature of the tyre?

Kind of - I want to measure the outside edge temp, middle temp, and inside edge temp of the tyre under race conditions

This is a data overlay from a previous HW iteration using 3 discrete sensors per tyre...

https://www.youtube.com/watch?v=Sf3G0DhfiYo

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

irongarment

280 posts

Ultimate Geek
Inactive user

#2051640 8-Jul-2018 19:12

How about signing up to Stack Exchange and submitting your question there?

zxspectrum

25 posts

Geek

#2051669 8-Jul-2018 19:59

Could you compare values from adjacent sensors? A large differential from one sensor to the next could indicate the tyre edge. Just a thought.

irongarment

280 posts

Ultimate Geek
Inactive user

#2051705 8-Jul-2018 20:36

How about using an FLIR sensor? It would give you a thermal image across ientire field of view, and you can test the physical range of motion of the tyre with respect to the camera to be sure it's always in view.

Next, and this might work with your existing sensor array, do a centroid calculation to find the "centre of mass" of the heat, then threshold just below that to figure out which sensors (or pixels) are pointing at air.

frankv

5678 posts

Uber Geek

Lifetime subscriber

#2051728 8-Jul-2018 21:30

Ah, OK. You have 16 sensors across the inside of the wheel arch. Some of these sensors are aimed at the tyre, some at thin air (some maybe at the brake disc?). If you know the width of the tyre and the distance between sensors, you know how many sensors are aimed at the tyre, but not necessarily which ones.

You could look at digital filters of each of the 16 datastreams, looking for a sudden increase or decrease, which would indicate that it was going onto/off the tyre edge. Digital filtering sounds difficult and compute-intensive, but I did this kind of stuff with seismic sensors back in the 80s with 1MHz 8-bit CPUs (2 channels of 16-bit data). Keep a running total of weighted values (e.g. F = new * 3/4 + F/4 is a simple smoothing filter). Probably better would be to look at the differences between adjacent sensor values; the tyre edge is where there's a big difference in temperature (I assume).

Probably the first thing to do is to simply log all 16 channels for each wheel, and then you can analyse them at your leisure. I've used Excel for this kind of analysis quite successfully. Maybe include a pushbutton in your logging, so that you can click at points of interest (e.g. the entry to a corner).

Talkiet

4786 posts

Uber Geek

Trusted

#2051739 8-Jul-2018 22:18

frankv:

Ah, OK. You have 16 sensors across the inside of the wheel arch. Some of these sensors are aimed at the tyre, some at thin air (some maybe at the brake disc?). If you know the width of the tyre and the distance between sensors, you know how many sensors are aimed at the tyre, but not necessarily which ones.

You could look at digital filters of each of the 16 datastreams, looking for a sudden increase or decrease, which would indicate that it was going onto/off the tyre edge. Digital filtering sounds difficult and compute-intensive, but I did this kind of stuff with seismic sensors back in the 80s with 1MHz 8-bit CPUs (2 channels of 16-bit data). Keep a running total of weighted values (e.g. F = new * 3/4 + F/4 is a simple smoothing filter). Probably better would be to look at the differences between adjacent sensor values; the tyre edge is where there's a big difference in temperature (I assume).

Probably the first thing to do is to simply log all 16 channels for each wheel, and then you can analyse them at your leisure. I've used Excel for this kind of analysis quite successfully. Maybe include a pushbutton in your logging, so that you can click at points of interest (e.g. the entry to a corner).

Actually, it's all a single 64 point sensor in a 16x4 array - look up MLX90621... (and MLX90640 - although that's overkill and would require too much processing on the wheels)

The system is already up and running with the 3 points - there's good logging of GPS, time, CANbus data, other telemetry like oil pressure, brake actuation and brake disc temp as well actually etc... I currently log 3 points per tyre. My initial integration will be to log all 16 values for each wheel as well but ultimately for display purposes I want to be able to derive inner, middle and out temperatures. With those 3 per wheel I can do wheel to wheel comparisons on the fly and highlight in real time if there's an imbalance (which would mean I need to change geometry or tyre pressures)...

I like the idea of just getting the data first and playing with it - that's probably a good idea and I'd be able to eyeball the algorithm's accuracy in realtime by comparing it with an overlay of the 16 raw values - the human eye/brain is brilliant at detecting how well patterns match - or don't...

The digital dash I built has a dash for logging - everything goes to a MicroSD card every 100ms....

The tyre edge detection is the hard one - there's likely to be a value which is half on and half off the tyre edge - but it is likely to be only one I guess - so I could do some crude looking for a temp diff and then stepping one more in towards the centre. When I have the inside and outside, the middle is easy :-)

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

elpenguino

3343 posts

Uber Geek

#2051747 8-Jul-2018 23:19

interesting project. Temperature differences will give you some idea of where the sensor is detecting a tyre and where it is detecting fresh air but i think you also need time and/or absolute temperature in your algorithm cos how will the system work when your tyres are not warmed up?

If you have all the temperature values in an array (say from left to right) then you can iterate through the array looking for differences , if not between adjacent values then you can try adjacent pairs or what not.

Dynamically find the range of values that are hotter than fresh air and you can take the middle index's value as your centre - this way you won't be hard coded to a certain tire size or suspension adjustment.

For front tyres , what will you do to allow for tyres that turn in and out of the sensor's field of view? Will you system respond fast enough or will you average everything out over time? Or is the sensor's FOV axis very close to a radius of the tyre?

The good thing about gathering the raw data in excel is you can run it through any trial algorithms and see if the result looks like you expect.

Most of the posters in this thread are just like chimpanzees on MDMA, full of feelings of bonhomie, joy, and optimism. Fred99 8/4/21

frankv

5678 posts

Uber Geek

Lifetime subscriber

#2051775 9-Jul-2018 08:28

Talkiet:

I like the idea of just getting the data first and playing with it - that's probably a good idea and I'd be able to eyeball the algorithm's accuracy in realtime by comparing it with an overlay of the 16 raw values - the human eye/brain is brilliant at detecting how well patterns match - or don't...

If you can, get the absolute raw data for playing with; if what you log has already been averaged, you can lose some useful information.

The tyre edge detection is the hard one - there's likely to be a value which is half on and half off the tyre edge - but it is likely to be only one I guess - so I could do some crude looking for a temp diff and then stepping one more in towards the centre. When I have the inside and outside, the middle is easy :-)

Yeah... this is where digital filters can help. You can use them to differentiate and amplify and so on. If you treat the 16x4 as a grey-scale image, you could apply 2D image processing filters to sharpen or edge-detect (e.g. Sobel filter... https://stackoverflow.com/questions/17815687/image-processing-implementing-sobel-filter).

I think my aim would be to have all the processing for each tyre done at the tyre, and only send the 3 values you want back to the dash. I think I'd also start with overkill at the tyre, with a system there that does all the logging and has more than enough processing power to do whatever calculations you might want. Once you figure out what the right calculations are, maybe spend a bit of time on recoding to do all calculations with integer-only maths. Then resize the processor downward to match. Or just stick with the grunty machine; the price difference will probably only be a couple of dollars.