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 - LukeZ
Pages: 1 [2] 3 4 5 ... 79
16
« on: January 08, 2024, 02:04:58 PM »
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. Ok, up to now I have not thoroughly re-acquainted myself with the entirety of this project, and making changes until I've done so is always a mistake. I've spent a good deal of time today looking through everything, and hopefully I have a better idea of what is going on. Ultimately what your friend did in setting the direction of the positive trigger pin to OUTPUT will not fix the phantom firing issue, though it might have improved it. The problem is we still have an interrupt defined on this pin which is causing the problems. The solution is to create another setting in A_Setup.h where the user can specify whether they want to use this input or not. I've made it the first setting in that file, and by default it will be false (disabled): #define USE_5VOLT_TRIGGER false
When false, the interrupt will not be created and the setup of the pin will be handled appropriately. There is no need for a setting for the negative-input/pushbutton trigger, that one can always be active. It uses an internal pullup so isn't subject to stray voltages, also it doesn't use a hardware interrupt procedure and should ignore anything other than a very intentional signal. 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. This was an error on my part. I've corrected it and it should work now. I also increased the blink time a little bit to 400mS. 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)
Wow, great catch! I can't believe I missed that. In fact the same bug is present on the TCB, I will fix that too. The GitHub is now updated with all these changes. I hope now everything will work, please let me know your results.
17
« on: January 07, 2024, 10:10:47 AM »
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(450, HitLEDs_Destroyed); // This is a slow blink, about half a second Yes, if you want to change the blink rate for the destroyed notification, then you can modify the 450 value that you mentioned above. If you use a smaller number the blinking will be faster, or if you use a larger number the blinking will be slower. Regardless it will continue to blink for 15 seconds (or whatever value you decide to specify for DESTROYED_INOPERATIVE_TIME_mS). 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! 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.
18
« on: January 06, 2024, 11:31:16 AM »
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?
Hi Rongyos, I've posted an update to the firmware to GitHub, there is now the option to have the apple Hit LEDs blink when the cannon reload time has completed. By default it is off, you can set it to true in the A_Setup.h file near the top. // NOTIFICATION LED
// --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------->>
//
#define CANNON_RELOAD_NOTIFY false // << --- SET ME - set to True to blink the IR apple notification LEDs when canon reload time has transpired (CUSTOM_CANNON_RELOAD below)
I'm not sure how long the blink should be, and I don't have an Arduino right now to test. Currently it is set to 250mS, which is only 1/4 of a second. If you want to increase the time, modify this function at the very bottom of Tank.cpp: //------------------------------------------------------------------------------------------------------------------------>>
// HIT NOTIFICATION LEDs CANON RELOADED - Short blink to notify user the canon reload time has completed
// Can be enabled/disabled with setting CANNON_RELOAD_NOTIFY on the A_Setup.h tab
//------------------------------------------------------------------------------------------------------------------------>>
void OP_Tank::HitLEDs_ReloadNotify(void)
{
HitLEDs_Blink(250);
}
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.
Finally, with regard to the "phantom firing" - I probably should have made this more clear, though it is shown in the included sample schematic PDF - but you need to place a resistor between A0 and ground. 10k is shown in the schematic though the value is not important. What you have done by setting A0 (pin_VoltageTrigger) to OUTPUT will also work, but then of course you would have to change that if you were going to use this pin in the future as an input signal from some other MFU. I 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.
19
« on: January 04, 2024, 11:45:37 AM »
Hi Rongyos, 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. The solution is listed in that post, or again on this page of GitHub under the "Compiling Firmware" section. So I would suggest following the instructions of opening the Boards Manager in the Arduino IDE, finding the Arduino AVR Boards section, and then installing boards version 1.6.20 and try recompiling and see if that makes a difference. This could explain several of the problems you're seeing. An other question. Do you know where can I get constant 5V from the Taigen V3 MFU? It seems the CN2 is only providing around 1.8V
I don't have one to test, but I believe you should be able to find 5 volts from the sound card port, and possibly also the IR port. I can't say which pin is what, but you can use a multimeter to verify. However, I can't say how clean the voltage will be from the Taigen MFU, and it might be better to use a 5v regulator to power your receiver and Nano.
20
« on: January 02, 2024, 11:50:10 AM »
Hi Chris,
Congrats on the most epic first post of all time! Guess you decided to jump straight into the deep end.
Back in the day I actually had complied in 5.6 with High DPI as a test, but since I didn't have a display with resolution greater than 1080P, it wasn't a very useful test. From what you've shown, the High DPI setting does seem to work well.
What this test back then did show me however were a few challenges that would come with upgrading to 5.6. The biggest downside was that QT Assistant (the program that renders all the built-in help files), was no longer supported, and at the time there wasn't a clear replacement. You can see a note to this effect in your first screen shot. It seemed a shame to lose the help, and most people were probably not using high resolution displays (well, that would have been more true in the past than today), so I stuck with 5.4. There were some other annoying bugs with 5.6, however I have heard they were fixed in later versions which did not exist back then.
Obviously if we're up to 5.15 now (not to mention 6.x), then a lot has changed in the intervening years, and maybe it is possible to get OP Config fully functional with a newer version. Having the high resolution issue resolved is a big advantage, but thorough testing needs to be done to make sure all the other components work.
If you want to keep experimenting please keep me posted on your progress and I'll be happy to help as I can!
Luke
21
« on: November 27, 2023, 07:09:48 AM »
You can use any ESC that you want, the Sabertooth is not required.
22
« on: November 22, 2023, 08:20:46 AM »
Good work, and that's with two speed controllers and the bulky OP sound card. You've even kept the wiring very clean!
23
« on: October 27, 2023, 02:10:38 PM »
I'm glad to have helped!
24
« on: October 27, 2023, 11:15:38 AM »
Hi Rongyos,
This should be easy to do. You have the right idea. Try putting this code in the setup() routine of TankIR.ino, after the "RECOIL SERVO DEFINITION" and just before the "BATTLE SETTINGS" section (in other words, somewhere around line 139)
#define pin_WeightJumper 7
unsigned char WC;
pinMode(pin_WeightJumper, INPUT_PULLUP);
if (digitalRead(pin_WeightJumper) == LOW)
{
WC = WC_HEAVY;
}
else
{
WC = WC_MEDIUM;
}
Next, in the "BATTLE SETTINGS" section just below you just need to set BattleSettings.WeightClass to our new variable WC (replacing the WEIGHT_CLASS that was there before). This is currently at line 145:
BattleSettings.WeightClass = WC;
The check will only occur once at startup, in other words, if you change the jumper after the board has power the code won't do anything, you will have to reboot before it checks again.
Let me know if it works!
25
« on: September 04, 2023, 01:48:56 PM »
Hi Sub, sorry for the slow reply. I would have guessed the voltage regulator as well, but you discovered it yourself. Good work, and thanks for reporting back.
I remember reading somewhere that some of the Chinese Arduino boards use voltage regulators which have a lower current rating than what they claim in the specifications. At higher currents, this could cause the thermal shutoff that you theorize. And the higher the input voltage that the regulator has to drop to 5 volts, the more current and heat will be created. This might explain why yours worked with a lower voltage battery but not with a higher voltage battery.
In your case it seems like the regulator worked for a long time but slowly began to fail. I guess it was just a poor quality part. I agree, hopefully this information will be useful to others.
26
« on: July 08, 2023, 03:29:05 PM »
Hi Rongyos,
I don't know if I understand your question exactly, but I will try to explain this bit of code and maybe that will help you.
First of all, if we reach the code you have posted, we already know that we have received a cannon hit (not a machine gun hit).
By this point we have also already calculated our new damage percentage based on this cannon hit. All that has come before this code.
Now, in the code you posted, we have the first part of the "if" statement: if (DamagePct >= 100.0)
This means that we've added up all our damage and it's equal to or over 100%, therefore the tank is "destroyed" and must be disabled.
The second part of the "if" statement is the "else" condition: else we have been hit, and our damage has increased, but we are not yet destroyed (in other words, damage is less than 100%).
In that case we flash the LEDs in the apple that indicate a hit was received. We also enable an invulnerability timer, but only a very brief one. This is simply to prevent receiving multiple hits from a single shot of someone's cannon. As you know, the Tamiya signal lasts for a full second - that would be enough time for us to register many hits if we didn't have this brief timer.
I hope that helps!
27
« on: June 14, 2023, 03:27:15 PM »
Well it took me two years, but I finally got around to adding the Wiki page for the barrel smoker. Please feel free to continue using this thread for questions and discussions about barrel smokers. Barrel Smoker Wiki page
28
« on: June 04, 2023, 03:22:17 PM »
Thanks again Rongyos for helping with the testing!
I've finalized all the changes and posted a new official release, it is version 0.93.76 (both TCB and OP Config). I've also updated information in the Wiki.
29
« on: June 02, 2023, 03:43:51 PM »
Ok, I've taken your suggestions.
- The fade back to full brightness at the end has been shortened to almost nothing.
- The flickering has been "softened" a little. I have limited how much the brightness can vary between each step so that it doesn't make changes so abruptly.
I hope this looks better.
30
« on: May 31, 2023, 04:42:40 PM »
Hi Rongyos, I bought a cheap Arduino UNO and a couple LEDs so I could do some testing on my laptop. Here is yet another update where I've adjusted the flickering effect to be about as good as I can get it. Other changes: - I've removed completely any effect on the headlight output since that simply doesn't look good.
- But I did add the effect on the Aux output (Arduino pin 8 ). So you use that for your headlights instead. Of course the Aux output needs to be On when the engine is started or else nothing will happen.
- The flickering effect will apply correctly now to the brake light depending on whether the brake light is on or just the running light.
- When the flickering is finished (the transmission engage delay has expired/your engine start sound has finished), the lights will gradually return to full brightness instead of doing so abruptly all at one.
You can let me know what you think.
Pages: 1 [2] 3 4 5 ... 79
|
Show Posts