• Welcome to Jetboaters.net!

    We are delighted you have found your way to the best Jet Boaters Forum on the internet! Please consider Signing Up so that you can enjoy all the features and offers on the forum. We have members with boats from all the major manufacturers including Yamaha, Seadoo, Scarab and Chaparral. We don't email you SPAM, and the site is totally non-commercial. So what's to lose? IT IS FREE!

    Membership allows you to ask questions (no matter how mundane), meet up with other jet boaters, see full images (not just thumbnails), browse the member map and qualifies you for members only discounts offered by vendors who run specials for our members only! (It also gets rid of this banner!)

    free hit counter

DIY GPS Speed Control Project

Wow awesome job Chris! Thanks for the read and just wow I can understand what you're posting but no means capable of duplicating much respect to your skills.
 
Don't give up yet!! You need to add an integrator to your control loop. Without an integrator, by definition, you cannot achieve zero steady state error. Your speed will also tend to be "underdamped" -- like a car with bad shocks. I paid a lot of money to learn that in college and you got to discover it while doing a cool project on your boat. :thumbsup: Most control loops are PI (Proportional - Integral). The proportional gain controls how quickly your system responds and the integrator helps smooth out the error. Feedback control loops can be difficult to tune, but don't give up.

On another note, I know the PP in my SX230 only monitors the RPM on one engine. It doesn't control the second engine, it applies the same throttle adjustments on the second that it does to the first. So, you are not at a disadvantage with respect to PP.

Apologies if you already know all this, I'm sure there are others on the board that can learn something from it.

Cheers,
Steve
 
@YamahaForMe - Thanks for jumping in on this. I must say that I don't know much about what you are referring to in those terms which may be enough to say that I was destined to fail but let me clarify a few things. I was not communicating directly with the ecu as that could get dicey with another multiprotocol read write device already on the network. Instead I just mimicked existing hard buttons on the N2K network knowing that I could not hurt anything that way.

By smooth I meant two things. I did initially get fairly smooth speed but the engines were bouncing up and down by 200 rpm multiple times every second because that is the built in step for the cruise control buttons. The sound of this happening that often is very annoying and made the boat feel jerky even though the speed was relatively smooth. I am sure that it may not be good for other reasons as well. That is why I played with other variables to try and find something that would work.

Reaction to the commands I was sending was ~0.10 seconds and my algorithm accounted for current speed, angle of turn, and predicted speed increase/decrease based upon the last 1 second of speed curve. (perhaps this is what you are referring to)?

I will admit that I had to do a bit of reading to figure this all out. I am a data and quant guy in the financial arena so I had to teach myself NMEA but it was not too hard having already understood other canbus systems. I already knew how to read gps data from other hobby projects I have worked on. So basically keep in mind most of electronics knowledge is hobby based.

I truly believe that with the method I tried there is absolutely no getting around the 200 rpm steps as that is built into the ecu firmware for the cruise control buttons. If you still think I missed something that matters in a boat pulling a skier I would love to chat.

Chris
 
OK, I want to state for the record that I am no expert on this topic. I have dabbled in it in college 25 years ago, and am barely exposed to it in my job (aerospace electrical power generation and distribution systems).

I do remember a few things and will try to offer some help. We may be in over our heads.

Clarification: Steady State error. This is the difference between the desired speed and the actual speed after the system stabilizes from a disturbance.

A closed loop controller (which you have because you use GPS speed as a feedback reference when choosing your throttle "bump" command), will naturally have a cyclical error because of over-correction. As the controller increases the speed command, there is a delay before the system(boat) responds. This results in the controller commanding more speed than needed, overshooting. Then it reduces the speed command and winds up undershooting. Then it overshoots, undershoots, overshoots, undershoots, etc. If the system is "stable" then the over/under shoots get smaller and smaller until it hits a steady state.

You can keep your overall gain low, resulting in low steady state error. However this means that your system will respond extremely slowly to disturbance from desired speed.... not necessarily what we want. We can mathematically eliminate steady state error by introducing an integrator into the algorithm. An integrator can be thought of as a time history of the error. Note that an integrator also slows system response time.

So how do we implement an integrator into your system? I haven't a clue. I am having trouble wrapping my mind around the fact that your speed control command is an RPM increase or RPM decrease command. I will put some more thought into it, but now its time for sleep.

Steve
 
I had started building a boat speed control system earlier this year using an Arduino as well. I never got close to installing it in the boat. It was just a prototype and I was focusing on the software, with the primary challenge of getting the PID controller setup with some tunables so I could get it working properly with the boat. I had high hopes that it would work decently well with ~200rpm granularity in the throttle.
 
@YamahaForMe -

Steve - Thanks for your input. You certainly have the correct terms where I do not and I am sure I could learn a lot from you. You are spot on with the over correction occurring. This is a result of 200 rpm steps. I assume an integrator uses a predicative model. I could certainly create a predicative model in fact by examining the actual speed curve over the last second and rate of turn I have a fairly simple one already. Of course I could bump that to 10 seconds but I think you are referring to using the observed delta and other variables over a long history of previous runs. What I think I will run into though is all of the other variables that will affect speed that would require inputs prior to a given run. These would include people weight, water ballast, fuel weight, ambient temperature, relative humidity, elevation, water temperature, skier weight, skier aggressiveness, windspeed, wind direction relative to the boat course, beer weight, and so forth.

Currently the target speed is set once the target speed is reached by the user observing the target speed from the built in boat GPS speedometer and then pressing and holding the cancel button. This means we are starting from a somewhat steady state. I am able to read in GPS speed into my micro controller every tenth of a second and it take less than a tenth of a second for it to compute wether or not to bump the rpms up or down by one or two 200 rpm steps. The boat recognizes this and reacts in less than a tenth of a second once the command is sent. So the loop delay is less than 0.2 seconds. The boat then takes time to get to it fully realized speed correction but of course the skier is still impacting that. I have also found that when manually controlling speed when towing a wakeboarder it is harder at 18 mph then at 20 mph because of the natural planning speed of the hull. This will matter when there is more chop in the water as I want 20-21 mph on glass but 18 mph when conditions are not ideal.

I really want this to work. The idea of having a one plug and done system for under 100 bucks in parts is great in theory. Perhaps it is even possible if instead of using the built in rpm steps ( I still think this is something that can't be fully accounted for without some sort of annoyance in operation) someone could figure out the commands to send directly over the engine can bus to regulate the rpms without using the cruise control steps (Not something I want to try spending the time on as I think that would be far more difficult to figure out never mind that would almost certainly void the warranty on the engine ecus and the motors). I know it is theoretically possible as the e and x series throttles are just potentiometers that send control voltages to a independent control unit that then interprets the control voltage into an command to send to the ECU (my opinion based upon the wiring diagrams and parts listings available online). The I/O on the ECU from the wiring diagrams is certainly different and possible the firmware in the ECU as well.

As previously mentioned I have no doubt that I could clone the perfect pass method to overcome the 200 rom steps but would have to fabricate the bracket system on top of figuring out a whole bunch of code and the cost of the parts would easily exceed $300. Even if I bought the brackets from perfect pass I am still looking at a boat load of time to get it all working even just using a set button without a display. Perfect Pass of course allows the user to enter a target speed prior to starting the run get the boat up to a certain rpm and then it takes over. This is better and in order to do that some method of input prior to the run would be needed such as a smartphone but a dedicated water proof lcd and a couple of buttons is better in my opinion. So in the end that is a whole lot of development time and for arguments sake lets say my time is worth only $1 a minute. Even at that rate the time alone would cost me more than just buying a system that is fully ready to go. I bought the boat to enjoy my time and while this is could be a fun project for someone I just don't want to put my time towards it anymore (1 wife, 3 teenage kids, 1 dog, 2 cats, relocating next year, etc). I need a working system by next spring and testing is out of the question with my boat shrink wrapped for the winter.

If you want to give this a try I can point you in the right direction and I bet you could get to the same point I did or further. I won't just deliver the project in its current state though as I am very timid about any perceived gain in something that is patented. This also means I won't give any explicit or implicit advice/directions when it comes to the finer details.

I really do appreciate you input Steve, and perhaps if we connected earlier on I would not be giving up on it. Perhaps we can connect on this or another project someday. Feel free to pm me if you would like to connect further.

On another topic .. I am jealous of what you do for a living and I bet you could give great advice on a lot of different questions/projects here. Granted don't need to reinvent the wheel on 12vdc but you must know your stuff.

Chris
 
@Spooling - Should be easier on your model for the coding as you can just use the analog or digital out pins to mimic the analog cruise control button on your boat model and year. In your case I would go with a mega board and a GPS module with separate antenna lead for the hardware. A due board would work but is overkill in your case and of course is no longer supported very well. There are libraries and sketch examples out there of how to just read in speed and rate of turn. There is not much though on how to process that from there but in general think loop and keep the code efficient for the cpu. I had to create my own library code/files but you should be able to get away without having to do that. Good luck and hopefully you get it working better than I did.
 
This is an interesting topic. I had this same idea this last weekend after having my wife pull me wakeboarding on my 2017 ar210. My speed varied between 18-27 mph.

On my boat, the throttle levers have cables back to the engine compartment, then it looks like it converts to digital signal before it goes to the engines.

I have the cruise assist buttons that I use when i'm pulling skiers/ wakeboarders. My thought was to set the throttles to get pretty close to the speed to be maintained, then have a device automatically bump up / down the cruise assist to maintain speed.

It looks like that's exactly what's being attempted /done in this thread. I think that the 200rpm resolution is sufficient, as when I'm doing that manually I can keep a pretty even speed. Also, for my needs +/- 1 MPH should be plenty.

My thoughts were similar to mainah's solution. Get an arduino that reads the speed from GPS. Then, have it bump up or down the cruise assist automatically. I am thinking that a PID controller should help to prevent too frequent or unnecessary changes in RPM ( i've played a bit with this with balancing robots and quadcopters). Also, with the boat the change in speed is pretty slow after bumping the cruise assist. It may take a second or two before seeing what happens as a result of bumping the throttle.

I guess my main question is: Is the cruise assist button just a simple button press, like one that could be easily simulated with an arduino, or is it a data bus that requires communication on some kind of protocol.
 
This is an interesting topic. I had this same idea this last weekend after having my wife pull me wakeboarding on my 2017 ar210. My speed varied between 18-27 mph.

On my boat, the throttle levers have cables back to the engine compartment, then it looks like it converts to digital signal before it goes to the engines.

I have the cruise assist buttons that I use when i'm pulling skiers/ wakeboarders. My thought was to set the throttles to get pretty close to the speed to be maintained, then have a device automatically bump up / down the cruise assist to maintain speed.

It looks like that's exactly what's being attempted /done in this thread. I think that the 200rpm resolution is sufficient, as when I'm doing that manually I can keep a pretty even speed. Also, for my needs +/- 1 MPH should be plenty.

My thoughts were similar to mainah's solution. Get an arduino that reads the speed from GPS. Then, have it bump up or down the cruise assist automatically. I am thinking that a PID controller should help to prevent too frequent or unnecessary changes in RPM ( i've played a bit with this with balancing robots and quadcopters). Also, with the boat the change in speed is pretty slow after bumping the cruise assist. It may take a second or two before seeing what happens as a result of bumping the throttle.

I guess my main question is: Is the cruise assist button just a simple button press, like one that could be easily simulated with an arduino, or is it a data bus that requires communication on some kind of protocol.


Connext uses a N2K data bus using proprietary pgns. Actually Connext connects a few network protocols together which is perhaps what inspired its name. Here is a post I did on what I sniffed out from the joystick on the N2k network https://jetboaters.net/threads/connext-joystick-nmea-info.11513/. 200 rpm steps are sufficient to get decent control but it becomes a compounding issue depending on refresh rate, variation allowance, rate of turn, what the boarder is doing behind the boat etc. The engine jumping up and down 200 rpms 10 times per second or more is annoying. I am sure a suitable algorithm could be coded to get to something better than what I did. I ran out of time at the end of last season before having to wrap my boat for the winter season in Maine (now live in SC). My goal was to get to something very smooth and I never achieved that. I simply could not justify spending more time on it with off the shelf products available. I now have ride steady and can say that it works very well. With a nearly 10x improvement in resolution and a independent/dedicated control system it is will always work better than injecting commands into an existing network. That said for someone with the right skillset looking to save some money and is ok with it not being as smooth as other products out there than this may be a viable substitute given the right amount of dedication and time. For someone with the right skill set and a non-connext boat with the rpm cruise control this is easier as that is just an analog switch and no need to worry about the can bus issues.
 
My screen says Connext when it boots up, but the Cruise Assist is just a rocker switch. So I'm wondering if it's just a simple button press (alteast on the ar210 anyway).

Why would you adjust the RPM's 10x per second? Why not only make an adjustment like once every 1-2 seconds? I'm just thinking that manually I only make an adjustment every 2-5 seconds and see what happens before I make another adjustment.
 
There is no other system for these boats?
 
Perfect Pass and Ride Steady are off the shelf solutions. Both $1200+
 
@seabass2020 If just a rocker switch then you don't have to worry about the whole N2k thing. On 24 foot connext boats the rpm cruise is handled by the joystick buttons which are n2k interface but it sounds like that is not the case for you. The issue with refresh rate and the 200 rpm steps is compounded because the load is dynamic. The longer berween the refreshes the more correction may be needed and recovery will take longer making it a bit jerky.

It sounds like you have the skillset to tackle this. I started with allowing a 5% tolerance from set speed as that allows a 1mph up or down from with a total of 2 mph difference and I did not like that. I got fancier from there and then found an issue comes into play when the set speed is best achieved in the middle of the 200 rpm band. IMO a fast refesh rate with a tine tolerance delta is the best way to acheive the beat performance but when you are dealing with large steps it becomes annoying. Algorithms or a whole bunch of if staments in a loop can help with a lack of resolution.

If you tackle this I wish you good luck and more success than I had. Just don't forget to code in some safety like if delta from set speed variable greater than 20% then cancel.
 
@seabass2020 If just a rocker switch then you don't have to worry about the whole N2k thing. On 24 foot connext boats the rpm cruise is handled by the joystick buttons which are n2k interface but it sounds like that is not the case for you. The issue with refresh rate and the 200 rpm steps is compounded because the load is dynamic. The longer berween the refreshes the more correction may be needed and recovery will take longer making it a bit jerky.

It sounds like you have the skillset to tackle this. I started with allowing a 5% tolerance from set speed as that allows a 1mph up or down from with a total of 2 mph difference and I did not like that. I got fancier from there and then found an issue comes into play when the set speed is best achieved in the middle of the 200 rpm band. IMO a fast refesh rate with a tine tolerance delta is the best way to acheive the beat performance but when you are dealing with large steps it becomes annoying. Algorithms or a whole bunch of if staments in a loop can help with a lack of resolution.

If you tackle this I wish you good luck and more success than I had. Just don't forget to code in some safety like if delta from set speed variable greater than 20% then cancel.

Well, thanks man for the information. I may play around with this a bit and see how it goes. Probably the first thing is dig into that rocker switch and see how it's hooked up. Just curious, and unrelated to my install, but how did you listen in to the connext protocol?
 
Well, thanks man for the information. I may play around with this a bit and see how it goes. Probably the first thing is dig into that rocker switch and see how it's hooked up. Just curious, and unrelated to my install, but how did you listen in to the connext protocol?

On the hardware side I used an Arduino mega, can bus shield and a mcp chip on a breadboard. I then pointed actisense software at the terminal ouput. Once output it was a matter of watching the hex state change over the network on my laptop on each broadcasted PGN when I made human inputs on the joystick.
 
On the hardware side I used an Arduino mega, can bus shield and a mcp chip on a breadboard. I then pointed actisense software at the terminal ouput. Once output it was a matter of watching the hex state change over the network on my laptop on each broadcasted PGN when I made human inputs on the joystick.

Yeah, what he said. . . .
 
Back
Top