Registration Notice

Due to increased spam, forum registration must be manually approved by a moderator! Please see this post for instructions.

*

Offline LukeZ

  • 998
    • View Profile
  • France
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #30 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.


Quote
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?!
Barrettes_1.jpg
Heclo TCB Shield for Mega2560 Boards Barrettes_1.jpg
Views: 67
Barrettes_2.jpg
Heclo TCB Shield for Mega2560 Boards Barrettes_2.jpg
Views: 66
NO SUPPORT THROUGH PM - Read why
Need a forum account? Read here
Open Panzer FAQs

*

Offline JPS99

  • 25
    • View Profile
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #31 on: September 07, 2020, 04:53:29 PM »
Quote from: JPS99 link=topic=240.msg2488#msg2488 date=1599512813 The other thought that comes to mind is women's hair barrettes, but what are the odds they would be the right size?!
[/quote
Wow, that's thinking outside the box!  They would have to be fairly large, as what I've tried so far has been about 110mm X 12mm.
I'll check the local Dollar Stores to see if they have anything like that.
Thanks for the tip! (as well as the soldering guidance!)
Joe

*

Offline Heclo

  • 15
    • View Profile
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #32 on: September 08, 2020, 02:17:09 AM »
Quote
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.

Quote
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.

Quote
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!

Quote
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! :D
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

*

Offline LukeZ

  • 998
    • View Profile
  • France
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #33 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.
NO SUPPORT THROUGH PM - Read why
Need a forum account? Read here
Open Panzer FAQs

*

Offline Heclo

  • 15
    • View Profile
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #34 on: September 14, 2020, 03:16:52 AM »
Quote
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.
Code: [Select]
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...  :D

Quote
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  8)

Cheers Kim




*

Offline LukeZ

  • 998
    • View Profile
  • France
Re: Heclo TCB Shield for Mega2560 Boards
« Reply #35 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!
NO SUPPORT THROUGH PM - Read why
Need a forum account? Read here
Open Panzer FAQs

 

bomber-explosion