@@TheDigitalMermaid By the way, my alter-ego just left a proposal for a possible improvement on your github repo. I'll see if I find time to play with the code a bit...
So, funny story... Years ago, I got a nice laptop and decided to get accidental damage coverage. Well, sure enough I knocked a drink over. I called Lenovo and said "To confirm, the accidental damage warranty me being a dumb ass, right?". Dude laughed, said yup, and sent out a replacement keyboard. :)
Awesome engineering. Well done. Consider safety and I’m sure you will. Albeit you are testing, As you were flipping and clicking the switches, you had the throttle at full. I believe it would be useful to program some “if then else” statements around if the throttle is > 02.5v don’t engage motor etc. Murphy will bite you if you know what I mean. Keep up the good work. You inspire me
A basic question one should always ask - is my 5V actually 5V? I think Andrew has probably mentioned this, but those DACs are outputting proportional to their 5V power rail. I noticed all your outputs were a little higher than one would expect if that was truly 5.0V - 2.57V with a DAC value of 2048 for example, which should have been exactly 2.5V. I don’t know what you’re using as a 5V power supply for those (I suspect a USB supply, and they’re often 5.2 or even higher, like 5.35V). This means when you move it to the boat with a different 5V supply, all of these calibrations will be off. I’d highly recommend using a more accurate (or at least repeatable) 5V supply so that doesn’t change. The ADC pot readings don’t have the same issue - they’re always ratiometric based on the STM32’s 3.3V rail, so no calibration issue there. Also, the motor controllers generally output their own 5V rail for use with potentiometers, and they’ll be responding to voltages which are ratiometric to that 5V, so ideally your DACs would run directly off that rail rather than a different one which would introduce a scaling error. Sorry for the long comment, but I hope this helps… ;-)
Oooooooh, that's a very very good reason to use the controller's 5v as reference. I hadn't thought of that letting everything be relative in the controller's logic. Thanks!
As an EE who has done embedded development since assembly was the big deal, Arduino simplifies things insanely. Going to bare metal code (as you are on the STM32) is MUCH more powerful, somewhat more complex, and infinitely more configurable. There is a workflow for CubeMX and STM32 development that makes the process go a little smoother. I'll see if I can find a copy I can send you.
Thanks, @mausball! I used STM32 Cube MX to get the initial setup working, actually. I've made enough changes that I'm reluctant to let it edit my working directory directly now, but I export changes to another directory and then use 'meld' to merge the changed.
Very entertaining video, no need to worry about that! As someone that's also figuring out embedded programming (recently finished my first project woohoo, I built my own button box/controller for my PC to play games on), this is wildly entertaining and interesting to follow along with to me! Looking forward to the next one already!
Oh, it's 100% addictive. I am a full-blown addict. However, though this addiction can leave you equally broke, at least it doesn't end up with you arrested or dead in a bathtub, so yay?
Something to consider when using EPROM chips is this. SRAM is cheap and has lots of write cycles so it's better to write all the volatile data to those. With the EPROM data it would be better to simply require the throttle lever to be set to neutral before it can become active. That leaves zero writes to the EPROM while in use. From there all the active reads and writes come from SRAM and you only have to write default settings to the EPROM to be loaded at startup.
The Kelly controller itself requires the throttle to be in neutral when it powers up, likely for exactly that reason. I am curious now... If the power comes up on the Kelly controller and my board at the same time, will my board's throttle DAC have already ramped up before the controller checks? Hrm, I need to think about this more.
You are amazing. You have the persistence coupled with the intelligence and raw education needed to be super successful. I love watching your videos because they expose your passion and intelligence while also serving as education for knuckleheads like me. Keep on charging. You'll be sailing soon.
Digi you make this stuff entertaining. your enthusiasm, your personality. It's very easy to watch. I would go so far as to say endearing. Good luck with your progress and I'm glad to see that you're going to get your boat in the water this year. Can't say I'm not a little jealous.
@@TheDigitalMermaid oh it's coming along. I just got into some things that didn't need to be necessarily dealt with right now, but because the boat is already opened up and torn apart it made sense to go after the stringers and the floors. It would be more difficult to get them after I put it back together. They're a little soft. They'd be good for years, but while it's easy to get them, I figured I'd get in there and do the job. Basically I'm building a new boat
"fine scruv you" that made me smile :-) mlost of what you said in this video was lost on me, my understanding of programming is almost limited to " it is about zoeros and ones, but stil find the porces of you finding out what too do worth my time. I might be a bit strange. As siad before, looking forward to more videos frome you.
Interesting approach to use multiple throttles. Ever thought about using a bus like NMEA 2000 or CAN to connect the controls to the "brain"? That would allow even more controls and emegency backups.
@TheDigitalMermaid your welcome it's nice to see and watch ur vids so informative I'm mainly in for the battery side but the rest is really interesting I live on a boat myself well a dutch barge anyway
Be careful with I2C bus implemenmtation. I have done several I2C bus debugging projects and there are several things to keep in mind. Signal integrity: Keep busses short. Keep all devices on the same ground plane Use guard traces when near other signals. Have return (ground) traces/wires running parallel and close to the bus lines if you have to cross boards or boxes. Fault protection: Glitches noise or other nasties can cause the controller and peripheral device to get out of sync. Then the peripheral can hang the bus by pulling a bus line low. (even the Clock line since peripherals can pull the clock low for clock stretching) Use a watchdog timer or other means of detecting a stuck or otherwise non-responsive peripheral device. This can then try to reset the bus and and set and log some error condition/message. Ideally the controller should be able to cycle power on the peripheral devices. Thank you for your energy, enthusiasm and all that you do in this series. Keep up the great work.
Great work getting it up and running! Embedded systems can be a deep pool to go wading in and you're doing an incredible job making it approachable and accessible! If you'd like them, two suggestions you might consider to simplify things: The datasheet for the DAC you're using mentions that you can order ones with up to 8 different addresses (section 7.2 of the datasheet). It might be worth seeing if you could get ahold of ones with a slightly different configuration to simplify your firmware and wiring a bit. Another option down the same vein would be to look at a slightly different stm32 series. From what I remember the STM32G4 has more than 4 DAC channels built in, as well as some neat safety features around program memory and analog inputs that you might find helpful as you get your helm put together to minimize complexity & opportunities for murphy.
Aye, at some point, I'll be getting a proper PCB made, and when I do a lot more options come on the table. For this build, the stm32 nucleo I have is a spare Andrew has that he kindly donated to get me started. Using a DAC that can have 4+ addresses would free up four pins on the stm32 I could use for the extra LCD page select switches I want to have (two input pins per LCD, for pg-up/down). I also need to add things like key switch pins, etc. For now though, it's all about getting to a minimum viable product as safely as I can with the hardware I've got. :)
Makes complete sense, and the F0 is a solid little part! I've got product out in the wild on a slightly larger variant of it. Lots of little features you never knew you wanted until you're up a creek and they bail you out. Since you're still pushing towards MVP it might be a little early to look towards reliability & safety on the firmware side, but I'm happy to take a look if you'd like and make some suggestions.
You may want to consider including a momentary switch to interrupt power to the brain in case it needs to be reset. That or a secondary brain that you can switch over to. You can put diodes on all the output pins to make sure that the brains don't accidentally mess with each other if one of the brains goes short
Adding a reboot switch is not a bad idea. There's already one on the Nucleo board, so running a physical switch up to the dash isn't a bad idea. I don't think I'll have a hot-swap board (that's a LOT more complexity), but I absolutely will have backups onboard.
About dashboard design, when we were sailing from Canada to NZ, we experienced fairly rough seas. I needed the pedestal just to stand up in the cockpit, and standing was pretty tiring. So keep pedestal handholds in mind and try to keep the compass, at least, visible from a seated position.
This is a very very very good point, and thank you for it! I'll make a point to add hand holds around the helm box. Curious; I had planned to add a GPS-based compass as well as the magnetic one, with the GPS-based one on a display somewhere near the companionway (along with the SOG, depth, etc). In your experience, do you think, with that, it's still important to have the mechanical compass down low? If so, I'll keep it in mind to lower (or make the whole helm box be able to be lowered).
@@TheDigitalMermaid @denisebbrooks4513 Good point i had some thoughts too seeing the pedestal plans. The time you actually steer is reduced to inland, coastal, approach and leaving. At sea you just overwatch workings of autopilot/hydrovane course, ais, so - 80-90% you are not steering at all, - 98% you will do that from a sitting or (half)lying position. Tucked half under the sprayhood, on deck or below. - your sail boat is very happy at an 15-30 degree angle. But you won't. And want to stand straight vertical regardless of the angle angle. A high pedestal at 30degrees will stick out and be in your way. Since you tend to move on the lower side in the cockpit, on deck on the higher side (which is not a good thing anyway if you fall in) you want to make sure you still can pass and move freely. - For the fun of it :)) i call the setup the "Nordic Walking" 2 throttle handle set up:) Can you imagine that the handles sticking out pose a risk when under 30 degree tilt and you want to pass it? Same goes for reefing /spinaker lines that are far back. - Even in a snagging safe position A mechanical blocked neutral position seems mandatory. A trip to the boat, and a coffee, find your nicest spots to sit, ly hang around and go from there. then the info you want there. in good weather for a position for sliding in an green blue atol and bad weather and nasty waves rounding Madagascar. A well thought over setup will greatly enhance boat handling and reduces stress and fatigue.
I don't quite understand the need of saving space, you could just buy balling MCU with enough memory to run everything, it's not like you will be making hundreds of those devices and need to save every penny. Heck, I'd probably just use Micropython on some overpowered MCU to ease development.
I thought about this earlier on, but decided I'd need a minimum of three, so I could discard the outlier. Otherwise, if the two pots reported different values, how to know which is "more" correct? In the end, a selector switch to swap active pots seems like a good way to solve it, as it leaves the helmsperson to decide which they prefer.
Cars with throttle by wire (many in the last 20 years) and electric cars have a nice accelerator pedal module that has two pots for redundancy and well made, durable mechanicals. A visit to a local automotive recycler (junkyard) should get you a couple for not much $(C). Then you could modify to remove the return spring and make a more appropriate handle.
Please think of inductive and other coupling into your wires, when controlling your motor with voltages. When the wires are long enough, they turn into antennas and will probably gather some radiation from smartphones and so on. This can lead to voltage spikes on the wires. I don't know how fast your motor controller reacts, so configuring it to be a little bit sluggish is a good idea. I am not a native speaker, please do not hesitate to ask, if something is unclear.
Danke, Bruseidon! Ich freue mich wirklich darauf, dass das alles bei beiden Motoren zum Laufen kommt. Es wird wirklich befriedigend sein, einen Schalter umzulegen und zu sehen, wie sich der aktive Motor ändert. :D
so a lot of things like hitting the port directly are also quite possible in the Arduino/avr ecosystem in fact you can get some notable performance improvements by hitting the ports directly (and if you don't use the helper functions they don't get compiled in) and you can also use the stm32 under the Arduino ecosystem since the ecosystem is extensible which is probably one of it's biggest boons. For i2c, if you want to reduce i/o usage even more there are i2c multiplexers designed for exactly this kind of use case they basically sit on an address, wait for a port number and then send any i2c traffic after that to the given port, the PCA9546A and PCA9546 are pretty common 4 port multiplexers.
I've looked a bit at multiplexors, as I suspect I'll run low on pins when I try to add 2 or 3 more LCDs. For now though, I'm aiming for the minimum viable product so that I can get in the water and start sea trials. Come fall/winter, hopefully I'll be able to come back and start adding nice-to-haves.
HOWdy T-D-M, ... Hi Madi ... is it me ? or were you out of FOCUS on this INTRO ? LOL ... Glad to see you = I have not had time to WATCH this VIDEO for a couple of DAZE ! Glad you are alive & well & PROGRESSING Hugz COOP the WiSeNhEiMeR from Richmond, INDIANA ...
Whatever you do ... make it modular and have atleast 2 backup Brains which you can quickly swap out incase one fails for whatever reason. Have your final circuit fuse and zener diode protected for over voltages.
I will, because I'm paranoid. That said, it's worth reflecting how few other boats on the water have backup MFDs, redundant throttles, redundant motors, etc. Especially in a monohull the size of mine. So of course I'll have as much redundancy and spares as possible, but I think I'll already have way more than most. :)
Since you at the beginning of your boat project think about using a trolling motor and prop on a long shaft on the bow for slow maneuvering in tight spots.
I've had other folks suggest this, but given the electric motor should be fairly (mechanically) reliable, I'm not toooo concerned. If I had more time, I'd love to do the dinghy outboard conversion and have it as a backup for just this reason, but alas... I don't.
Great video as always, I have to go back and watch the last one- must have missed it, but why do you have 2 motors now? As a quality-of-life (optional) nuance for throttle control. -- Consider using a "exponential" mapping of the throttle position to the power level (rather than linear). This allows 0=0 and 100% =100% , but it makes it smooth and lots of throw for slow speed and then ramps u fast in the high power level. this is most useful in Marians when you need to control speed carefully. This might already be built into a controller. The result (depending on how aggressive you make it) is that the first 1/2 of the leaver movement controls the first 1/4 of the power and the second 1/2 of the moment contains about 3/4 of power. wish I could explain it better but basically it gives you "fine control" at low power, and course control at high power.
I got into detail on the two motors in Ep. 86, at 23:07. In short; Low-speed efficiency of the 5kw is markedly higher than the 10kw. Also, redundancy. I have thought about the exponential throttle, and I quite like the idea. It's something I'll need to learn how to do, but I can see implementing that after I'm on the water and have cycles for QOL tasks.
@@TheDigitalMermaid You can try it in Excel, on a cell you put your G value for the exponential correction (start with 1), then make two columns (X, Y) on X you put values from 0 to 1 (0.1 0.2 ....) on Y you put the formula ((X/max(X))^G)*max(X) where: X is the input value max(X) is the maximum input value you expect (in this case 1 but works with bigger integers too) G is the gamma correction factor (1 is linear, and over or under has an exponential correction). Make an X, Y plot and play with the G value.
In light of the fact that spending someone else's money is _the_ best fun, I'll fire the idea of using the throttle lever to move the shaft of a stepper motor with an encoder on it across your bow. That way you get digital values of throttle position directly, and you can use the stepper on the other throttle quadrant to keep the levers in sync.
You are aware that if the supply voltage (5V) changes even a bit that the values u just spent a while calibrating are useless. At least if the dacs work like I thing they work. So watch out for that.
I'd certainly recommend using a lower voltage reference or regulator to get a stable ADC reference. I use a tl431 as my base line 2.5v reference for all projects and they only cost a few pennies. Actual voltage is irrelevant as we only care about absolute stability.
Aye, this is true, I realized that after I mistakenly connected the source voltage to the 3.3v source instead of the 5v. I really need to sacrifice some input pins and write a tool to auto-calibrate, but that's a down-the-road feature.
enjoying your journey and wish you well, static electricity dot know if you get it on a boat, and electromagnetic storms can kill chips I remember in previous video you mentioned someone helping with the electronics bit it may be worth exploring some protection at the board connecters like TVS Diodes. Just a thought
When I get the final PCB made, I'll make a box that protects against electrical noise / shields to ground. The power to the helm will come from the propulsion bank, also, so as long as the motors have power, so will the helm. :)
I would see it as a helping mate. Let it check your code, and ask if it could improve it. You learn esp32 and ai in one go haha. Its really amazing what it can do. Not perfect but its got a hell of a lot of nowledge, available in a few seconds.
I don’t know if anybody already mentioned it, but why not just use an i2c multiplexer / switcher ic? The trick with the io pins for dynamic address selection sounds really hacky
You are right, the Arduino libs make life a lot easier. I however get the impression that you underestimate it's power though. E.g. there are arduino boards that support DMA as well, and you are by no means limited to one file. There are other IDEs out there than the arduino ide, e.g. platformio, that work better for complex projects. Stm32 can be programmed with arduino API as well. And you can mix and match, so if the native interface is more powerful, you can always use that. That's what I often do with esp32 and the native espressif API.
Consider Plexiglass helm panel to mount throttle and switches. Must stay organized. That way you don’t waste time trying to figure out what switch does what. Know what I mean?
Your Oscilloscope is more accurate, The only thing is that now you have the addition of time and that now involve frequency; PWM [Pulse With Modulation]. You'll will be fine. I'll come to you. But both meters need to read if you are connecting to the same output. Just me humble guess. I depth finder would be nice at the helm to.
I'm planning to learn PWM soon to drive the (many!) LEDs I plan to have on the dash. The scope is so much more powerful than a normal meter, I just need to get over it's learning curve, also.
I had one of my potentiometers fail just as I entered a Marina. Luckily I got to the kill switch and also had the outboard running so managed to stop before hitting a wall with my rudders. I'm going to hall effect controls
I know you're in development, so this may not be a useful suggestion, but I wonder if mounting the controls to a board and labeling them would help you avoid using the wrong ones. It might also give you an idea if you have the controls you want/need. I know when I'm working on something complicated, a test app helps and so a test set of controls might be useful. Plus it would just be cool to have a helm mockup.
Aye, I've considered this using cardboard actually, but so far it's all I could do to stay focused on the helm dev itself. I will mock up the dash though, before making it in wood.
Mandy it concerns me you having two throttles that could be in totally different positions, e.g. one at full and one at zero. One switch mistake/accident and you go full throttle. Please manually connect these two throttle together with a common bearing bar. So a mechanical movement in one is translated to the other.
Given future plans, that wouldn't make sense (unless I also connected to bar to a motor). I'm not toooo concerned given the ramping algorithm (mine and the one in the Kelly controller), and how easy it would be to correct if it did happen.
Would it not have been easier to use an ESP32-XX and writing the code in micro-python? Enjoy your videos and look forward to you getting back in the water.
There's many ways to get to the same goal, I fully admit. I do still want to learn ESP for wireless functions I plan to add, but at the moment, I've been focused on the minimum viable product to get in the water. The STM32 Cube MX made the initialization of the STM32 easier (at least with the level of knowledge I had at the start) than the ESP32.
@@JGnLAU8OAWF6 ABYC standards require the helm to be fully functional within 5 seconds of powering on. I don't think an Rpi is fast enough for the helm itself. I will be adding Rpis though, later.
@@TheDigitalMermaid Yes, the STM Cube (MX) software suite, depending on the STM32 chip type, allows you to do software debug (SWD) and thus also allows for live variable debugging/breakpoints etc. Everything you love from other programming languages and IDEs
I've actually got that ESP32 protoboard specifically for wireless. I've got some extensions to the project planned. I started with the STM32 first given it's a simpler (older, more stable) dev platform for the core safety stuff, and the esp32 will be fore the nicer features. Also, STM32 Cube MX took some of the edge off the already-steep learning curve.
You probably said and I missed it, and clearly you've mastered the STM, so no reason to change gears now... but why did you reject the ESP32? There must have been some interesting fundamental reason. Also two controllers, two motors, one brain... why not two brains? STMs are cheap, and pins on chips fail.
Very kind of you, but I assuredly am FAR from mastering STM32, or anything else embedded for that matter. :) As for why I chose the STM32 for this stage, it's because my friend Andrew, who's been helping me through all this, advised it's a simpler / more stable option, and so better for core safety-critical systems like the helm control. I already have the STM32 as I plan to use it later to add some quality of life features that will be less safety-critical.
Oh, and the "one brain" part is because I wanted to be able to run either throttle to either motor, and that seemed to be easier to do with a single brain. I certainly will have spare/backup controllers for quick replacement later.
Hi again, I wonder could you give chat gpt 4o a try. It the latest version. You could just talk to it and ask for help wit the code you're working on. Just saw a demo and it's amazing.
The concern with anything like GPT is that it can confidently and convincingly give you the wrong answer. Also, and perhaps more importantly, I am doing this as much to learn as I am to get the end result. So the process of learning to do it myself is a goal itself.
