Spent a few hours addressing some odds and ends today. Got the “enter” key working from CLI entry textbox. It now actually runs the command when you hit enter, then clears the entry textbox. I also added a CLI command to display the LCD Address. SHOW-LCDADDRESS is working as expected.
I made the LCD settings variables. (address, total rows, total columns). This was done just as a best practice to facilitate easier use of different LCD’s later.
The functions in the Arduino code were moved around into a more logical sequence. Doesn’t affect code flow, but does affect readability.
So as this project has grown I’ve started to see memory warnings in the IDE. “Low memory available, stability problems may occur.” Didn’t think too much about it until today when I kept running into weird issues where stable code just wouldn’t run correctly. For example, the printNextline() would only print half the output of the line (WTF?) and the parseAndExecuteCommands(). After spending an embarrassingly long time picking through the code looking for the problem I decided to actually the shiny new Mega 2560 I bought the first time I saw the command and put that baby into production.
Learned the Mega is not a straight pin-for-pin match of the Uno. Mega has a SDA/SDC pins (Sweet), and for whatever reason the LCD2004 has a difference address on the Mega than on the Uno. 0x37 and 0x3f respectively. That said, after I got the conversion done it’s running smoothly again.
Still haven’t been able to get into the shop to build out the frame for the the arm yet. However, that doesn’t mean I’ve been idle!
Decided to take the opportunity to start adding the LCD display I wanted. I grabbed a spare display I had lying around and get started. Found some good articles over on Robojax and got it set up.
I have it set up so that ever N’th time the arduino sends a serial line transmission of the current values it updates the LCD. This means the LCD isn’t as current as the serial monitor, but I found the refresh rate of the LCD was too slow to keep up. I plan to add more functionality to fine tune this via the C# app and the CLI, but for this morning just getting it running was good enough for me. I’d like to add “Enable-LcdUpdate”, “Disable-LcdUpdate”, and “Set-LcdInterval” commands. Possibly an option to choose what is displayed as well (servo’s vs sensors or something like that).
I’ve been too busy lately to really commit the time to go build out a proper frame for the light probe. Instead I’ve build a bunch of half-assed mock ups which all generally suck and failed to work. I guess the moral of the story is that there is no shortcut here and I need to just go build the thing.
That said, I’ve decided to add a dedicated CLI tab to the application so I
don’t have to keep switching back to the Arduino IDE’s serial monitor. The next step is getting it wired up. This will require me to learn some new techniques as I don’t really know how to write a buffer type variable, or even if one exists that I could just make use of. While contemplating this I again found myself looking for a quicker easier way to do it, and again half-assed some things that didn’t work and were rolled back. Again proving to me that there are no shortcuts. I think I might include that on the site motto going forward…
I’m travelling today so this will be a shorter update.
Finally got the calibration working so I can manually offset the photoresistor readings and servo positions. This was necessary because the components naturally have slight variations in their readings, etc. I will be creating semi-automated calibration sequence, but that will need the LCD screen up and running first. I also tweaked the CLI functionality a bit to more easily integrate with the C# app. Still outstanding is polishing it up so it can be used the a terminal emulator like Putty.
Next items on the agenda include:
Getting rid of the semi-colons from commands
Re-aligning the sensors from corners to sides (i.e. left and right instead of upper-left, upper right, etc.
enabling manual override of the automatic controls
Tying that to a Wii-Chuck (down the line a bit…)
LCD Status Screen
Bluetooth control module, to allow operation remotely, and without a PC/phone.
Having a blast building this thing, even if there is some serious scope creep happening. 😉
So I took some time this weekend to add a CLI to the Arduino. It follows the verb-noun syntax familiar to Powershell users (because I am one, and I love that syntax…) It still interfaces with the C# GUI of course, but now I can interact with it from the Arduino IDE’s serial monitor as well. Ultimately I will enable Putty interaction with it. I also did some refactoring to streamline the code a bit as I’m now up to over 70% of the Arduino’s available memory… May need to upgrade the Uno to a Mega. Fortunately I’ll be near a Micro Center in the near future. (W00t!)
Also got the servo’s governed down to between -45° and 45°. This was simple enough, but I did get hung up on an idiot loop because the damn values kept going out of the range and getting hung. Took some thinking to get that to stop. Derp.
As always, the code has been updated on the Github Page.
I also have the Latest Build available for download as well, though not much has changed.
I did some extensive re-working of things over the last few days, which is to be expected on something this early into development. I’m kind of forming what I want this to be as I go, which is considered terrible development practice but eh, fuck it. Also uploaded the latest build if anyone would like to download and take it for a spin. Here’s the link: Light Probe (Zipped Exe)
So I tweaked the UI quite a bit. Removed some extraneous junk, added things I will actually use. The sensor progress bars now have numerical value boxes as well. I added some (not yet functional) buttons for things like semi-automatic calibration, loading and saving of calibration config files, rescanning for COM ports, and manual override of servo control.
Going forward I’m going to be working on finishing the fully automated operation of the unit, and then starting to tackle the manual operation and calibration. I feel the calibration will be vitally important now that I’ve been playing with the hardware for a few weeks. It’s fairly obvious that the sensors and servo’s are NOT all created equal, as I can now predict which sensors will read higher or lower given identical readings, and which servo will go further one way or another given identical commands.
This has lead me to consider how I would even calibrate everything. For the sensors, I’m thinking I will need two things: a light source to act as a control. I’m thinking very bright LED with a rubber seal around it to isolate the sensor from ambient light. Turn the LED off, take a measurement, the value read then becomes zero. Turn the LED on, take a measurement, the value read then becomes 100. I might just build out a mock-up modal window for this purpose later today if I get some free time… Should be quick and easy.
For servo calibration there are really three things to consider. The actual values of 0 degrees, 90 degrees, and 180 degrees. (or -90, 0, and 90 as I prefer to refer to them as.) I’ve noticed that when I tell the servos to go to these positions, they are invariable off a few degrees. While this shouldn’t technically matter for fully automatic operation, it just bugs me because I’m obsessive. If the servo is facing 90 degrees, IT SHOULD SAY 90 DEGREES DAMMIT. So to tune them I’m looking at the following process: Tell servo to go to -90. Use tuning buttons to adjust it until it’s actually at -90. Press some sort of “commit” button, and rinse, lather, repeat for 0 and 90. Once the calibration is done, what is sent to the servo’s is what they will actually do.
Once I have the calibration routines set for everything, it would be nice to not have to do this each time I boot the damn thing. So this logically leads to something like a configuration file. This then runs into an instant problem. This device is supposed to be able to run independently of the C# program. So the config file needs to be stored locally. This will probably be as easy as throwing an SD-Card shield on the Arduino and storing it there. I will probably make some sort of serial load/save functions for this file to avoid having to pull the SD-Card to tweak it. Would also be nice to just be able to save the files to the PC over the serial line.
I’ve got some grand plans for my little toy. Now all I need is about a month with nothing to do to flesh it all out and actually build the boom, mounts, etc.
Spent a good chunk of this weekend tinkering. Got the Arduino IDE for Visual Studio plugin up and running. (and mostly functional), though I still can’t get it to actually upload to the Arduino. Still, it beats running one IDE for Arduino and another for C#! Plus I wrapped the Arduino Code, Fritzing file, and C# code all into one Solution and got it on Github. The servos are mostly reacting as expected finally. Still some tuning required, but we’re making progress. Some highlights from this weekend include:
Servo’s move different amounts based on how much variance there is between the sensors. Bigger difference between sensors, bigger movement. Then as the sensors get closer together the distance moved each time decreases. Eventually, I’ll map this to a parabolic function or something similar, but for now it’s all about KISS. I’ll eventually probably also eventually adjust the delay in a similar fashion to allow the servo to complete it’s moves before the next cycle.
Cleaning up! While it’s not sexy and doesn’t really bring any new functionality, I did some (desperately needed) housekeeping on the Arduino code. Just the basics… combining redundant code into functions, commenting things, etc.
Consolidating into a real version control system! I had to learn how to use Github at some point. May as well be now…
Goals for this week:
Build the prototyle hardware. Probably going to mock it up in cardboard before I hit the shop for real.
Get manual calibration of the sensors working
Get manual calibration of the servo limits working
That’s all for tonight. You can check out the code and schematics at the Github page.
I’ve decided to finally build the self-tuning Wi-Fi antenna I’ve been dreaming about for a few years now. I figured it would make sense to start with something a tad easier, but with transferable skills and code. Hence I’m building an arm that orients itself toward light. It will accomplish this with 4 photoresistors and some math. (I may eventually trim it back to 3 photoresistors). They’re broken down into Upper Left, Upper Right, Lower Left, and Lower Right. Basically the code flow goes like this:
Read all the sensors
If the left and right sensors are reading equal strength make no lateral adjustments, otherwise move toward the stronger signal.
Same concept for vertical sensors.
Rinse lather repeat until everything is reading the same values and you are (hopefully) oriented towards the light source.
To go with this hardware, I’m writing a UI in WPF/XAML (because I know it, don’t judge me!) It’s fun, and quick to set up. So far it’s giving me live readouts of the sensor values. This is accomplished using a simple set of fixed length values passed via Serial. I’m currently primarily using USB cable, but I do have a bluetooth module ready to go once I get things polished up a bit.
For now the code is UGLY!!!! I know this. Don’t care. Will refactor is later as I get things working. For now it’s all about getting things to actually function.