Added a commit code to have Boron have OpenMV send information.

[BentleySettin]

I added code to the commit list under the project Boron. It's purpose is to have the Boron tell the openMV to send it information when the Boron wants.

[SUPScientist]

Great, I look forward to reviewing the new code. Please use one of the two following options to provide us with more information.

1. Provide a link to the relevant commit. You can do this by clicking from the main repository page where it shows the seven-character commit hash (in this case, d5ba7f5) and copying and pasting the full link to that page here. Here's a screenshot of where to find it.
2. If you want us to drill in even deeper, use the technique Evan demoed on our zoom call and copy and paste the permalink to the specific lines of code that you want us to review.

[SUPScientist]

Since there are only three commits, it's easy for me to identify which one to look at, but once the codebase/repository grows, it will be increasingly difficult.

I'll answer my own question using option #1 from above to show you what I mean. Here is the relevant commit that you are asking us to review: https://github.com/TinyCamML/Boron/commit/d5ba7f5abb21bff19b69c760a9e993073e912bf7. Note that I'm copying and pasting the full https://github........d5ba7f5.........bf7 URL into this issue, but GitHub knows that we are referring to a commit so it renders it as a nice link to commit #d5ba7f5.

[SUPScientist]

As a more direct reply to the initial question, your new code won't compile or work. The code through line 16 is Particle/Wiring code. That is what gets compiled and then flashed onto the Boron. Lines 19–end are written in something intended to be (micro)python. That is what gets compiled and flashed onto the openMV. You cannot have code for two distinct devices in one single file. First, it won't compile (because you're using two totally different languages). Second, even if it did compile, it would only get flashed to the Boron.

Instead, create a single file of code just for the Boron. Edit your current .ino file, recommit, push, etc., and ask for another review as needed.

[SUPScientist]

@ebgoldstein, no need for a code review yet unless you care to take a peek but tagging you here in case you want to follow along, comment on GitHub usage, etc.

[BentleySettin]

Okay! I will look more into the code.

As you can tell I made the commit messier and am struggling how to rename the the descriptive portion of the commit. I renamed it entirely but the second part is lengthy and says "update and rename".

[BentleySettin]

https://github.com/TinyCamML/Boron/commit/2e863923fde9e68879d1c9c458decb0c8631e5cc

I am just practicing giving you the direct commit.

[BentleySettin]

@SUPScientist

I seperated the code and successfully flashed and compiled the information for the Boron. However on the openMV camera I go to "flash" the code and it does not tell me if it has successfully flashed or any form of talking back to me. The only times I have gotten the openMV to "talk back" is when it displays on the monitor what the camera itself is seeing.

While I am trying this I have Boron on a breaboard and the correct wire connections between the Boron and OpenMV.

[ebgoldstein]

When you connect the opnemv to your computer, it just acts like a harddrive. To 'flash' the openmv requires you to just drag and drop you .py code onto the board liek you would put a file on an external drive. I think you then need to rename the code main.py.. (Also drag&drop the *.tflite file too). When you power up the openmv (i.e., from a battery pack, or from plugging it into an outlet), the 'main.py code will start running...

to verify this, you can blink the LED a certain color or a certain pattern in the core loop of the code...

make sense?

[ebgoldstein]

see also: https://docs.openmv.io/openmvcam/tutorial/openmvide_overview.html#tools

[BentleySettin]

Thank you Evan! I will check out this link too.

[BentleySettin]

The code in https://github.com/TinyCamML/Boron/commit/0f5ef2eed6e563b884bf1c361af5c895290d21a5 has been updated. It is in VS code and successfully asks OpenMV for either "Flood" or "No Flood".

Dr. Bresnahan and I chatted yesterday but it seems to recieve data that is a conjumbled mess of mixed of askey. After added delays and serial close and open it has cleaned up to sending just a blank line.

[BentleySettin]

The only code I added to openMV was "uart.write()" for flood and no flood.

[SUPScientist]

It's "ASCII": https://www.w3schools.com/charsets/ref_html_ascii.asp.

Can you confirm that the OpenMV is doing what you think it is? If so, how? Does it serial print (over USB) to computer screen "flood" or "no flood"?

After confirming that, what are you doing to troubleshoot the incorrect ASCII translation on the Boron side?

[BentleySettin]

I cannot confirm that the OpenMV is doing what I am telling it because it is not sending "Flood" or "No flood". However the Boron is printing as if it is recieving data, therefore I am determing if there needs to be a change in Boron or OpenMV code.

This is currently what I am looking at in the serial monitor...

Serial connection closed. Attempting to reconnect... Serial monitor opened successfully: if was true Received data from OpenMV: if was true Received data from OpenMV:

... and so on.

As you saw before, without the added delays in the code after "Recieved data from OpenMV:" there was a mess of characters but now it is just blank.

To troubleshoot I am looking into OpenMV code to make sure I am using the correct code to write across UART and if so what do I need to change in Boron code. Another question is: Could the openMV possibly not be sending any data and therefore the line is blank? But why would the Boron be printing code as if it is? <--- Questions I am asking myself.

[SUPScientist]

This sounds like an appropriate troubleshooting approach.

I understand what you mean that you cannot yet confirm that the OpenMV is sending data as hoped. To restate that question, how could you determine that it is doing what you want? E.g., without worrying about what the Boron is doing, can you prove that you can print "Flood" or "No Flood" to the OpenMV's serial monitor via USB? Is there a uart.print or just the uart.write?

[BentleySettin]

I found the serial monitor option on the bottom of OpenMV. It has been there all along but because I wasn't working in full screen I never saw it.

I am running the camera and I have continually recieved the message:

Traceback (most recent call last): File "main.py", line 3, in Exception: IDE interrupt

I am trying to figure out why this is occurring. Line 3 is https://github.com/TinyCamML/OMVmodel/blob/628c58bbc829f9c162b2ab7f652e225012f65835/FloodCamMLpy.py#L3

[ebgoldstein]

Try breaking that line up into all the separate import commands

import pyb import tf ...

Then rerun and it will identify the line

[BentleySettin]

I did this and now it is saying:

Traceback (most recent call last): File "main.py", line 2, in Exception: IDE interrupt

And line 2 has no information on it. Based on scoping around the internet and openMV docs it is possibly an IDE problem, not code issue. I updated all firmware and IDE.

[ebgoldstein]

hmm.. can you test on a different computer just to rule out an IDE issue?

[SUPScientist]

An IDE issue isn't my first guess. Weren't you successfully flashing code last week, Bentley, as verified by the streaming camera imagery in the IDE window? If you had anything running that you flashed, it's highly unlikely to be an IDE issue.

Can you commit/push your updated code following Evan's recommended edits above so we can take a look at what you're currently using?

[BentleySettin]

I have successfully streamed camera imagery from the IDE window. I can retry it again when I come back in to make sure it is still working and not an IDE issue.

I will commit an updated code.

[SUPScientist]

Confirming that we've seen multiple built-in examples and our own blink_LED.py code run, both via the IDE and via saving as main.py and running while disconnected from PC. IDE does not appear to be the main issue. tf module is also not the issue as running a built-in model is working via example script.

Issue seems to be with tf.load() statement (not finding the .tflite file).

Recommend reading more from getting started guide and tf.load() examples for openmv.

[SUPScientist]

Exciting update (cc @ebgoldstein): .tflite is now loading. Serial monitor shows flood/no flood, so toy code is working as hoped.

For future reference, the problem seemed to be with way .tflite was downloaded from GitHub and/or modified in Windows Explorer prior to dragging into the OpenMV's drive. When we redownloaded .tflite file, dragged it into the OpenMV drive without any renaming/modification, and added the new name ('MNv2Flood_cat (4).tflite') to the main.py file, it operated as expected.

NB: this thread has diverged a bit from the main issue, so not closing, but let's get back to the OpenMV<—>Boron comms now.

[ebgoldstein]

aha!

[ebgoldstein]

if you want to meet at all to discuss anything, i am free RN (until 4:35pm)

[SUPScientist]

I'm bouncing into two back-to-back meetings starting in 5, but @BentleySettin, maybe a good idea if you're planning on being in the lab a bit longer?

[SUPScientist]

Closing as duplicate of https://github.com/TinyCamML/Boron/issues/12, but @ebgoldstein, as our GH teacher, feel free to jump in and suggest a different workflow for any of this if needed, please!