I am not suggesting that some "magic software" do the net connecting. I think getting the schematic to the right place, making the logical net connections and other corresponding design decisions, might be roughly analogous to the code merging you talk about. But there's still a lot of work to do in the layout and routing, which I think would be more analogous to compiling, and I think there is a very fundamental difference in the amount of magic software available to do compiling vs. auto placing and routing.
I don't personally do it, but more software-oriented people here tell me that merging more than 100 lines of code changes is normal and not at all a nightmare. On the other hand, adding a resistor to some of our hardware designs can be much harder, necessitating moving lots of other components and redoing a lot of routing and reevaluating integrity of things like polygon areas and current paths. It's more like making changes in a program written in assembly for a microcontroller that is already full.
Of course we can find cases in any domain where merging projects is difficult; the point is, when is it relatively easy and practical? On larger software projects, different people are merging hundreds of lines of changes many times a day and it's completely routine. I don't see anything equivalent to that happening in hardware projects; do you?
Are there even any examples of hardware projects that merge in changes from external contributors? Looking at something like Arduino, we can easily see tons of software merging history and none for the hardware side.
If you get two of the same battery, you will have double the energy of one battery, no matter how you arrange them. You do not get to double the voltage AND double the amp-hours, which would be quadrupling the energy stored. If you put the two batteries in series, you will get double the voltage and the same Ah; if you put the batteries in parallel, you will get the same voltage and double the Ah.
By the way, you should be very careful about putting various packs in series or parallel. Particularly in the parallel configuration, you are basically shorting together two batteries that are unlikely to have the exact same voltage. Lithium batteries are especially touchy about being correctly charged and discharged, so I strongly recommend getting a single pack that fits your application rather than trying to assemble your own large pack out of smaller batteries.
The hobby servos I wrote about in this article are not well suited for doing what you are asking for since they do not tell you the error. You can do something similar to the speed control I wrote about by picking a virtual set point and then sending your servo appropriate commands based on where you think the servo should be, having it move faster when farther from the point and slower when near that set point. However, this is all just an open-loop motion sequence you would be sending the servo, and depending on the resistance it encounters, the actual resulting movement can be completely different from what you intend.
If you are looking to effectively make your own servo by doing your own closed-loop control system, that is outside the scope of this article, and you should search online for things like "closed-loop motor control with Arduino" as there are many resources available.
You're missing the voltages of the batteries. It's hard to tell much without that. For instance, if your 6 Ah battery is 36 V and your 9 Ah battery is 24 V, they will both have the same capacity. If that were the case, your 9 Ah battery would indeed last longer, but you would be going a lot slower, for no net increase in range. This is is all assuming the bike would even go at 24 V. If both batteries are 36 V, the 9 Ah unit should give you about 50% more time and range. Keep in mind that in that case, the battery should also be about 50% bigger and heavier.
I am not saying *every* draft needs to be shared with every source. You, meanwhile, are advocating for the extreme of never allowing it.
Given that you are arguing for an extreme, it would be much more convincing if you actually argued for it instead of just saying "imagine if". It looks like you haven't even bothered to read much from those who disagree with you, who are not just imagining sharing drafts with sources but are actually executing the approach with success.
I think there are many issues that a journalist is just never going to understand that well. Plus, who do you think should judge when a journalist has gone "far enough to make sure they understand the concept they are trying to explain"?
Assuming the voltage is fairly constant during discharge, you can just divide the mWh number by the voltage to get mAh. So a 1.65V, 2500mWh NiZn cell is probably going to give you about 1500 mAh (and the energy stored would be similar to that of a 1.2V, 2000mAh NiMH cell).
I do not quite understand what you are asking, but I suspect continuous rotation servos, which are not particularly high performance motors, are unlikely to be appropriate for inverted pendulum applications or for retrofitting with encoders.
The 20 mAh low end is probably because the charger cannot get the charge current low enough to charge the battery safely. I am not sure about the 100 mAh upper limit; are you sure that is not a mistake? Maybe that's a typo and it's supposed to be something like 100 Ah, though that sounds a little high (that would take almost 24 hours to charge with the 6A limit, plus 100 Ah is a pretty big battery).
Thank you for continuing to push on this. I've seen that Melexis sensor before, but I think the magnet for the AMS sensor should be pretty simple to make (and we're already working on it), so I suspect that will be the easier route.
As for your performance calculations, I definitely agree that 12 CPR is lacking if you want decent resolution per millisecond. We are targeting 8-bit MCUs with no special quadrature decoding hardware, and I think these 12-24 CPR units are very well matched to that. It's definitely good to hear from customers pushing for more, and we are aware that much better MCUs that can deal with high frequency quadrature are getting more and more available.