Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


3740 posts

Uber Geek
+1 received by user: 2270

Trusted
Spark NZ

Topic # 238242 8-Jul-2018 14:13
Send private message

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

 

 


Create new topic
'That VDSL Cat'
8894 posts

Uber Geek
+1 received by user: 1951

Trusted
Spark
Subscriber

  Reply # 2051503 8-Jul-2018 14:26
Send private message

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.




3740 posts

Uber Geek
+1 received by user: 2270

Trusted
Spark NZ

  Reply # 2051508 8-Jul-2018 14:34
Send private message

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

 

 


2494 posts

Uber Geek
+1 received by user: 1219

Lifetime subscriber

  Reply # 2051602 8-Jul-2018 17:33
Send private message

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?




3740 posts

Uber Geek
+1 received by user: 2270

Trusted
Spark NZ

  Reply # 2051620 8-Jul-2018 18:22
Send private message

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


153 posts

Master Geek
+1 received by user: 67


  Reply # 2051640 8-Jul-2018 19:12
2 people support this post
Send private message

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

21 posts

Geek
+1 received by user: 13


  Reply # 2051669 8-Jul-2018 19:59
One person supports this post
Send private message

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


153 posts

Master Geek
+1 received by user: 67


  Reply # 2051705 8-Jul-2018 20:36
Send private message

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.

2494 posts

Uber Geek
+1 received by user: 1219

Lifetime subscriber

  Reply # 2051728 8-Jul-2018 21:30
Send private message

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).

 

 




3740 posts

Uber Geek
+1 received by user: 2270

Trusted
Spark NZ

  Reply # 2051739 8-Jul-2018 22:18
Send private message

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

 

 


696 posts

Ultimate Geek
+1 received by user: 249


  Reply # 2051747 8-Jul-2018 23:19
Send private message

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.

 

 

 

 


2494 posts

Uber Geek
+1 received by user: 1219

Lifetime subscriber

  Reply # 2051775 9-Jul-2018 08:28
Send private message

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.

 

 


Create new topic

Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.