Why would you hold throttle and brake at the same time?
No idea, I just find weird. With a single level it’s easy to smoothly go from one to another
Guess its just practice
Would it be possible to have the brake lever reversed? Less prone for accidental braking. That way it also doesn’t have the pointy end pushing against your thumb.
Yeah, that’s an easy modification. Probably will keep both models though, for my hands the thumb rests very comfortably and the spring is stiff enough that a little deadband will prevent accidental presses.
Still think that @Pedrodemio has a point and implementing a “brake subtracts from throttle” control schema is worth exploring. Oh, the beauty of cooking things yourself, I’m gonna have a ton of fun with this xD
Seems like a similar situation as a car control.
I’ve never had this thought but I don’t think that’s how it works with my mtv2. I think once you press brake the throttle is canceled.
But yeah I’ve never had a situation where I was pressing both triggers at the same time
After riding with it for a while, it’s much better than a single trigger, where if you over extend on accident, you run into the brake.
As wonky as the first pic looked, you actually moving them makes it look better than I expected lol
Iterative design, baby!
This is nowhere near finished, but I like to validate stuff bit by bit and show the thought/prototyping progress. Also, I hate that aqua colored PLA and I’m not gonna miss it if I go through the whole spool just for this project
They’re here! Let me start with the good news:
PCBs work and I’ve validated 90% of the functionality.
- The LoRa module is properly soldered and secured.
- The power circuit is solid and confidence-inspiring. It draws basically no power when off and the button feel is very nice.
- I get very reliable and accurate measurements from the hall sensor, which has more than enough range for our purposes.
- 20 PCBs cost me about $60 (includind surface mount components and shipping), so if you factor in the Arduinos, sensors, plastic, battery/BMS and SX1280 modules we could be looking at a unit cost of a remote + receiver of less than $40*!
* this is just orientative based on very rough calculations. I have yet to make a proper BOM
Ok, as excited as I am, we have to address the elephant in the room. Why does the current prototype look so ugly? Well…mistakes were made. Very stupid, boneheaded mistakes:
- I manage to fuck up the spacing of the Arduino pins. How are you so stupid @thunkar? You may ask. Well, it’s my first time using KiCAD and I used an incorrect grid size, that’s how. I got it in there, which resulted in the Leaning Towers of Dissapointment as depicted below:
- I completely forgot the Arduino Pro minis that I’m running on the PCB work at 3.3V and not 5V. That means I cannot use the Arduino ADC to measure the remote’s battery voltage (in the range of 3.2-4.2V) and I have to use an external voltage divider (which I should use anyway to measure the thing against the internal voltage reference and not VCC, but I digress). A voltage divider with a big enough ratio can also be used in the receiver to measure board battery voltage up to a 12S (probably). Since I only have 4 LEDs, I don’t really need a lot of accuracy to distinguish between 25-50-75-100% charge.
- I need additional capacitance on the power on/off circuit for better reliability when turning it on (once on is rock solid though). A single 1uF capacitor suffices, as you can see externally soldered to the Arduino in the video.
- Since I have to make a new revision of the PCB, the vibration motor should have a proper transistor to be driven, @thunkar you lazy fuck (right now is again manually soldered under the Arduino)
- The footprint of the LoRa module is correct, but slightly bigger pads would help immensely when soldering.
- Silkscreen is free. For fuck’s sake why didn’t I label stuff properly? Tiny “+”, “s” and “-” signs would have made the assembly process a lot more straightforward.
- The Arduino reset button is dangerously placed and should be removed in the final version.
- The PCB could really use additional mounting holes that are not under the Arduino. This would allow me to directly solder it instead of using pinheaders and reduce the overall height of the stack.
- On the subject of height, low profile round pins will make it look a lot sleeker. Ordered a bunch.
To finish this update in a trully “shit sandwich” manner, I’ll add that these PCBs are not a total waste. Soldering the Arduino with pins slightly bent using a printed jig is possible, and since the receiver wasn’t going to use the mounting hole anyway, all of these 20 PCBs can become fully-featured receivers.
Thanks for joining the journey and I hope this info drop doesn’t play against your confidence in me and/or the project. I like to share what I learn as I go and in the end I believe it results in a better product.
Onwards and upwards!
Man you got to believe in art, that looks beautiful to me! Also triangular shape have great weight distribution so I’m sure the thing it’s very sturdy
Very cool update bro, things are going fast!
Thank you! I actually have what I hope will be version 1.0 of the PCB in the works, but I’m not ordering anything until I have simulated every subsystem using discrete components (since what I’m missing is just a couple of resistors, capacitors and a transistor). Then it’s software, ergonomics and testing.
Once that’s done, I believe I’ll have something sellable in my hands. Probably will do a poll on hoy many of you would like one assembled vs. DIY, thumbwheel, trigger, dual…
Most of the soldering will be done by JLCPCB, and the other critical part for safety is the hall sensor + magnet alignment. For the latter I have a few ideas that I hope will convince most people to ride a board powered by the Unfancy
I really appreciate you walking us through your process here.
Exciting work, can’t wait to get ahold of one of these!
Changed the orientation of the sensor and magnets, resulting in much easier and precise assembly:
Now the three of them are inserted vertically in a snug fit. A drop of superglue and they’re not going anywhere, ensuring alignment is always perfect:
Also lowered the profile of the Arduino on top of the PCB, getting ready to close this up (still waiting for the BMS though).
I’ve started implementing some more stuff on the software side, mainly calibration and centering for a smooth and linear range in both directions. Tomorrow is time for a proper mini scheduler that will allow me to time tasks and accurately set timeouts. Bye, bye library example code!
Looking good
Do you mean interrupts or something else?
this is super awesome I am actually hyped AF for this. @thunkar would you ever consider trying to shrink the PCB(s)? it would be wonderful to have this remote be as small as possible.
Stopping by to confirm; on my maytech, brake trigger overrides throttle completely. I think that’s very important. I use very high negative ramping time on my vesc settings as it simulates free roll; I wouldn’t do so it I couldn’t immediately cancel it out by tapping the brake. If the brake trigger doesn’t override the other one, I could not immediately brake with my settings, as far as I understand.
More like a simple task scheduling schema checking millis()
in the arduino code and making sure every part of the code runs at a reasonable rate (hall sensor sampling, package transmission, telemetry reception, battery voltage sampling…). Think of the blinkWithoutDelay
Arduino example, but with multiple tasks!
The obvious way to do this would be to develop a more tightly integrated PCB with the Atmega328p chip and BMS, but it would be more complex and something I’m not sure I can tackle at the moment. Also take into account that I’m limited to putting SMD components on just one side of the board so JLCPCB can assemble them for me. I can solder the boards by hand, but I am trying to avoid that as much as possible so anyone can order remotes without going through me or someone with specialized tools.
At any rate, I take it into consideration and will try my best for the final PCB
Noted, that control schema will definitely be implemented in the dual trigger version.