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 - Heclo
1
« on: October 08, 2020, 07:44:48 AM »
Luke! You're a star! Thanks for the detailed walktrough, it worked in the first try, I was kinda perplexed  Before I move on with the modding, do you have a repository for the 0.93.71 version? The one with Onboard driver C and D integrated. I just went ahead and tested with version 0.93.70  Have a great day, Kim
2
« on: October 07, 2020, 02:15:13 AM »
Attached the wrong picture to the post above..
Here is OP_Driver.h
3
« on: October 07, 2020, 02:01:50 AM »
I have gotten a Qt environment up and running thanks to this thread and I have managed to compile a working OP Config.exe
however not being familiar with anything but arduino code (and other micro controller level code, being an electronics engineer)
I have trouble figuring out how the parameter data go from the OP config to the TCB.
Where is the variables stored before being uploaded to the TCB?
How does the TCB recognize the data?
I would like to add entirely new settings to the OP Config, settings related to my own TCB design.
I have tried making copies of existing combo boxes and spin boxes but I'm not completely sure I'm on the right path.
This is what I've tried thus far:
I want a spin box in the Motors tab, with the setting for motor watt output, this should change a public variable in the OP_Driver class
Best reagards Kim
4
« on: September 14, 2020, 03:16:52 AM »
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. I have made a modification to the code so the logarithmic curve is fixed, meaning there is only one variable that need to be adjusted = engine_max_watt. The 5 points on the curve will be derived from this number. float engine_max_watt = 50.0;
float log_speed_curve_in[] = {0, speedLimit >> 3, speedLimit >> 2, speedLimit >> 1, speedLimit};
float log_speed_curve_out[] = {0.0, 0.02 * engine_max_watt,0.08 * engine_max_watt,0.25 * engine_max_watt, engine_max_watt};
setpoint = FmultiMap(desiredEngineOutput, log_speed_curve_in, log_speed_curve_out, 5);
feedback = engine_watts;In my testing with different tanks there have been no need to tune the PID k values. I have tested tanks ranging from 20W to 180W and max Max speed (set in OP Config) of as low as 15%. I don't think the users of Open Panzer should be underestimated, if someone wanted a plug and play solution they wouldn't be looking here. The project is already 100% DIY so if one has come this far...  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. This is how I've been doing it thus far, easy for me, not so much for anyone with no coding experience. I imagined a parameter in the config like "Enable motor power regulation" and then a parameter like "Engine max power" with a default value of 50. The help file could explain that in order to scale the power use this formula: prototype kW / 16 ^ 3, and that due to the immense torque of electric motors the end result usually needs to be reduced by means of trial and error (go up a 60% slope and your speed should be reduced to a crawl). One could even make the parameter in OP config be the value of the real tanks horse power, so that the user can lookup the real tank's specs and thereby get scale correct performance. The calculation could then be made in the code converting it to scale Watt (just an idea). Could it be made so that if one have selected the "Heclo board" that new options become available? Like they remain hidden until you choose board or something? I hope I am not being to much of a PITA, I am just very enthustiastic about making the hobby as realistic as possible  Cheers Kim
5
« on: September 08, 2020, 02:17:09 AM »
since the VNH chips are now on the bottom, do you leave that section of the board hanging off your hot-plate? Exactly yes! It is is not the optimal solution, but due to the component density on both sides of the board, this has proven the most practical. 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? In fact the VNH5050 can soak up so much heat that they doesn't reach the melting point while hanging over the side, I haven't had any problems with it anyway. I use 37/60 solder and a hotplate temperature of 220c. 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?
This sounds like a very interresting approach! 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. Thank you for reimplementing it! 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. Using my leopard 2 as example: Prototype: Engine power = 1130kW Model: engine power (scaled down) = 272W, adjusted after rigorous testing to 100W Weight = 62000kg Weight = 13,8kg Top road speed = 73km/h Top road speed = 4,56km/h Top terrain speed = 40km/h Top terrain speed = 2,5km/h The result is that when I drive the tank through grass or up a slope it slows down while the motor sound is still going full monty and if I try to go up a slope that is too steep the tank will grind to a halt, just like the real thing would. 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. By the way if it would be helpful to you Luke I could send you a finished board? It makes it a lot easier to work with code I imagine. Cheers Kim
6
« on: September 07, 2020, 03:37:30 PM »
I jumbled together a video showing the regulation feedback debug. You can hear the blheli_32 ESC's beep to life in the beginning. Sorry for the shoddy filming. Best regards Kim
7
« on: September 07, 2020, 03:20:22 AM »
Wow, Luke, you've been busy!
I have the bill of materials and will post it here. I have sourced Digikey Electronics here in the US for the components and have included their part numbers and links to the parts on their site. I hope it is helpful!
I've not made any progress in building my boards. I recently started building "THEDIYGuy999" micro receiver board and am having problems getting it working. It is all SMD components and until I conquer it I'm not going to attempt Kim's much busier board.
Learning to work with SMD's at the tender age of 68 is a bit of a trial. I think I can solder them pretty well now, but when things don't work it is very hard to troubleshoot. Continuity testing is fun when you are switching between 5x magnifier and reading glasses between the board and the schematic. Likewise, it is difficult to get a scope probe on a tiny Mega328P pin! Oh well, what else are we to do during the Covid shutdown??
The soldering process I use is as follows: 1. Reflow solder the VNH5050's. Check for bridging/gaps (using multimeter) 2. Reflow most of the underside components, starting so close at you can get to the VNH5050's which are now upside down and hindering a complete reflow of the buttom. 3. Hand soldering the rest of the top SMD components 4. Hand soldering the rest of the buttom SMD components 5. Hand soldering the top through-hole components 6. Hand soldering all of the pins going into the arduino mega. (mounting the pins in the mega using it as the holder is the easiest way to do it) Saying this is an easy soldering task would be a lie. It takes some practice to solder smd components of this size, youtube is your friend. I use a simple hotplate for the reflowing such as thisCheers Kim
8
« on: September 07, 2020, 02:58:28 AM »
Thank you so much for taking the time Luke! 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. This is exactly what I had in mind, perfect! 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. This was how I named them intially, but to get around the onboard motor driver warning in OP config, I switched them around. So this is perfect aswell. 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 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? 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! Yes this was a remnant from my experimentation with the "telemetry" out of the board, CRC calculation namely. I will test the firmware ASAP!
9
« on: August 26, 2020, 01:31:28 AM »
Hi Kim, what is NT1 - Net_Tie_2 on the PCB? I'm working on a Bill of Materials with part numbers and prices for Digikey electronics here in the USA which I can post, when complete, if there is any interest.
Cheers,
Joe
Hi Joe, The net tie is just where the different ground planes join at the board, it's not a component JLCPCB are super fast! They are my go to PCB maker aswell 
10
« on: August 21, 2020, 06:49:32 AM »
Hi Kim, I'm trying to put together a BOM spreadsheet, but when I view your Kicad schematic there appear to be holes in it. (please see attachment)
The schematic appears complete in the PDF version you uploaded, but some of the values are overwritten by other components and the values or names can not be read.
Is there a problem with the uploaded schematic you posted above, or is this a configuration setting in my installation of Kicad. Sorry, I don't know how to use that Ecad software, so maybe I just don't have it set up correctly.
Regards,
Joe
I have attached the project folder with all of the dependencies. Just unzip the entire folder and open the project file, that should solve it. Cheers
11
« on: August 20, 2020, 01:12:37 AM »
Hi Kim, thanks for posting the firmware. I am in the middle of moving right now so I have not yet had time to look at it. Next week when I get settled into my new place I will try to set aside some time and get it posted to GitHub.
No rush good sir I am just glad you want to give it a look! Cheers Kim
12
« on: August 19, 2020, 08:11:57 AM »
Thanks very much HECLO. Now that the code is posted I will order the PCBs. I have two tanks that will need your board. One is built already (my IS-1) and I'm working on a second tank, a T-35.
I appreciate your efforts to design this board and software and thank you for being generous enough to share it with us on the forum!
Regards,
Joe
Glad to hear that you can use it! I have some notes on the BOM: U7 The teensy controller, *this is only relevant if using an external DAC*: if using 3.2 = remove pin 7, 20 and 21. If using 4.0 = remove pin 9, 22 and 23. The incentive to use an external DAC is to get 16bit sound instead of 12bit, which only matters if your audio files, and speaker are top notch. U9 I use the 7805 as a placeholder in reality i use these DC-DC converters for efficiency U10 INA181 needs to be the A3 version with a gain of 100 Q2 can be any N-Channel MOSFET in a SOT-23 package with the same pinout and a continous current of 1A or more. Input_jmp1 if using the onboard Teensy DAC, jumper pin 2 and 3. VNH5050A (the main motor drivers) are truly a PITA to solder. I check every solder for continuity and shorts on these chips. I wish you the best of luck Cheers Kim
13
« on: August 18, 2020, 05:39:14 AM »
Thanks for the Gerbers, I took a look at them in KiCad. You have done a professional layout job, I am impressed. You said you used this project for an exam, are you an engineering student? I think you deserve a good grade, I hope you get one!
I look forward to inspecting your firmware and I will be happy to host it on the OP GitHub, it should be possible to make you a contributor so you can maintain that repository. It also should not be a problem to add an entry to OP Config Firmware tab so users can select your firmware for download/flashing.
As you say, with all the microcontroller advancements constantly being made there are now many tantalizing possibilities, but people who possess time and skill are necessary to realize them, and in so far as there is no great financial reward for doing this work, these must also be special people who have other motivations (educational achievements appears to be a good one!)
Thank you for the offer to help with board layout, I will keep it in mind and let you know if I can get the design to the layout stage.
As promised: the modified code for my version of the TCB, with comments Just ask if there is something I havn't explained properly I am still learning so there might be some odd solutions in there XD The modifications are in: OpenPanzerTCB.ino Objectsetup.ino LVC.ino OP_Driver.cpp OP_Driver.h OP_Motors.cpp OP_Settings.h and an addition in form of: Status.ino
14
« on: August 17, 2020, 06:49:19 AM »
Wow, this is very interesting! I am currently building a tank and am looking for a control board. Having the control and sound integrated into one package is quite appealing.
Do you have a BOM (bill of materials) prepared that you could share? Is there a site (perhaps Youtube or ??) where I could see some of your tanks in operation?
I'm building a T-35a and it will need a control board.Definitely interested!
Cheers,
Joe in Pennsylvania USA
Thank you! Sounds interesting If you download KiCad (freeware) you can open the project schematic and generate a BOM from that. The schematic and layout will also be a great help if you decide to build it. I am working on commenting the code alterrations/additions I have made, so that they will be comprehensible to others than myself  Best regards Kim
15
« on: July 15, 2020, 08:18:46 AM »
Here are the schematics for my latest build, it is drawn in KiCad (free open source)
I have attached a zip with the compiled gerber files aswell.
I will post the custom code later.
Cheers!
|
Show Posts