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 ... 14 15 16 [17] 18 19 20 ... 78
241
« on: October 07, 2020, 12:10:48 PM »
Hi Kim, my apologies for not replying earlier. Fortunately the process is not difficult but there are many steps.
All variables passed to the TCB will be stored in EEPROM on the device chip, and all of the several hundred EEPROM variables are stored in a single "struct." The first thing to do is open the Excel file I have included in the source code (source for the TCB, not OP Config). It is in the \src\OP_EEPROM\ folder and is called OP_EEPROM_Vars.xls
On the first tab "eeprom_data" is where we keep track of all our variables and their IDs. You will want to create a section for Heclo variables, you can pick a gap in the ID list, for example there are no variables starting with 23xx so that might be a good place to put them. I would start with number 2311 and go up from there (if you have more, or need to add more in the future). These need to be inserted between the 22xx and 24xx series variables in the Excel file.
Your variable looks to be defined as a double (same thing as a float on Arduino) but I think you can probably get away with a uint8_t since the value is just a number between 0-200.
In your new row on the Excel spreadsheet you need to enter the values for columns D, G, K, L and optionally M. Column K will be the variable name and this will need to match exactly what is in Arduino (which we will put somewhere else, described below). In your case it looks like the name will be "engine_max_watt"
When you insert a row in the Excel table the formulas in the grey columns will not automatically adjust (C, E, F, H, I, J) so you will need to drag the formulas down from a higher row all the way to the bottom of the sheet so that is corrected. (I hope this makes sense)
Ok great, the "eeprom_data" tab has been adjusted, now we can use the two other sheets to give us the code we need to copy into both the TCB and OP Config firmware.
The Excel tab named "For OP_EEPROM_VarInfo.h" will of course provide the array code for the \src\OP_EEPROM\OP_EEPROM_VarInfo.h (in the TCB firmware) and the tab named "For_QT" will provide the array code for "op_eeprom_varinfo.h" in the OP Config source code (under the Headers section in QT Creator).
But again, since you manually inserted a row in Excel these two sheets will need to have the list repopulated, just select cell B4 and click the little square at the lower right corner and drag it down until you have the complete list at the bottom (hopefully you are familiar with Excel).
Ok, now you need to copy those arrays to the TCB and OP Config firmware in the files I just mentioned above. When you open those files you will see what area needs to be pasted over. ALSO - you need to update the #define NUM_STORED_VARS in both files. This number is calculated for you in Excel. I believe the number now is 331 so if you add 1 more variable it should calculate to 332 if you did everything correctly.
Great, that's step 1!
Now let's tell the TCB firmware about this variable.
Open the \src\OP_EEPROM\OP_EEPROM_Struct.h file in the TCB firmware. You need to create your variable here, and it has to be the same datatype that you defined in the Excel sheet, and it has to show up in the same location. So for example if you created in a new section 23xx between "Smoker settings" and "Driving Adjustments" then in this .h file you will want to define your variable here like so:
... etc ...
uint8_t HotStartTimeout_Sec;
// Heclo variables
uint8_t engine_max_watt;
// Driving adjustments
boolean AccelRampEnabled_1;
... etc ...
Now do the same thing to the \src\OP_EEPROM\OP_EEPROM.cpp file (look way down near the bottom), only this time use the "ramcopy." prefix before your variable name, and give it whatever default value you want (this should be the same as the default value you assigned in the Excel), like so:
... etc ...
ramcopy.HotStartTimeout_Sec = 0;
// Heclo variables
ramcopy.engine_max_watt = 100; // engine_max_watt default set to 100
// Driving adjustments
ramcopy.AccelRampEnabled_1 = true;
... etc ...
Ok, we are nearly done with the TCB side of things. In the Arduino sketch you can access your variable by the name "eeprom.ramcopy.engine_max_watt" But you don't really need the variable in the sketch, you want it in the OP_Driver class, so I'd just add it to the class begin() statement, and then pass it to the class from the sketch where the Driver.begin() call appears (around like 284 in my copy, on the first tab in the Sketch, this is under the Setup() section). There are already several other eeprom variables passed to that class so you can easily see how to add another one.
Great! Now you have the variable passed to the OP_Driver class and you can do whatever you want with it in the class begin function (typically save it to a local class variable and then refer to it in your class functions).
Ok, one more thing on the TCB side - go back to the \src\OP_EEPROM\ folder and open up the "OP_EEPROM.h" file. Near the top you will see a define called "#define EEPROM_INIT" set to some 4-digit hex number. Change this number, it doesn't matter what to, just so long as it is different. This will cause the firmware to force an eeprom reset on the next boot after you flash this firmware, so that it can wipe the old eeprom values and adjust for the new one you added. This 4 digit number will itself be saved to eeprom so on subsequent boots it will skip the reconfiguration (which deletes all the saved values), but anytime you change the number a reconfiguration will occur. So the first time you flash any firmware that has new eeprom variables added to the source doe, you need to change this INIT number.
At this point you probably want to change the firmware version number too! This is done in \src\OP_Settings\OP_Settings.h
This post is getting pretty long, so I will do another one about how to wrap up the OP Config side of things.
242
« on: October 04, 2020, 12:28:58 PM »
Hi Osika.
1. No, you can not control the Taigen recoil from the Benedini sound card. It can't provide the necessary current and also it is not an easy on/off switching procedure, the controlling device has to be able to read the limit switch on the recoil unit in order to know when to turn off the recoil motor, and the Benedini doesn't know anything about this.
2. Are you using one of the functions to enable/disable/toggle the mechanical recoil from your transmitter? If so, it may be something simple such as the position your transmitter switch is placed when the model is turned on. You can post your OPZ file and I will take a look if you want.
243
« on: October 02, 2020, 02:22:52 AM »
Thank you for the kind comments!
244
« on: September 28, 2020, 12:44:09 PM »
More often than not it's something simple like that! I'm glad you figured it out.
245
« on: September 27, 2020, 07:23:08 AM »
Hi Osika, I'm glad you like it and you are fortunate to have found one after such a long time out of production.
I am hopeful the board will be available again someday, but I think the wait will have to be a little longer still. When or if it reappears I will of course let everyone know!
246
« on: September 24, 2020, 09:23:18 AM »
Hey Joe, it's looking good. It must be cool to see an actual "thing" start to materialize in front of your eyes from what were just spools of filament to begin with!
It's definitely true that less is more when it comes to solder paste, I seem to have to learn that lesson over and over. This is especially the case on ICs with small pins located close together, or on chips with multiple pads underneath (too much paste and the pads will bridge, and there is no way to fix it after the fact). Using a stencil greatly helps with placing an appropriate amount of paste, though it is possible to overdo it even then. I would suggest getting one for Kim's design. Occasionally for some packages it ends up being easier to just hand-solder, I found this to be the case with the ATmega processor on the original TCB, but I reflowed everything else.
247
« on: September 16, 2020, 01:52:54 PM »
Hi Kim, sorry for the slow reply, things have been very busy lately. I think your modification that reduces the input to a single variable in watts is much more practical for the end user. They still need to know what a watt is, but they can experiment.
Nevertheless, I am unwilling at this time to make further changes to OP Config for this purpose. You are not being a PITA at all by making the request and I would like to accommodate it, but it sets a precedent which I would be obliged to maintain in the future, and there are other long term considerations I have to keep in mind. I know it is more work for people to compile the firmware if they want to make a change to your code, but at present the number of people using this is very small, and I have to keep some limits both on what I incorporate into the main project and also on the amount of work I sign up for voluntarily.
I am happy to make another change to the firmware and post a new hex, either with the power regulation turned on at a default of 50 watts, or else disabled by default, or something else if you have an idea. But to change it from whatever the default state is, the user will have to modify the source and recompile, or ask someone to do it for them if they don't know how.
The source for OP Config is also open so I suppose another option is to fork that and modify it to your heart's content!
248
« on: September 09, 2020, 09:04:00 AM »
The whole idea of the wattage regulation was to make the model behave as their prototype meaning when the model goes through rough terrain it should slow down to a pace that reflects the prototype.
A feature I would love to be implemented in the OP Config is the ability to set this max motor power. As it is now it has to be set in the OP_Driver.cpp Hi Kim, I have had to look more closely at your code, I admit when I first saw the words "PID" my eyes glazed over. I have some vague memory of them from college or somewhere, but only recall that it is somewhat complicated. When you say the max power is set manually in OP_Driver, are you referring to this array: log_speed_curve_out[] ? If so, it looks like there are 5 numbers actually needed, corresponding to the desired max wattage for 5 segments on a logarithmic scale. Even if we make it possible to set these numbers in OP Config, I wonder how many people are going to have any clue what to enter? The final effect will seem to depend on the motors used, the gearbox ratio, the battery voltage, and the model's specific handling characteristics as influenced by its weight. Even if they have the ability to measure their own current draw (which most do not as I have discovered on this forum), it still seems like it will take a lot of trial and error over different terrain at different speeds to derive suitable wattage values. To me this just seems like something very, very few people are going to want to do or even be able to do. I am not saying it is a bad feature, in fact it is very cool, but it is not widely applicable. Even having looked at the code I am still not perfectly clear on how the scaling and PID work, so I don't think I would be able to explain it very clearly in the help files. I tried to create a similar effect myself, but my approach was to use an IMU. This was useful for barrel stabilization but at the same time could also measure when the tank was going up or down an incline. When going up, the maximum speed would be reduced, so the user would have to use more throttle to get up the hill, and the throttle sounds would increase, even though the tank was moving more slowly. When going downhill the effect would be reversed. The only adjustment the user would need to worry about in OP Config was the sensitivity, which was a number from 0-100% and it could also be adjusted from the transmitter if they wanted to experiment on-the-fly. It worked quite well but in the end the 2560 processor couldn't handle the IMU communication along with everything else so I removed it from the final version. But I guess it illustrates an approach to this sort of thing that also keeps in mind the user and tries to make the settings easy and simple for them to understand. If I am making a product just for myself of course I can put in many complicated and esoteric capabilities, but if the goal is to share it with everyone then I have to take into account everyone's abilities. Already the main complaint about the TCB is that it is too complicated. From what I can see now, as much as I think your approach is very impressive and clever, I'm not sure I want to add a section to OP Config for these adjustments. The number of people who would use it is surely so small that it would be easier for the rest of the community if those few people compile their own custom hex files. To be honest, since your fixed values may not work for everyone, what might even be the better approach is to have the code function by default the way the standard TCB does. For those users who do want to use your custom wattage scaling, they would need to edit the code to enable it (set some variable to "true") and enter their 5 custom values. It would be best to put these options in a dedicated .h file rather than in OP_Driver, that would make it easier for the user and less likely they accidentally change something else. Then those users can recompile the code with their changes. But otherwise for people who want to use your shield but don't know anything about compiling code, the driving would already work like a normal TCB and they wouldn't have to think about any of this.
249
« on: September 09, 2020, 07:26:31 AM »
In his other thread Joe mentioned the video of Dean's tank but when I went to look for it I never saw it posted anywhere. Here it is for those who are curious to see it in action!
250
« on: September 07, 2020, 04:30:52 PM »
Kim and Luke, thanks for the soldering tips and workflow. I am doing a lot of research about SMD soldering on Youtube. I am working on making a toaster oven I have into a reflow oven, which I think will give me the best chance for success with Kim's TCB Hat board. I see some folks do double-sided boards in reflow ovens by using a temperature sensitive expoxy under the chips when reflowing the first side. That may be the way to go, or am I overthinking it? Looks like we just posted at the same time. I have not done oven reflow before but I agree it would probably be the easiest method for a double-sided board. From what I have read, the upside down parts should stay in place even without epoxy, simply from the "stickiness" of the paste itself (before melting), and after melting, from the surface tension of the liquid solder. However, this is probably most true for small components like resistors and such that don't really weigh anything. The VNH chips have a metal slug in them and are probably (relatively) heavy so those I am not so sure about, but Kim can answer that. Those might also be difficult to epoxy since the bottom of those chips is mostly going to be soldered. However, if you do the board in an oven you only have to melt it once and you can just reflow it with the VNH chips on top so gravity is not a problem. I've begun assembling the road wheels on the T-35a that I'm building from Dean Rauch's files. I've been trying to get an answer from him on what metal he is using as a leaf-style return spring on his bogeys, but so far no answer. I've tried contacting another fellow on Thingiverse who also built from Dean's files, but so far no response. I've attached a photo of what I'm talking about. I tried some galvanized steel sheet I had, but it was too soft. Perhaps stainless steel around 0.35mm? I'm afraid I can't be of much help with that one! But I'm sure if you experience with various sheet metal you will find a suitable material. I would think stainless is generally less flexible than carbon steel, but in such a small scale maybe it doesn't matter, the thickness is probably what is important. Leaf springs are widely used in 1/10 scale crawler RCs but I don't know if they would be the right length/width for your requirements, however they are easy to source so maybe you could try some. The other thought that comes to mind is women's hair barrettes, but what are the odds they would be the right size?!
251
« on: September 07, 2020, 04:12:54 PM »
I don't quite follow you here. In my Frankenstein Leopard 2 (the one I make most of my experimentation on) I use brushless motors which are being controlled by ESC's (BlHeli32) via the servo outputs. The ESC's are supplied current via the EXT_ESC connector on the board, so their current consumption can be measured. The motor wattage is regulated to an accuracy of +-0,5W. I'll post a video of it in operation tonight? You are completely correct! I needed to look more closely at your schematic. I knew the VNH5050 chips provide a current measurement output and I just assumed you were using that, but I see you have a dedicated current measuring IC so you are right, your code can work with any motor drive type. I have changed the code back to the way you had it and posted it as firmware v0.93.71. It is a very interesting idea to regulate the model's behavior based on current draw and I would be curious to experience the difference in driving style that might give. Perhaps when I return to America I can try to build one of your boards so I can experience the difference first hand. I am still a little unclear about your assembly process. I understand you do the VNH5050s first on the top of the board. Then you flip the board upside down, and this is the part I am confused about - since the VNH chips are now on the bottom, do you leave that section of the board hanging off your hot-plate? Otherwise the board would not lay flat on the hot plate. The sound amp and the two turret driver chips are really the only important ones to reflow on the bottom since they have hidden pads, and I see they are not directly over (under) the VNH chips, so it looks like it will work even if you leave the VNH end hanging off the hot plate. I suppose the surface tension keeps the VNH chips attached even as their paste melts again during the second reflow, but I can imagine it would be important not to knock it suddenly while hot! Have you had problems with that?
252
« on: September 05, 2020, 07:56:12 AM »
Thanks for doing that Joe, that is a lot of work I know! I posted the file on the downloads page. It should be easy to use the part numbers to find equivalents at Farnell or other places for those in Europe or wherever. I am sure you will master SMD soldering with just a little practice. For the chips with lots of small pins I find some flux to be very useful, it helps the solder flow much easier and you can just drag your soldering iron across the pins and voila. You can buy it in a small plunger type needle thing that makes it easy to apply. You can also try reflow soldering which I find actually to be easier than hand soldering. There is a discussion about it in another thread on this forum starting here. I use a cheap electronic hot plate. The one thing I have not done is a double-sided board. To reflow one of those you would need a small oven rather than a plate. Many SMD components can be hand soldered but some chips like the VHN5050 motor drivers that Kim uses will really need to be reflowed because they have pads underneath the chip (in addition to the legs sticking out the sides) that have to be soldered, and of course you can not get a soldering iron underneath something. It looks like he has the audio amplifier and the smaller BD63573 chips on the bottom of the board and I believe those also have inaccessible pads. So I think reflow will almost have to be the only way you can mount at least some of these components, but maybe Kim will let us know what method he used.
253
« on: September 03, 2020, 11:40:01 AM »
Hi Rongyos, first I have to say I admire your creative thinking. I am always impressed with the clever ideas that people come up with.
I understand what you're proposing and I think it could theoretically be possible. From my experience with electronics, I think there are some challenges. One is that turrets move very slowly and electrical switches do not provide what we call "clean" signals to a processor who will be reading them several hundred times a second. So I think the software can easily become confused when the turret passes over the switch. Also a single switch will probably not be enough. If it touches the switch at the limit, it can say "ok, you have to move the other direction now." But how long does it need to move the other direction before it will allow the switch to be hit again? When the switch is touched again, is it because we just moved a little way away and then came back (which we do not want to allow), or did we go all the way around and hit it from the other side (which is ok)? Two switches at least would be required, but even then I think it will be possible to confuse the software if we really try. Three switches would be better, but that gets to be too much for the user to setup.
A rotary encoder would be best. These are like little knobs that can be turned and they count up or down as they rotate one way or the other. However the rotary encoder would need to be geared to the turret ring somehow, we would probably need to design a 3D printed gear. And then also the user would have to know how many revolutions of the encoder equals one revolution of the turret. So some kind of setup routine would need to be run to calculate this. That would be a lot of coding and it would be kind of a pain for the user the first time, but after the setup I think it would work well.
It would work, that is - until they remove the hatch for maintenance on their tank, and now the count is no longer valid! So then we have to provide a way to tell the TCB to reset the count to Zero. In the end I am not sure we have saved the user any work!
I like the general idea and I am of the same opinion as you about the small 360 sliprings, I think they are not great. The wires are very small and do not allow a lot of current, and they are well known to cause problems with sending and receiving IR.
However I think for this to be an idea worth investing time in, it would have to be possible to do it in a much more simple way. Right now I can't think of a very simple and fool-proof approach. It is a clever idea but I think it needs one or two more clever ideas to go with it to really make it effective in practice. Maybe someone will come up with these other ideas in time? I will keep thinking about it.
254
« on: September 03, 2020, 10:25:26 AM »
There is one other thing to think about - what happens when in the future changes are made to the existing TCB firmware or to OP Config? I can not promise that I will have the energy to maintain your firmware too. If you create an account on GitHub I can grant you permissions to the Heclo Shield repository and you can make the updates yourself (either copying the new TCB updates, or adding new features of your own). But as the years and decades go by this might become very tiring (ask me how I know). If worse comes to worst, the existing firmware will always work. But if it is not kept up to date, what will eventually happen is that some new variable will be added to OP Config that your firmware will not know about. At that point, your firmware will no longer be compatible with new versions of OP Config. However, all the prior versions of OP Config are stored on the website ( OP Config prior releases) so people can just continue to use v0.93.70. Anyway, we can just see how it goes, right now the firmware is not being updated very often, but of course it is inevitable that someday it will be. Thank you again for your great work on this project and I hope to see other people using it! I will be interested to watch Joe as he tries to assemble them, and if you have any tips for reflowing components on both the top and bottom of the board I'm sure he will be glad to hear it! Also Joe if you do manage to create a bill of materials I will be happy to post that also on the downloads page.
255
« on: September 03, 2020, 10:11:16 AM »
Hi Kim, I've posted your firmware and files to the Downloads page and also created a GitHub repository: TCB-Heclo-Shield. I've made a few changes to your firmware: - I've created a new motor class called Onboard_ESC_CD (for C & D). I've put the Sabertooth_SerialESC motor class back to normal so now that can still be selected. In OP Config, I've created a new entry in the Drive Motors list called "HECLO ONLY! - Drivers C & D" so users can select these new outputs.
- To keep compatibility with all the other TCB boards in existence, I had to make your VNH5050 the C & D outputs, so we can keep the turret outputs at A & B. I renamed the variables in your code as well to keep everything consistent. From what I can see of your physical PCB I don't think this will require any changes to the silkscreen since I don't see A, B, C or D written on the board, but you will know better than me.
- Your motor current measuring code is good when using the onboard C & D motor drivers, but it would break any other kinds of outputs (serial controllers, hobby ESCs, etc...) so I added a check and now the current measuring code is only used when the C & D motor drivers are being used but the old code is used for any other kind of output. Of course if someone is using your shield they are most likely going to be using the onboard VNH5050 drivers, but it is best to allow all options just in case.
- I removed the mavlink folder from the source code because I couldn't see that it was being used anywhere. If this is a mistake you can let me know, but it compiles without it!
On GitHub, I started from a clean copy of the TCB firmware version 0.93.68. I then applied your changes, and then I applied my changes. So now if you look at the commit history it is very easy to see exactly which lines have been changed at each step. I also gave your shield a unique device ID, this can be found near the beginning of the Arduino sketch: // HARDWARE VERSION
DEVICE HardwareVersion = DEVICE_HECLO_SHIELD; // This is the Heclo TCB shield for Mega2560 boards
I've updated OP Config so that it should recognize this when it connects (the device type should appear at the bottom of the OP Config window). Users can also now select your firmware in OP Config on the Firmware tab by choosing "TCB - Heclo Shield" in the Hex file drop-down box. The new software version for everything (OP Config, old TCB, your new TCB shield) is v0.93.70 (I skipped v0.93.69). It would be good if you could flash this new firmware to your shield using OP Config just to make sure everything still works as you expect. I didn't make many changes but you never know when a bug can be introduced accidentally!
Pages: 1 ... 14 15 16 [17] 18 19 20 ... 78
|
Show Posts