A wild stab in the dark, but is the controller trying to calibrate itself here ?
Differences in the vehicle’s setup vs the standard/default may be leading to mistakes in the configuration and setup.
I recommend going back and changing the transmitter so that channel 1 = roll, channel 2 = pitch, channel 3 = throttle, channel 4 = yaw. channel 5 or 8 is for flight mode selection. Then re-do the RC calibration and make sure the green bars are all moving in the same direction as the sticks except for pitch (although as you say, pitch is not used so it shouldn’t matter).
Then I’d go back and make sure SERVO1_FUNCTION is 73 (left throttle) and SERVO3_FUNCTION is 74 (right throttle) and that these are corrected to the appropriate motor and then I’d re-do the motor test.
I don’t have a full parameter list and I don’t think it would be helpful because the rest of the parameters should remain at the defaults and/or are specific to the vehicle.
Have you posted an onboard log (aka dataflash log) anywhere? We say this a lot but without a log it’s all guesswork.
Sorry to be annoying but sticking with the standard setup makes support much easier.
A standard setup would clearly be easier for anyone to assist with - so I’ll reconfigure. I won’t put a data flash log up until I’ve done that reconfiguration. When I do put up such data, what format is best? .bin/.log?
My reconfiguration will extend to moving one of my ESCs to port 3 on the FC (gggrrrr…I’m not a great solderer). If that is necessary, I conclude that the logical/coding route from RC receiver channels through RCMapping to ESCs is quite different from the corresponding route from the loiter controller to the ESCs. This doesn’t seem ideal. I’ve cloned the ROVER code locally so that I can work my way through the differences. I expect I’ll need a deeper understanding as this project progresses - so the review will be worthwhile whether or not it helps with reconfiguration.
With configuration set as close to standard as possible, radio throttle/steering control and motor tests work fine, as long as SERVO1_REVERSED = 1. Is that likely to be problematic for loiter mode?
I’m very interested in your project. I am a World Sailing International Race Officer and I run sailboat races all over the world. Our large trapezoid courses can have up to 10 marks. I’ve run a world championship in Curacao in depths of 400 metres and autonomous marks would have been very nice.
I’m thinking about an implementation in which autonomous marks are directed from the signal/start boat. The race officer on the signal boat would have the application that sends the coordinates to the marks. The marks would move to the correct position and enable the mark loiter mode.
In the past I have written a program to calculate the latitudes/longitudes of marks based on the origin of the signal boat, wind direction, and windward leg length. I won’t have any problems with that part, the hardware side of the implementation would be all new to me.
I have a little Python experience even though the above program was not written in Python.
Would you be willing to share your hardware design?
Peter - absolutely no problem sharing - our mutual scope requirement is exactly the same - bar I sense the scale of the buoy ?
What we seek are buoys sized max 400mm diameter / ~ 2 kilo / ~6 hour battery life for inshore / lake use. Am I correct that what you seek are buoys for offshore applications - i.e. up to ~ 2 meters tall and ~ 48 hour endurance ?
No matter the end use, we believe the software / GUI systems could be identical, the hull, propulsion & top works would vary to suit the environment.
If offshore is the case, I am aware of commercially available offshore solutions - Marksetbot and Roboboj - and i’d be surprised if there where not others - (i know of at least one more under development in Turkey). I’ve tried to speak to both of these to sound out their willingness to offer a “micro” sized solution but no dice thus far. These two solutions are way beyond our price range, and way to large, and not sure that their GUI functionality (currently) delivers what we both would aspire to … and have no indication that they are willing to collaborate or share design or components. I’d be very happy to be proven wrong.
So for our prototype, my team of two has adopted this bogey board hull solution Announcing the Maker Boat Basic! developed largely by (i think) @nuballawalla (Daniel Carlson) & @rmackay9 (Randy Mackay) and are in the process of testing. Our status to date is that hull and propulsion are exactly what we want, but we can’t get the darn thing to “loiter”… but we are doing what we can, and taking/seeking input from this user group to sort out the issues …
We have a simple top works design and when the planets align will be posting to this forum, but prototype will be only a single buoy operated from a dedicated transmitter.
Next step, and we think its a big one, is the software / GUI / handset ability to direct and control multiple buoys from one control station / ipad / laptop, and we’ll really need help .
We can see applications for sailing, rowing, swimming, triathlon, water skiing, commercial shipping etc etc.
Trust this assists, and would be very pleased if you chose to collaborate.
You can also reach me on andrewRwilson62@gmail.com
OK great. Having SERVO1_REVERSED=1 should be fine. Another option is to swap two of the three wires connecting the ESC to the motor but it’s not important.
Thanks @rmackay9. Test last evening was unsuccessful as mode couldn’t change to loiter. I haven’t worked out why but suspect it was something to do with GPS signal. A test now, albeit with the FC out of the vessel and no motors connected, shows it moving to loiter as it did previously before. I’d like to analyse that log before launching in water again. Is there a position error, with direction to loiter station, in the log?
Peter, I’m prone to under estimate development required for most projects…witness the fact that I’m 3 weeks solidly into this 2 day (estimated) project! But, in principle I don’t think there is so much to do to go from a single BuoyBot rounding mark to a coordinated fleet each member of which will go to, and hold, it’s position if the system is given position of committee boat (or some reference), wind direction and course length (assuming a fixed geometry can be specified by these).
I’ve not yet tested loiter in the water. But behaviour, from the log, still seems very odd when the FC is simply sitting still. See for example the following (which shows SteeringOut, PIDS.Target and PIDS.Actual). I’m looking through code trying to work out what the inputs to the PIDS are and where they come from…
Hi all, the events that I’m talking about are on lakes or or just offshore and we’ll be on the water for about 4-6 hours maximum. 2 metre marks would the the exception, most of the time the marks 1.2 -1.5 metres.
The reason that I’m looking here is that the commercial solutions are out of most club’s price range and over the long term an open source solution will be better.
I see the following parts to a potential solution:
- A GUI to calculate the mark coordinates and to send them and the instructions to the marks. Some instructions would be: move to x,y and loiter, move to x,y and drift, loiter in place, drift, etc
- a platform to hold the mark which will be different based on the application
- the electronics and software on the platform which will probably be basically the same for all applications
The GUI will be the easiest. A long time ago I wrote a little program that calculated mark locations based on a given course, wind direction and course length. The coordinates could be uploaded as waypoints into a GPS. This allowed my mark layer to lay a full trapezoid course within 15 minutes. He just used the go to option. Also, it displays the course in Google Earth if GE is running when you start the program. Here are the links to the program and a bit of documentation :
I suggest that you install it in a directory for which you have read write access. This is because there are a couple INI files included that allow you to configure the units and course configuration. The program works with or without a connected GPS. You can configure any course with up to 9 marks.
Overlaying the course on Google Earth is a powerful feature.
GE has a python API and is a very good tool for this.
Unlike the RC course, my course could cover 3KM. Will MavLink be able to cover that?
I know that 4 thruster Omni configurations are not supported, but can you use two pairs of thrusters for bigger platforms?
I’m still getting weird steering oscillations, even with the FC on my desk (but with good GPS). I’m interpreting NTUN.WpBrg and NTUN.WpDist as being the bearing and distance to the loiter station (way point). Is that the correct interpretation? If it is, then the throttle behaviour (not shown), which commences rising from zero when WpDist = 1 = LOIT_RADIUS, looks at least plausible. But with WpBrg changing very slowly (apart from the flip in display from 360 to 0), high amplitude & frequency steering oscillations commence and are driven by the derivative term in the PIDS. Gains are constant (ATC_STR_RATE_D = 0.2 =ATC_STR_RATE_P = ATC_STR_RATE_I; ATC_STR_RATE_FF = 0.05) so what is driving this behaviour? Is the steering speed available in the log? Log here: https://drive.google.com/file/d/1m_f2a37HCPCU3DdDingl8ix8GT6x1KSN/view?usp=sharing
Edit: The derivative term in the PID is _derivative += get_filt_D_alpha() * (derivative - _derivative); get_filt_D_alpha() is a low pass filter which is basically (dt/(dt+1/(2π * filt_D_hz))). I haven’t been able to find default values of dt and filt_D_hz. Any suggestions? (Even if this were the problem, I’d like to understand why a high frequency signal is being generated that needs filtering.) @rmackay9?
Hi Peter, your email confirms that our mutual intent is the same, solution not so much. May I suggest we arrange a conference call to discuss ?
We are two parties in Brisbane Australia, your location ? Preferred time and communication method ?
Hi Guys ,
sorry i saw only now this post … how i can help you ?
here https://www.facebook.com/groups/1606596929592397 you can found last my update that i’m doing on iseo lake …
Here there is 56 video of story of my test until begin …
This is my parameter if is usefull for other that are working on buoy system …
I’m available for support new project we are going in production with 10 new buoy this week …
boaconfig.param (15.8 KB)
Hi Peter the source is available of your application ? i could integrate in my app for android smartphone for define the position of buoy automatically and sure i can implement a mavlink transmition towards buoy for set its position
Please contact me at firstname.lastname@example.org and we can talk. My main goal is to create a open source solution.
Thanks very much @Roberto_Navoni. Our test yesterday in a pool, with poor GPS, was much better, I think mostly because of putting ATC_STR_RAT_D=0. I’ll investigate how this can be improved. Next tests will be in the nearby river with better GPS + some current (tidal) and wind - with a SUP on standby for rescue.
Interesting concept this but wonder if it would be easier to have a RC boat that can carry the weight of a buoy to a set location on the map to go there, drop the mark and come back to its release location to grab another mark to drop?
I also race RC Sailboats in various class and being thinking of this for us.
@Gilbert, I suspect the position holding concept would be easier than deploying another buoy, with anchor, etc. Of course, having 6 or more position holding buoys, to form a course for example, would likely be more expensive but would also allow very quick course realignment. We had an idea last evening that could bring the cost down a bit - when we have something we think is near optimal, we’ll publish full details. But a major reason for this particular exercise is that the club races in channels in a harbour. Although they’ve been racing for perhaps 30 years, they’ve recently been told that they can no longer anchor a buoy in the channel - ie the anchor line is considered a danger to navigation. So the station holding buoy is ideal for that purpose.