*Update 5/22*
-Hitch with MRAA and I2C explained
-I2C Screen Writing Details
-Updated wiring list, removed old to reduce size (due to no spoiler/see more function).
-Added photo of console not uploaded here before, when it was created, under last date's update.
*Bonus: House Purchased, so work on building the pilot cabin started!
I may upload a pic or 2 of how much space I have now for mech storage. XD
__________________________________________
Introduction:
Initially, this was to be a mascot project of an animal mech, from a game I'm developing based on Zoids, but I've been unable to get/have fabricated knee-joints that can sustain 400lbs; so with permission, I've changed it to another type of mech. I've played many hack-and-slash games through the years, but my favorite one that's NOT an RPG is probably Warriors Orochi 3. Actually, I'm actually hoping this project may give enough light back to the series to make a 4th installment, including characters from Hyrule Warriors and Band of the Hawk. But I digress.... the project for this Intel project is.... the Juggernaut (also known as the "Tiger Tank").
This is a log of updates and information for the building of the Juggernaught from this game series, created by YueYing (who I also plan to cosplay with the debut at a convention).
This post will be formatted with the most recent update description up top with details within this post; I will comment as well that the post has been updated, to alert anyone who would want an update, so they can follow the post. as well
I selected the Edison for a basis for this (and my other goal) mech, because I required Linux to use some features I intended, with Arduino lacking raw processing capabilities. Also, while the PicAxe seems to have better I2C communication features, it lacks the number of analog input ports compared to the Arduino. However, it was impractical (not to mention unsafe) for the Arduino to send all sensor data in an array, just to be interpreted by the Raspberry Pi I was using. Then I saw the Edison has 6 analog inputs, I2C if I needed it, and 20 GPIOs (4 having PWM). Seemed close to a mix of the RPi and the Arduino Uno I needed... Best part yet? Can read it without waiting to send/receive!
Enter the #intel_project
Hardware Plans:
-Differential Steering, controlled either by PWM, or a DPDT relay.
-12v batteries, possible multiple in parallel for longer runtimes.
-Power to hardware controller will require multiple-position register-style key, different positions for different permissions.
-Special Entry Method, using electric magnets
-Creating fire illusion with fog machine and lights.
If you're in a position you can donate any related hardware to help, I am currently in the need of 12v motors and batteries, SHARP sensor connectors, and any method for drive-train.
PROGRESS:
If anyone knows how to put dates in "spoiler" boxes or the like, please tell me where to find them!
5/22/17 - CONTROLLING THE CONTROLLER
While I planned to upload photos for the last update, I never got to update them, because my phone screen got broke during the move, and it was more worth it to buy a replacement than cut myself (more) on trying to get the broken screen out. As such, I'm taking new pictures as I'm writing this (and mentally putting together what I've worked on in text).
I actually used the Edison to give a Panel/Q&A for a local Pop Culture Convention. My panel was on "Mechs, Props, and in Between". I basically taught about how to use boards, sensors, and motors for cosplay and props, with a "safety first" approach. Speaking of "safety first", I wanted to address the care taken in the development and design of this board.... a couple of times, I've had shorts happen from from the 5v to a GPIO from things getting bumped. The board would just restart. Note, this is a good safety precaution, I DO NOT recommend using it for a reset button! XD
I haven't wired ALL of the directional sensors yet, only needing two to ensure the programming allows multiple to be run at once. As I'm programming in Python, it requires the multi-threading module, and programming with it can be odd or unpredictable, at least to some degree.
-Coding the sensors:
I am trying to run a thread per sensor, to turn on an LED (connected to the GPIOs) on/off using MRAA. However, because of limited GPIOs, I'm working one using "trigger" on all sensors, then trying to read them all at once. It seems to sometimes return duplicates, but that was also before I found a bug in my code with multi-threading. Each sensor has an echo (input) and trigger (output) pin, that you have to use a script to detect distance based on the time the trigger was sent, to the time that frequency coming back to that sensor.
I'm considering to look back into SHARP sensors, if I can find any to read more than 1.5ft away. I do have a sensitivity knob connected to it, to change the setting based on ambient light.
The sensitivity knob is where I've run into my latest hitch in programming: I'm using an SSD1306 I2C screen. If you want to know more about programming for it, I made a post asking for help (and answering it a day later) here: Live Update of OLED module in Python
My current problem, and I do have a post for it, so I will link it as well when I get an answer, is:
Once I try to read the rheostat input I'm trying to read in MRAA (again, using Python), the screen refresh stops working. If I call the analog input first, the screen will never even turn on.
I plan to double-check my threads later, but I didn't see a problem there last few times I checked.
-Wiring:
I'm wiring the panel, with screen, LEDs, to all connect at the back to a screw terminal, to connect to the Arduino and external sources from that point. This allows me to interchange one part at a time later, as I make sturdier parts, or want to change something. It also allows for easier prototyping, where I can jump one screw to another to another to test if something is not powered or grounded properly, or is malfunctioning from software, instead.
For example, I had a LED stop working even though the sensor was connected and script was running to make the light blink when the sensor is covered. The light did not light up. I used a jumper to run power to the LED terminal (3rd from right), and it did not turn on. All LEDs share a common ground with my setup, so I jumped a voltage to #3 (from the left), and ground to the black... it turned on. I use a miniature breadboard inside the control panel, which allows me to manually control or bypass sensors or controls if there's a malfunction.... because as I said at the convention several times, SAFETY FIRST!
Okay, so I'm kinda pleased with my organization and soldering here, lol.
And yes, that's a chip bag, I'm using for a reflector behind the LEDs. I'm using acrylic pieces off a Samus Helmet I was making buy got damaged. I just broke it off, and glued the pieces onto here, for protection to the LEDs.
I went through the breadboard, tested leads, and YUP! A bad ground. Fixed it, and jumped it again....
So, of course it worked again after I restarted the script! ^_^
Yet, I'm still having trouble on the MRAA not reading analog unless it stops sending commands to the screen.....
-My current Pin usage:
-Analog Input:
5: Rheostat(knobs) to return signal controlling sensors' deadzones, programmed to vary by position, to avoid false positives.
-Digital IO:
2: Trigger (kicks out sound)
3-6: Echo (reads return on sensor)
10-13: Controls LED indicators
SCL/SDA: I2C Screen Module
TX/RX is currently reserved for the bluetooth serial module I consider installing, since my phone will not pair with the Edison.
Other Wiring:
-Wiring an additional rheostat to control brightness of console lights, with likely another to control internal soft lighting, once internal compartment is built.
-All wiring from the control panel runs to screw terminals at the back. This allows the console to easily disconnect to maintenance it, jump a function in case of malfunction, and allows for easier replacement of console in case of damage. Wires run from this to where the Edison is centralized.
4/14/17 - CREATING THE CONTROLLER
While I had an update 2 weeks ago, I condensed it since it fits in with the previous and following.
Also, I know people usually want photos to look at, but all got 1 or 2 got lost when my old phone was destroyed.
Yes, a box. Half made from a box for Ramen, half of it being the platform that those ranch beans come wrapped on.
I figured this would be the easiest and cheapest way to prototype.
The motion controls, I plan to control with an actual 3-axis joystick with Hat. Throttle will act for PWM/Speed control. If I make the head movable, I will use the Hat Switch for that.
I spent a good few days (trying on) setting up Bluetooth.... or rather, trying to. When I never got an answer here about the issue, I took it to the Intel forums (here). While I got someone trying to help, his remedies were useful, but for a problem different than I had. There is a very useful script (linked on that page) that helps people with passcode issues when pairing. My issue is that my phone nor the Edison would ever see the other existed. This is what I planned to use for a directional indicator, by sending info from the Edison to the phone via serial; so I had to make a replacement.
______________________
I am using blinding LED indicators to indicate if a sensor is detecting an object nearby. I'm currently working with sonic sensors, but may be switching those back to SHARPs: while the sonar gives better distance reading, they are supposed to take 2 Digital IO pins per sensor (8 pins total). While I have gotten that down to 5 by sharing the "Trig" pin command for all sensors to trigger at once, it is still causing a shortage of available Digital I/Os, and the threading (using python) is not working how I'd like it to (as I'm still a novice).
It currently leaves me asking:
"Do I want to simplify and use my only 4 remaining analog inputs?" or "Do I want to make this code work, but leave myself only 3 Digital IOs - 2 which I plan to use for motor control".
In the meantime, in 1-2 weeks, I'll likely be moved and have my new computer, as well as more room to develop this project to be able to take better photos (poor lighting currently).
2/28/17 - UNPACKING
Unpacking it.... The packaging made me feel a bit like when I opened a tin of Pokemon or YuGiOh cards when I used to buy them. No, it doesn't come in a tin, BUT they have the Edison board, packed all pretty on it's own up top, like a holographic card at the top of a box. It felt like Spongebob's "Magic" meme here to me. I'm sorry, I'm not sorry. XD
Anyhow, back to reality, it was very easy to assemble.Please, in case it's not obvious, do NOT open that package of screws over a drain or even carpet: some are VERY tiny. The installation for the configuration tool takes a good while. In fact, as I was typing, I was typing when it finally popped back up.... It messed up the installation of some drivers, so I had to redo the process, as it showed some things not installed properly ("MERRIFIELD" and "X USB Download Gadget" for me).
SSH may be a good idea for many of you, but know any service you have running usually does take more power from your device, and part of the device's resources are going to be used to run it... if you don't need SSH, I'd say leave it alone unless you need it. As it just finished updating the firmware, I learned it did not store previous settings. In other words, update the firmware, if you plan to, before anything else.
An important note on setting up SSH, some tutorials say you have to use USB SSH (what the config tool sets up) to set SSH to be allowed through Wi-Fi. It worked right away for me. If you connect it to Wi-Fi to SSH, username is root, password is whatever you set it to when enabling SSH. Through sorting through that information for setting up the SSH and getting it working, at 5AM I called it a night.
Top Comments