search

ten-point-nine / freETarget

Electronic Air Rifle Target
84 stars 42 forks source link

Port to ESP32? #30

Open AussieMakerGeek opened 2 years ago

AussieMakerGeek commented 2 years ago

I've spent several hours going over the code and the circuit schematic and I'm wondering if there might be an advantage to moving to a newer/faster microcontroller.

Although I don't yet completely understand the project in the detail I'm sure you do, I can see that you are sampling the microphones at 32mhz and using the binary counters for the timing, and then reading it back back in to overcome the limitations of the clock speed and analog sampling rate of the Atmega chip. Did I understand that correctly?

I have done some initial testing using an ESP32 which runs at 240Mhz (vs 16Mhz of the Atmega) and some basic microphone modules (The ones that just have a comparator chip to give a binary output) just using interrupts and it is looking very promising. I can get repeatable timings for impact points (within the parameters of the testing environment/code i have made). The ESP32 is also Dual core so we can run timing functions separate from the main loop if needed.

Moving to this microcontroller would mean the large amount of pins needed to control the extra chips would not be needed and the accompanying circuit board would be much simpler to construct, reducing the overall cost to build one (and possibly not even needed). It's early days and obviously I am not experienced in all of the intricacies of this project that I am sure you are aware of so can you see any reason my logic is flawed and this would not work?

ESP32 is about half the price of the Atmega and outperforms it in every way other than raw I/O pins, has built in Wifi so no need for external ESP-01 module and also has Bluetooth which can be used as a virtual com port to PC instead of USB. With the addition of some very basic modules that are easily available (such as the temperature sensor and Stepper driver or fets), it could be a full functioning system but would require a massive rewrite of the code. I am happy to chainsaw in some code to yours as a deeper POC that you could potentially offer as a branch, or I could fork it into a separate project. The problem with that would be that it would be hard to incorporate revision changes to your code back into mine.

What are your thoughts?

ten-point-nine commented 2 years ago

Hello

You are fundamentally correct in your understanding. I’ve looked at an ESP, but I’ve been busy making housings.

I would not use an interrupt for the timing. The latency between the interrupt and it’s processing would not be deterministic, not to the level needed to accurately measure the time time interval between microphone pings. My thought was to use the comparators and use them to gate the on-board counters. I would also look at using two comparators on each signal and a total of eight counters.

At this moment in time, most of the software changes I am making are for controlling the operation of the target using the multifunction switches. Today I added a switch sequence for setting the LED brightness.

Probably the best thing is for you to fork it into your own project. Much of the I/O type things have been abstracted in gipo.ino, analog.ino, and nonvol.ino. The rest are somewhat platform independent.

Allan

On May 1, 2022, at 8:04 PM, Drew @.***> wrote:

I've spent several hours going over the code and the circuit schematic and I'm wondering if there might be an advantage to moving to a newer/faster microcontroller.

Although I don't yet completely understand the project in the detail I'm sure you do, I can see that you are sampling the microphones at 32mhz and using the binary counters for the timing, and then reading it back back in to overcome the limitations of the clock speed and analog sampling rate of the Atmega chip. Did I understand that correctly?

I have done some initial testing using an ESP32 which runs at 240Mhz (vs 16Mhz of the Atmega) and some basic microphone modules (The ones that just have a comparator chip to give a binary output) just using interrupts and it is looking very promising. I can get repeatable timings for impact points (within the parameters of the testing environment/code i have made). The ESP32 is also Dual core so we can run timing functions separate from the main loop if needed.

Moving to this microcontroller would mean the large amount of pins needed to control the extra chips would not be needed and the accompanying circuit board would be much simpler to construct, reducing the overall cost to build one (and possibly not even needed). It's early days and obviously I am not experienced in all of the intricacies of this project that I am sure you are aware of so can you see any reason my logic is flawed and this would not work?

ESP32 is about half the price of the Atmega and outperforms it in every way other than raw I/O pins, has built in Wifi so no need for external ESP-01 module and also has Bluetooth which can be used as a virtual com port to PC instead of USB. With the addition of some very basic modules that are easily available (such as the temperature sensor and Stepper driver or fets), it could be a full functioning system but would require a massive rewrite of the code. I am happy to chainsaw in some code to yours as a deeper POC that you could potentially offer as a branch, or I could fork it into a separate project. The problem with that would be that it would be hard to incorporate revision changes to your code back into mine.

What are your thoughts?

— Reply to this email directly, view it on GitHub https://github.com/ten-point-nine/freETarget/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCD5LORY2GZDXR6UPPRD5LVH4S3HANCNFSM5U2V3VLA. You are receiving this because you are subscribed to this thread.

AussieMakerGeek commented 2 years ago

I would not use an interrupt for the timing. The latency between the interrupt and it’s processing would not be deterministic, not to the level needed to accurately measure the time time interval between microphone pings.

Although there is a latency, it would be consistent across all sensors and therefore eliminate the error. It would only be if the interrupt routine had not completed before a second sensor was triggered that it would be an issue. i.e the middle of the target. So far, i have not seen this issue in my tests but neither have i set them up in a precision way and have a repeatable mechanism to test it.

I can definitely see your point though, it does make sense to me now to have external components to remove the delay in an interrupt. I'll do some calculations on the processing time it takes to run the interrupt (clock cycles for the commands) and determine the potential error in terms of distance. I'm not 100% sure on how the ESP32/Arduino handles interrupt priority either. i.e if an interrupt happens in the middle of another interrupt, is it dismissed or queued.

Using ASM directly in the interrupt routines would also likely reduce the processing time

I'll let you know how I go.

AussieMakerGeek commented 2 years ago

So, looking at the ASM code for the ISRs, it would take 0.1041 Microseconds to process my current (fat) ISR (25 commands at 240mhz, per microphone). This equates to an error of around 0.0356022 mm in raw distance to the microphone. So unless the shot was in the perfect center of the sensors, the ISRs would not collide, but even if they did, for our purposes, the resulting shot would still be a 10.9. I would say the error within the tolerances of the construction of the project would be a magnitude more than any error from 4 ISRs.

On paper, the interrupts would unlikely cause enough error to be of any substantial consequence.

AussieMakerGeek commented 2 years ago

Hi Allan, Can you help me get my head around the maths in determining the impact point? I've gone over the 'Theory of operation' and 'Sample calculations' as well as the code in the compute_hit files but I can't make sense of it.

Primarily I have been using the 'Theory of operation' document but there seems to be conflicting information.

The Spreadsheet and the code use: =ACOS((D19^2-E19^2-F19^2)/(-2*E19*F19)) s->angle_A = acos( (sq(ae) - sq(be) - sq(s->c))/(-2.0d * be * s->c));

But the example in the document uses: P = arcos( e2 - K2 / (2(s+e)K))

On top of that, in the triangulation diagram it shows the lengths of the sides of the triangle expressed as K, s+ e, e - Would it not be K, s-e,e?

ten-point-nine commented 2 years ago

The theory of operation is simplified and should only be used for guidance.

The code is correct since it uses the rotated sensors

Allan

Sent from my iPhone

On May 4, 2022, at 18:09, Drew @.***> wrote:

 Hi Allan, Can you help me get my head around the maths in determining the impact point? I've gone over the 'Theory of operation' and 'Sample calculations' as well as the code in the compute_hit files but I can't make sense of it.

Primarily I have been using the 'Theory of operation' document but there seems to be conflicting information.

The Spreadsheet and the code use: =ACOS((D19^2-E19^2-F19^2)/(-2E19F19)) s->angle_A = acos( (sq(ae) - sq(be) - sq(s->c))/(-2.0d be s->c));

But the example in the document uses: P = arcos( e2 - K2 / (2(s+e)K))

On top of that, in the triangulation diagram it shows the lengths of the sides of the triangle expressed as K, s+ e, e - Would it not be K, s-e,e?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.

ten-point-nine commented 2 years ago

It’s been three years since I looked at that document so I don’t remember much.

Looking back through the document there are some parts that need to be brought up to date, but the geometry portion is correct in principle.

In Figure 5 e is the thing we are trying to solve for, and is common to all sensors. The time from the pellet to the sensor is the value read from the sensor PLUS the unknown value e. The unknown e is solved iteratively.

On May 4, 2022, at 6:09 PM, Drew @.***> wrote:

Hi Allan, Can you help me get my head around the maths in determining the impact point? I've gone over the 'Theory of operation' and 'Sample calculations' as well as the code in the compute_hit files but I can't make sense of it.

Primarily I have been using the 'Theory of operation' document but there seems to be conflicting information.

The Spreadsheet and the code use: =ACOS((D19^2-E19^2-F19^2)/(-2E19F19)) s->angle_A = acos( (sq(ae) - sq(be) - sq(s->c))/(-2.0d be s->c));

But the example in the document uses: P = arcos( e2 - K2 / (2(s+e)K))

On top of that, in the triangulation diagram it shows the lengths of the sides of the triangle expressed as K, s+ e, e - Would it not be K, s-e,e?

— Reply to this email directly, view it on GitHub https://github.com/ten-point-nine/freETarget/issues/30#issuecomment-1118014191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCD5LKVXMGPF3V2MJFPA53VIL7THANCNFSM5U2V3VLA. You are receiving this because you commented.

ten-point-nine commented 2 years ago

The Github has been revised.

On May 4, 2022, at 6:09 PM, Drew @.***> wrote:

Hi Allan, Can you help me get my head around the maths in determining the impact point? I've gone over the 'Theory of operation' and 'Sample calculations' as well as the code in the compute_hit files but I can't make sense of it.

Primarily I have been using the 'Theory of operation' document but there seems to be conflicting information.

The Spreadsheet and the code use: =ACOS((D19^2-E19^2-F19^2)/(-2E19F19)) s->angle_A = acos( (sq(ae) - sq(be) - sq(s->c))/(-2.0d be s->c));

But the example in the document uses: P = arcos( e2 - K2 / (2(s+e)K))

On top of that, in the triangulation diagram it shows the lengths of the sides of the triangle expressed as K, s+ e, e - Would it not be K, s-e,e?

— Reply to this email directly, view it on GitHub https://github.com/ten-point-nine/freETarget/issues/30#issuecomment-1118014191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCD5LKVXMGPF3V2MJFPA53VIL7THANCNFSM5U2V3VLA. You are receiving this because you commented.

AussieMakerGeek commented 2 years ago

Thanks for that, i'm still a bit confused but at least it makes more sense and I should be able to nut it out.

At the moment, I'm just trying to generate a working test that can reliably sense the location with a decent level of accuracy and give an xy coordinate as a more in depth POC.

From there, I can probably generate some custom functions to swap into the bulk of your code but it's going to be a far from trivial task since a lot of how your code is very specific to your timing method and the Arduino Mega.

I appreciate your help.

pawelros commented 8 months ago

Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

ten-point-nine commented 8 months ago

I’m not sure what you mean?The target is used by members of the Olympic team for practice AllanSent from my iPhoneOn Jan 15, 2024, at 14:08, Pawel Rosinski @.***> wrote: Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

AussieMakerGeek commented 8 months ago

Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

No, I didn't. Not really for any specific reason other than losing interest in the project but I also struggled to get my head around the math involved for calculating the impact point. @ten-point-nine did provide some feedback but it wasn't enough for me to properly comprehend and move forward.

I had a test platform that worked extremely well and reliably to see the timings of the sounds but could not transform this into an x/y coordinate. Unfortunately, in the original code this is not just a simple function that can be exported.

I started looking into linear light based sensors pulled from computer scanners to simplify it, but this also ran into a bit of a dead end because I was unable to get enough technical data on the sensors. They seemed well suited, could support a suitable scanning frequency and are cheap. They worked but I could not get the expected results with lack of datasheets.

ten-point-nine commented 8 months ago

The math is roughly based on a GPS fix.  Guess where you are and keep iterating until successive iterations yield the same answer.  The math is so torcherous that there is no closed form solution AllanSent from my iPhoneOn Jan 16, 2024, at 20:37, Drew @.***> wrote:

Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

No, I didn't. Not really for any specific reason other than losing interest in the project but I also struggled to get my head around the math involved for calculating the impact point. @ten-point-nine did provide some feedback but it wasn't enough for me to properly comprehend and move forward. I had a test platform that worked extremely well and reliably to see the timings of the sounds but could not transform this into an x/y coordinate. Unfortunately, in the original code this is not just a simple function that can be exported. I started looking into linear light based sensors pulled from computer scanners to simplify it, but this also ran into a bit of a dead end because I was unable to get enough technical data on the sensors. They seemed well suited, could support a suitable scanning frequency and are cheap. They worked but I could not get the expected results with lack of datasheets.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

pawelros commented 8 months ago

Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

No, I didn't. Not really for any specific reason other than losing interest in the project but I also struggled to get my head around the math involved for calculating the impact point. @ten-point-nine did provide some feedback but it wasn't enough for me to properly comprehend and move forward.

I had a test platform that worked extremely well and reliably to see the timings of the sounds but could not transform this into an x/y coordinate. Unfortunately, in the original code this is not just a simple function that can be exported.

I started looking into linear light based sensors pulled from computer scanners to simplify it, but this also ran into a bit of a dead end because I was unable to get enough technical data on the sensors. They seemed well suited, could support a suitable scanning frequency and are cheap. They worked but I could not get the expected results with lack of datasheets.

Sounds like you did a decent research. Damn, eliminating moving parts and a need to refill paper would be a killer!

ten-point-nine commented 8 months ago

I tried just using the sound of the pellet passing the sensors but it’s just not loud and consistent enough.  AllanSent from my iPhoneOn Jan 17, 2024, at 03:20, Pawel Rosinski @.***> wrote:

Hey @AussieMakerGeek did you manage to achieve some promising results? I am thinking about building a target without arduino and mobile device instead of a laptop.

No, I didn't. Not really for any specific reason other than losing interest in the project but I also struggled to get my head around the math involved for calculating the impact point. @ten-point-nine did provide some feedback but it wasn't enough for me to properly comprehend and move forward. I had a test platform that worked extremely well and reliably to see the timings of the sounds but could not transform this into an x/y coordinate. Unfortunately, in the original code this is not just a simple function that can be exported. I started looking into linear light based sensors pulled from computer scanners to simplify it, but this also ran into a bit of a dead end because I was unable to get enough technical data on the sensors. They seemed well suited, could support a suitable scanning frequency and are cheap. They worked but I could not get the expected results with lack of datasheets.

Sounds like you did a decent research. Damn, eliminating moving parts and a need to refill paper would be a killer!

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

lboross commented 7 months ago

@AussieMakerGeek I recently came across this project and had the same idea as yourself.

I think I have the math/code figured out, but had issues getting reliable readings using the microphone modules I have.

I can contribute a function that will recursively calculate the X,Y based on time delay between sensors.

https://github.com/lboross/ESP_Target/blob/main/Arduino/ESP_Target/calculate.ino

If you are no longer interested in this project, I would appreciate if you could share how you got the timing working.

ten-point-nine commented 7 months ago

Hello

Version 5 of the hardware to be announced in the next two weeks uses an ESP32 and developed for Visual Studio Code.

Version 5 has a number of new features

The current implementation uses a successive approximation as yours does.

Accuracy, or lack thereof stems from a number of issues:

Allan

On Feb 6, 2024, at 9:59 AM, lboross @.***> wrote:

@AussieMakerGeek https://github.com/AussieMakerGeek I recently came across this project and had the same idea as yourself.

I think I have the math/code figured out, but had issues getting reliable readings using the microphone modules I have.

I can contribute a function that will recursively calculate the X,Y based on time delay between sensors.

https://github.com/lboross/ESP_Target/blob/main/Arduino/ESP_Target/calculate.ino

If you are no longer interested in this project, I would appreciate if you could share how you got the timing working.

— Reply to this email directly, view it on GitHub https://github.com/ten-point-nine/freETarget/issues/30#issuecomment-1930114717, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOCD5LNAID4G7UJ3XZSHVRLYSJHPHAVCNFSM5U2V3VLKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJTGAYTCNBXGE3Q. You are receiving this because you were mentioned.

lboross commented 7 months ago

@ten-point-nine Wow, sounds like an impressive update. Looking forward to the next release!

Do you think this would work well with supersonic ammo? Would it pick up the sonic crack of the projectile rather than the paper?

ten-point-nine commented 7 months ago

It should pick up the shockwave better than paper tearingAllanSent from my iPhoneOn Feb 11, 2024, at 06:23, lboross @.***> wrote: @ten-point-nine Wow, sounds like an impressive update. Looking forward to the next release! Do you think this would work well with supersonic ammo? Would it pick up the sonic crack of the projectile rather than the paper?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>