Tried to emulate Arduino's 11 folders... I'd perfer to have all the
shield scripts in one folder... but, that might not make sense. I don't
really want one script per folder however. So, I might merge some more
stuff in the future. I have a grand idea here that will become evident as
I work though the examples.
Anyway, the current structure is not final. It will be in flux for a
little while.
As for Git History, folder history is the best we're going to get. Git
and GitHub don't seem to deal with moves too well.
So I'm just adding a function to do it cleanly and efficently. Call
skip_frames() after changing any camera settings to let it settle.
10 frames by default works fine. Tested it.
Has a bias value that allows you to control if its really a midpoint,
min, max filter, or something inbetween. Run at 160x120 or lower. 320x240
is slow (seems to be the case for all convoltions at that res).
Added setters for these camera settings. AWB is necessary for color
tracking to work correctly. AGC still runs, which causes lighting
shifts. It may need to be disabled too. Not sure... if I want to do that
or not however, because without it lightning won't get normalized to
remain at a certain level. So, turning AGC off may cause issues in other
ways.
First, a few things:
The MLX 16x4 sensor has just too low of a resolution for mass appeal for
the price. The product is not going to sell very well. We need to look
into supporting sensors with a better res. Like the FLIR 1. The MLX
module was renamed to the "flir" module with this idea in mind.
The flir code now takes care of doing scaling and blending itself. I did
this to get rid of the user having to scale the image themselves and
blend themselves. Its too easy to run out of memory given our current
ultra small heap. In general, anything that requires multiple images in
RAM has got to go. When we do another OpenMV Cam with external RAM in
the MB range then maybe such functions will be safe. But, right now they
are definately not.
Anyway, moving on, I fixed a few bugs with the MLX math code. But, for
the most part was correct. I also added reconmended polling code for
brownouts as required by the datasheet.
Last, I designed this code like the LCD code to support a type value
when inited. This will allow the system to user a different sensor in the
future without any API changes to the user.
I will add test scripts for this next. Basic usage follows:
import flir
flir.init()
flir.display_ir(sensor.snapshot())
And that's it. Super easy. If the user wants the raw temp values they
can use flir.read_ir() to get the ta and to values. The display function
has a hidden alpha and scale argument for controling blending and the
min/max scaling.
The previous way we worked out scaling kinda sucked... it was a good
shot, but, controllable min and maxes that autoscale by default just
work better. If the user knows the temp range then they can just set the
min and max.'
Anyway, longest commit ever done.
This a python module driver for the BLE module. It puts the module into
a mode that's good for machine interfacing and handles parsing commands
for you. Additionally, it lets you get access to the low level serial
port.
Users who want to use this driver will need to read and understand the
TruConnect API for what commands they can execute. This driver simply
makes executing commands easy. The user simply needs to call the
"command()" function with the strings listed on the TruConnect API and
they will get the response from the command back as a byte object.
Once the user has executed the nessary commands to setup the BLE
connection they can then do:
ble.command("str")
To put the BLE module into streaming mode and then they can just
directly access the serial port via:
ble.uart().write(<data>)
And etc.