This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Rongyos
1
« on: September 16, 2024, 03:09:03 AM »
I think I might see another problem where the reload delay is not being taken into account properly, but let's test this change first, and if that solves your problem, I will update the code and issue a release with this fix and a fix for the reload delay.
Hey Luke, Sorry for the long delay, I was working on a new board layout where users can easily connect single relay to activate the taigen / henglong airsoft/recoil microswitch which activates the cannon sound and the irritating gearbox recoil. Also, i want to make a 3d printed case for the relays to store them stacked to save some space. Attached you can see a sample how it looks when two relay modules having an affair  (sorry for the cable spaghetti) Regards Rongyos
2
« on: September 03, 2024, 04:54:38 AM »
Hi Rongyos, I'm not sure I know which "Back to Default" signal you are referring to - is this in the Standalone IR code? Where is the code waiting for anything to go back to HIGH?
Are you using the negative signal from the Taigen connected to Pin D4 on the Arduino as the trigger to fire the cannon?
Hey Luke! Sorry for not able to provide clear details. Finally I am near my computer so I can provide more details. As the taigen mechanical recoil works: it gets negativ signal from the airsoft pin from taigen for a short period (you only have to push the transmitter joy up for a short time). The rotary gear releases a microswitch then in the recoil unit which connect the ground from the battery. The cycle is around 3 seconds, and the microswitch being pushed and disconnects the ground pole from the battery. (single banana plug from taigen). The standalone unit gets the shot signal from the airsoft pin (yellow wire) BUT the wire connected to the recoil motor - where the battery ground also connected until the microswitch close the line. (3 sec). So for 3 sec the battle unit receives LOW (because the D4 pin is INPUT_PULLUP in my case). I checked the code again the loop is waiting for InputButton.wasReleased() then activates the FireCannon function. (I called it BACK TO DEFAULT before, i remembered the thing but not the name) BUT there is an other function you commented on it: case BUTTON_WAIT:
if (InputButton.wasReleased())
{ // A single press (short) of the button will fire the cannon
FireCannon();
}
else if (InputButton.pressedFor(2000))
{
// User has held down the input button for two seconds (long press)
// Wait for them to release the button before proceeding
do { delay(10); InputButton.read(); } while (!InputButton.wasReleased());
ButtonState = BUTTON_WAIT;
// Now you could take some other action here to occur on long button press
// bla blaSo I think the board wants to go to the special menu which is not set and sometimes fails itself. What do you think, is it better to modify the loop to wait for InputButton.isPressed or .wasPressed to solve the problem and force the unit to activate FireCannon function as soon as it receives the LOW signal? /*----------------------------------------------------------------------*
* isPressed() and isReleased() check the button state when it was last *
* read, and return false (0) or true (!=0) accordingly. *
* These functions do not cause the button to be read. *
*----------------------------------------------------------------------*/
uint8_t OP_Button::isPressed(void)
{
return _state == 0 ? 0 : 1;
}
uint8_t OP_Button::isReleased(void)
{
return _state == 0 ? 1 : 0;
}
/*----------------------------------------------------------------------*
* wasPressed() and wasReleased() check the button state to see if it *
* changed between the last two reads and return false (0) or *
* true (!=0) accordingly. *
* These functions do not cause the button to be read. *
*----------------------------------------------------------------------*/
uint8_t OP_Button::wasPressed(void)
{
return _state && _changed;
}
uint8_t OP_Button::wasReleased(void)
{
return !_state && _changed;
}Thanks Rongyos
3
« on: September 02, 2024, 12:11:51 PM »
Hi Luke!
I hope everythings well, long time no see. There is some battle unit around now, working like charm with servo recoil...but... In case of taigen recoil the fire cannon function activated after the whole recoil effects is done (when gun barrel go back to default). I assume thats because of the firing cannon function is looking for the "BACK TO DEFAULT" signal, and - how the taigen works - the board recevies negative signal until the microswitch disconnects the negative pole from battery. Question: why is it important to wait until the pin signal go back to HIGH? Sometimes the battle unit fails and restarts because of this. Is it for safety? How can I solve this problem?
Thanks
Rongyos
4
« on: May 27, 2024, 03:34:21 AM »
I wrote a short description but if I have said anything incorrect or if you would like to modify it, just let me know!
Hi Luke, I’ve corrected some values in the BOM. Please reupload the file for clarity. Also, there is a misspelling in the name of the STL file in your post (cse should be case). regards Rongyos
5
« on: May 23, 2024, 08:20:25 AM »
Hi Rongyos, I will be happy to share the project. We can create an entry for it on the Downloads page the same way we have with other user designs. In addition to your Arduino code, if you have a schematic, board files (Eagle or Gerber or whatever), and list of parts (what we call a "BOM" for "bill of materials") we can post all that as well.
Even only understanding the subtitles, your video was very clear to me!
Hey Luke, I hope its okay to attach the file to this post. Regards Rongyos
6
« on: May 19, 2024, 09:59:28 AM »
I'm glad you figured it out, and thanks for letting us know. After a very long time it sounds like you have a fully working product, congrats!
Thanks for your kind words. I made a short video (with English subtitle) how it operates, I hope it is understandable. In the next week I try to clean the code and it can be shared if you help me how to do it  Regards Rongyos
7
« on: May 16, 2024, 01:57:29 PM »
Hi Luke! Can you help me please?
The new design board finally arrived (the first shipment lost) and I put it together. Every function works like charm except the servo 
I assume it is a power issue but you please take a look on the schematic? The Taigen MFU provides 7.1 - 7.2 volts constant and I drive the relay, IR receiver and servo with a LM7805 IC (datasheet here). 1uf capacitor on the IN and 0.1uf on the OUT.
The servo makes very low buzzing noise but the full stuff (arduino) stops when I plug in the servo. If servo is not attached, then everything works fine.
Thank you for your kind helpA solved the problem, unfortunatelly I just realized that the CN2 connector of Taigen MFU cannot provide sufficient current for the servos. I connected the power line to the battery (after a switch) and removed the R4 resistor so now the arduino receives LOW value during firing airsoft. Now everything works Rongyos
8
« on: January 26, 2024, 01:14:03 PM »
Very good! I suppose that does not solve the initial firing of the cannon when the Taigen MFU first powers up.
Yes, it solved the phantom firing. Also I tried the airsoft-microswitch connect to try before, but somehow thats not worked. I had to wait for the big bunch of resistors I purchased. Rongyos
9
« on: January 25, 2024, 05:38:57 AM »
Only some testing can answer these questions.
Hi Luke! I can say that testing went good. In my case R1 = 2.4K; R2 = 10k. Now it has 1,3V at resting state and 5,28 when activated at charged 2cells liion. I think this is now good to go Thanks Rongyos
10
« on: January 10, 2024, 03:01:20 PM »
Hi Luke! I didn't check the obvious You are correct, if digitalRead returns 1 that means HIGH. I'm certain the Taigen MFU keeps this pin HIGH except when the airsoft is fired, at which point it is held to Ground, but that doesn't mean there couldn't be some "noise" or a very brief signal on this pin when the Taigen starts - not long enough to activate an airsoft unit, but long enough for the Arduino to detect it and fire the cannon.
So every time at least 1.9V is there in this pin. BUT! When I checked this pin switched off (fortunately my switch is disconnecting the + wire) connecting multimeter to battery + and airsoft pin it was around 7V visible (not much less then the battery actual voltage *DOUBLECHECKED it was 6,64 - 6,62Volts). When switching on the MFU its dropped from 7V to 1.99V and stayed there until I (I mean, my dear wife who helped me) fired the tank and it was 7.04V again (which is the actual battery voltage) Now that I am thinking about it, it is also likely the voltage of this pin from the MFU, when the airsoft is not active, is greater than 5 volts. Of course the Nano can be damaged with input voltages higher than 5 volts, so this could also be a source of problems. You should try to measure this pin from the Taigen MFU with a voltmeter. If it is greater than 5 volts, there are ways to protect the Arduino, but we need to know what the voltage is. I attached a schematic. Please ignore the voltage regulator and any other stuff connected to it because it is my "future" board. I dont have the current one because I overwrote it Please see the blue ugly stuff, the 5V is supplied by taigen receiver connector (yes it has opportunity to connect aftermarket receivers and therefore TX-es to is. This connector provides 5,02V so I using it) Unfortunatelly no other pin which provides 5V continuously. According to the schematic the IR connector is 5V but jI didnt get 5 volt from this pin, only 4.3 at max. Servo was not working with this. It would also be good to check some other outputs on the Taigen, there are two more options I can think of: the flash trigger, and the IR port. I don't have a Taigen to test and my memory is not perfect, but I believe the flash pins were 5 volts. If so, that would be a better choice to connect to the Arduino. No, those are not activated until receiving a signal from a microswitch (it is located in the airsoft or recoil unit and pushed mechanically by those units). The initial triggering signal is from the airsoft, anyway Or.... maybe that should be solution if I connect the airsoft signal to the microswitch pin and then, the MFU triggers the gun fire function then sends out the 5V to IR. If so, I have to redesign my board again, and order it from pcb manufacturer :'(
11
« on: January 10, 2024, 10:11:55 AM »
Hi Rongyos,
At this point there are so many different symptoms which don't seem to have any relation to each other, that it is hard to say what is going on.
If the board board is reseting/freezing/locking, or just in general acting bizarre (not completing the serial statements, erratic servo behavior, etc...) something is not right, but yet I experience none of these on my end. So there are two possible explanations:
1. Possibly we are still struggling with a compiler issue. I kind of doubt it, but if you want to replicate my setup I am using Arduino IDE version 1.8.13 with the AVR Boards set to 1.6.20. We already discussed changing the boards to 1.6.20, but maybe there is a difference with the compiler itself. You could try downloading and installing 1.8.13 from this link, and again make sure the AVR Boards is set to 1.6.20, and see if that improves anything.
2. The second option, is that you are using modifications to the code that are causing problems, or there are electrical issue with your custom board. Those are things only you can troubleshoot, but through a process of elimination it is still possible to reduce the number of possibilities until you find the culprit.
[...]
In summary, the only way to solve any technical problem of this kind is to simplify everything down the absolute minimum until you arrive at a state where things work as they should. Only then can you begin to make changes, one at a time, testing at each step, until a problem occurs. Then you know what the problem is.
Hi Luke, I did some experiment with / without my motherboard; with your hex and with my hex also. I realized that when I tought the arduino was freezed there were 2 option: 1. It wasn't, but I was 1d10t and did not set the relay pin default as "HIGH". So when I switch on the arduino the relay was always on (led is on) until I shot the cannon. Now, I made a simple digitalwrite HIGH command in the void setup and now, everything is working right 2. there WAS a freeze. But it is a hardware issue. I think during the experiments I burnt out the IR emitter transistor or IDK, but when I try firing now, it fires 1 or 2 and the arduino is freezing. When I remove the IR LED (only the led) there is no issue anymore. Strange, there wasn't this issue before I could make a lot of cannon fire with this PCB. I have good news (?). The whole phantom firing is caused by the Taigen MFU. Finally I found an 5v BEC, krimped some connector and with this stable power supply (I mean the Taigen probably also stable but not the airsoft pin which I use for activate button firing) there is no phantom firing, only the servo positions itself to its home pos. SO the code was good regarding this (your and mine too). With my board, with relay, with my mods in code etc.... But, when I connect it to the MFU and power it on (via the MFU PSupply) it does a phantom firing. I tried to disconnect the airsoft wire and power it on by the MFU and it was fine, worked correctly without phantom firing (I should probably make a hotkey in windows to write "phantom firing" ). I assume the Taigen "switch on" this pin later. Or (worst case scenario) it is always on LOW? (When I put digitalRead its always said it is 1 (high, right?) Can you guide me out of this mess?
12
« on: January 09, 2024, 01:47:23 AM »
The GitHub is now updated with all these changes. I hope now everything will work, please let me know your results.
Hi Luke! Thank you again for you quick support. Unfortunatelly those mods are not working. The notify led is acting strange, when I shot the cannon some time (usually 4-5 times) the arduino reset itself and stay in a strange state ("L" board led is on, relay is on). You can see the pic what I mean. When I plug in the USB to see on the serial monitor what happens, this issue is not appearing (can it be a power supply issue? If yes, why servo, recoil and hit notification working?) MOD: well, in the pic the notification led is not on (3mm red one). But most of the time it freezed at staying on When I only tried the 5V trigger mod of yours there wasn't any different operation then before. Phantom firing is still there. BUT I realized 2 things, maybe connected. 1. when I power on the arduino, there is ~20degree turn in the servo, like it start firing then stops. But, it does a firecannon function and everything works fine after that. 08:17:47.916 -> ---------------------------------------------
08:17:47.916 -> BATTLE INFO
08:17:47.916 -> ---------------------------------------------
08:17:47.916 -> Is Repair Tank? No
08:17:47.916 -> Fire Protocol: Tamiya
08:17:47.916 -> Hit Protocol 2: Heng Long
08:17:47.916 -> Repaired by: Clark Repair
08:17:47.916 -> Send MG IR Code: No
08:17:47.916 -> Accept MG Damage: No
08:17:47.916 -> Damage Profile: Tamiya Spec
08:17:47.916 -> Weight Class: Medium
08:17:47.916 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
08:17:47.916 ->
08:17:47.916 ->
08:17:47.916 ->
2. when the arduino is on and I push the reset button, the "setup" is incomplete (or cannot do the loop, IDK what happens) and relay stays in and you can see the servo do the same thing which I wrote in the point 1. I attached a video, it is showing what happens. I dont know, but maybe the in the Tank.ino there is code part which is waiting for the initial cannon fire to go to the main loop.
13
« on: January 07, 2024, 11:37:52 AM »
Ok, I understand now. You're right, these Chinese MFUs often prefer to toggle the ground signal rather than the positive, so you were correct to use the button input D4 (which triggers when held to ground) rather than the 5 volt input A0 (which triggers when brought to 5 volts). Your friend correctly identified the problem with the 5v input which was left floating, and disabled it by setting it to OUTPUT. That works fine. For others reading this, you can do the same, or as mentioned before, add a resistor between A0 and ground if you don't want to change the code.
Hi Luke! My happiness was not long. Unfortuntely, the phantom firing is not visible on the serial monitor, but still there. I have another idea with this, can you please put a code which activates the IR emitter pin a little bit later? I mean, the ir pin activated or start to wait the cannon function after 2 secs from bootup. I put a button state in every initial bootup but its value 1 every time. IDK why this dump the battle info 3 times after uploading the code ... :/ 18:27:40.756 -> Button State: 1
18:27:41.021 ->
18:27:41.021 -> ---------------------------------------------
18:27:41.021 -> BATTLE INFO
18:27:41.021 -> ---------------------------------------------
18:27:41.021 -> Is Repair Tank? No
18:27:41.021 -> Fire Protocol: Tamiya
18:27:41.021 -> Hit Protocol 2: Heng Long
18:27:41.021 -> Repaired by: Clark Repair
18:27:41.021 -> Send MG IR Code: No
18:27:41.021 -> Accept MG Damage: No
18:27:41.021 -> Damage Profile: Tamiya Spec
18:27:41.021 -> Weight Class: Medium
18:27:41.021 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
18:27:41.064 ->
18:27:41.064 ->
18:27:41.064 ->
18:27:51.406 -> Button State: 1
18:27:51.671 ->
18:27:51.671 -> ---------------------------------------------
18:27:51.671 -> BATTLE INFO
18:27:51.671 -> ---------------------------------------------
18:27:51.671 -> Is Repair Tank? No
18:27:51.671 -> Fire Protocol: Tamiya
18:27:51.671 -> Hit Protocol 2: Heng Long
18:27:51.671 -> Repaired by: Clark Repair
18:27:51.714 -> Send MG IR Code: No
18:27:51.714 -> Accept MG Damage: No
18:27:51.714 -> Damage Profile: Tamiya Spec
18:27:51.714 -> Weight Class: Medium
18:27:51.714 -> (6 cannon hits, 5.0 sec reload, 20.0 sec recovery)
18:27:51.714 ->
18:27:51.714 ->
18:27:51.714 ->
18:28:27.490 -> Button State: 1
18:28:27.753 ->
18:28:27.753 -> ---------------------------------------------
18:28:27.753 -> BATTLE INFO
18:28:27.753 -> ---------------------------------------------
18:28:27.753 -> Is Repair Tank? No
18:28:27.753 -> Fire Protocol: Tamiya
.... cannot copy more lines ----> Rongyos
Referring the reload led notification, unfortunately its not working. If I set it true its on all the time, until it gets a hit, making hit notification effect but reload notification is not active. MOD: I just realized I can shoot the cannon after being destroyed (during recovery time). It is not desirable, so I just modified the cannon.ino with this simple stuff (tested, working) // CANNON FIRE
// ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------>>
void FireCannon()
{
if (!Tank.isDestroyed) // Check if the tank is not destroyed
{
if (Tank.CannonReloaded()) // Only fire if reloading is complete
{
if (Tank.isRepairTank())
14
« on: January 06, 2024, 05:16:57 PM »
Hi Luke! Thank you for your support! I will try it tomorrow and share the results of your modifications
As for increasing the length of the tank destroyed period, it is set to 15 seconds because that is the Tamiya standard. However if you want to change it, modify this value near the top of the Tank.h tab:
// Tanks is dead for 15 seconds
#define DESTROYED_INOPERATIVE_TIME_mS 15000 // How long is the vehicle immobilized after being destroyed. 15 seconds is the Tamiya spec. After this,
// the vehicle will automatically re-generate with full health restored.
No, maybe I was not understandable, sorry if my English is not perfect. For me the "tankdestroyed" notify LED effects were very similar to simple hit notification. I just wanted some longer blinking after destroy to make it more clear for the user that the tank is out. If I modify this can I reach my goal? (More blinking time, significantly longer than simple hit notification, the value was 450ms before thats what your comment also said ) // Now set a timer to keep coming back here after a short interval so we can blink the lights
DestroyedBlinkerID = TankTimer->setInterval(5450, HitLEDs_Destroyed); // This is a slow blink, about half a secondI guess you are using the manual pushbutton method to trigger the canon fire? Most people probably use the signal input so I suppose that is why we haven't caught this issue before.
I will update the documentation to make this more clear.
Thanks Luke, my plan was to use the 4th pin of the regular 8pin connector which is the airsoft signal pin. It sends out gnd signal, so thats why I used INPUT_PULLUP function to trigger the cannon fire. I don't need the 5V receiving pin because of this. Achieving my plan will let the users use this unit with older Heng Long and Taigen boards (they just need to extend the 4th wire and connect to relevant connector to the battle unit). I also have 2 Taigens and my test were good except the "phantom firing", but with the simple solution from my friend it disappeared! I will test your led modifications and let you know! Thanks and regards Rongyos
15
« on: January 04, 2024, 12:53:03 PM »
I have a suspicion this is related to the Arduino IDE version issue that was discussed earlier in this thread. With certain versions of the IDE the code will compile but without enough memory available, and the sketch will operate very erratically, if at all.
You were right, I try to get stable 5v from anywhere, uploaded sketch to 4 different nanos and so on but didn't find that solution Thanks, everything working. I downloaded the IDE 1.8.5 and board 1.6.20 Can I ask something? Can you add a simple led blink on HitLeds when cannon reloaded and a little bit longer blinking when tank destroyed?
I tried the reload blink like this, but no success: void OP_Tank::HitLEDs_Reloaded(void)
{
if (CannonReloaded)
{
HitLEDs_Toggle();
}
else
{
if (TankTimer->isEnabled(HitLED_TimerID)) TankTimer->deleteTimer(HitLED_TimerID);
HitLEDs_Off();
}Also, look at the test, I call it "almost there" Unfortunately, fantom firing is still there 19:07:13.025 -> BATTLE INFO
19:07:13.025 -> ---------------------------------------------
19:07:13.025 -> Is Repair Tank? No
19:07:13.025 -> Fire Protocol: Tamiya
19:07:13.025 -> Hit Protocol 2: Heng Long
19:07:13.025 -> Repaired by: Clark Repair
19:07:13.025 -> Send MG IR Code: No
19:07:13.025 -> Accept MG Damage: No
19:07:13.071 -> Damage Profile: Tamiya Spec
19:07:13.071 -> Weight Class: Medium
19:07:13.071 -> (6 cannon hits, 5.0 sec reload, 12.0 sec recovery)
19:07:13.071 ->
19:07:13.071 ->
19:07:13.071 ->
19:07:15.205 -> Fire Cannon
19:07:31.516 -> CANNON HIT! (Tamiya)
19:07:31.516 -> Health Level: 83%
19:07:41.921 -> CANNON HIT! (Tamiya)
19:07:41.921 -> Health Level: 67%
19:07:52.162 -> CANNON HIT! (Tamiya)
19:07:52.162 -> Health Level: 50%
19:08:02.223 -> CANNON HIT! (Tamiya)
19:08:02.223 -> Health Level: 33%
19:08:12.900 -> CANNON HIT! (Tamiya)
19:08:12.900 -> Health Level: 17%
19:08:23.038 -> CANNON HIT! (Tamiya)
19:08:23.038 -> Health Level: 0%
19:08:33.440 -> CANNON HIT! (Tamiya)
19:08:33.440 -> Health Level: 0%
19:08:33.440 -> TANK DESTROYED
19:08:48.467 -> TANK RESTORED
EDIT: I tried to rewrite the button state on the TankIR loop from wasReleased to isPressed and wasPressed, no success
I use INPUT_PULLUP pinmode for my input pin, changed back to INPUT but phantom firing still there. Don't know whats next. Of course, there is no periphery attached to arduino when I checked this on tests, only the Nano was attached to USB.My friend helped me. I set the VoltageTrigger to OUTPUT and no phantom firing occured
|
Show Posts