General Purpose Autonomous Rover

Hey guys, I’m back with an update.

Just been reading my first post here and I cannot believe how far this has moved on since then. Before coming across AOG, I had never seen an Arduino and knew very little about electronics, but AOG sparked an interest which has become an obsession.

So the vehicle. This is an all electrical vehicle, originally an electric scooter, now a golf buggy. The 24V motor is being driven by a 60amp Cytron motor driver (which, at £125, wasn’t cheap, but is really quite a piece of kit). This is controlled from an rpi on which is mounted a simplertk2b board, mounted via Ardusimple’s rpi - simplertk2b adapter board. All plug and play, really nice. The rpi is running Node Red which is being used to control the drive motor and various electronic tools we will be attaching. So that lot drives the vehicle, offers remote control via a mobile phone app, and tells the vehicle when to start / stop.

AOG has been deployed as the vehicle guidance / autosteer system. I would have just stuck with AOG for all of the vehicle controls, but I simply could not (yet) work out how cut power to the main motor if the vehicle breaches a geofence. I realise that this must be a simple case of employing relay control to the drive motor as a “tool”, but haven’t yet been able to get this working. Think I’m missing something trivial here.

Because this is a small / micro vehicle, I have stuck with MicrOpenGPS, but will be conducting field trials this week and will post up some videos of how it all goes. I will also test it out in the new V4.x version to catch up with what you guys have been up to.

1 Like

I’ve been busy with some other hacks and not had time to work with 4.xx. I’ve been reading the other post here and it seams to do some neat things. You’ll néed to modify the two files mentioned earlier in this post to get the u-turn working on your small tool. @BrianTee_Admin posted somewhere the location of the “if out of bounds, shut down.” With what I have seen in the version 4.xx, the tool lift at a zero headland could kill the machine as well as it lifts a lift. Good to hear that you are still moving forward. Sounds fun.

1 Like

Hmm, I have found what appear to be many u-turn bytes and cannot seem to locate the out of bounds reference :frowning:

I did try just strapping a relay to the system and using it as a section controller which does actually cut power to the motor when it breaches the geofence, but obviously it also cuts power when it senses it has hit an area that has already been covered so the vehicle just keeps stopping randomly half way across a field.

Still working on this!

I have no idea which version this is, but it is under the SerialComm.Designer.cs.

////gone out of bounds so full stop.
//if (mc.isOutOfBounds)
//{
// mc.machineControlData[mc.cnPedalControl] &= 0b00111111;
//}

        //add the out of bounds bit to uturn byte bit 7
        if (mc.isOutOfBounds) 
            mc.autoSteerData[mc.sdYouTurnByte] |= 0b10000000;            
        else 
            mc.autoSteerData[mc.sdYouTurnByte] &= 0b01111111;

Some of this is commented out and not used anymore. But the trigger is “isOutOfBounds” in AOG.

The “autonomous” part of AOG is seriously behind the field work part which has been the major focus these last few months. Yes, most of the code was commented out just to make sure the normal field operation code was working.

Just added this simple little check in the FormCommSet.cs to see if you could add a trigger to the relayData and you can. I put it on [9] as it was not being used on this version. And sure enough, it will give you the out or in bounds value (15 or 0). Arbitrary values, but it works. If I remember right, on one of the videos, there were extra serial read values in the arduino code. I may be wrong, but it may be worth looking into.

if (mf.mc.isOutOfBounds)
{
mf.mc.relayData[9] = (byte)15;
}
else
{
mf.mc.relayData[9] = (byte)0;
}

Edit: This was the video (6.25 mins is where the extras are). Much has changed very quick, but it is controllable:

1 Like

Thanks for this Kentstuff, this is all a massive learning curve. I have had a look, and edited, the CS files as described, but I’m still a little lost with this. Basically nothing changed after I’d done the edit, I’m unclear as to whether the app needs recompiling.

Sorry for my ignorance!

The geofence OOB feature does work as things stand; if the vehicle breaches the geofence, then it cuts power to the relays. So if I strap a relay to the drive motor and designate this as a tool, then it does stop as required.

The final problem I have though is the overlap feature: if the vehicle hits an area it has already covered, then it cuts power to the tool. If that tool is the main drive motor, then obviously the vehicle just stops… potentially half way across a field.

Is there any way of disabling this overlap feature whilst maintaining the OOB function? If I can do that, then I have everything working through AOG.

Try this!
Manual_Switch|689x449

I have tried, but unfortunately there is no change. The sections still disable when they hit an overlap area.

Thanks for the idea through :slight_smile:

In original code it should be working. With this manual mode I can overlap and drive to my neighbors field and it will be painting all the time.
Try to change to manual section control while driving.

1 Like

I’ve updated the MicrOpenGPS to limit the number of sections to 7 and use section 8 for the out of bounds relay. Simply connect your equipment master supply to the section 8 relay in the arduino code. It will send a 0 for off or 1 for on. Section 8 is overwritten just prior to the serial transmit. I have reformatted the strings in the picture below to see working. Just remember, there is no out of bounds when there is no boundary. I have not tried with the arduino but it appears to work in the simulator. Edit: Workaround I know, but it is simple. Better solution would be the other switches as mentioned above.

In and out of bounds

1 Like

Ok, let me try what you’ve each suggested.

Really can’t thank you enough for about 8 months of support!!

Almost there :slight_smile:

I’m not sure how you originally got the MicrOpenGPS, but fairly certain you will have to update it and rebuild it on your end in Visual Studio. You will loose whatever changes that you have made.

Ugh, that does sound a bit beyond me right now. I’ll try MylArti‘s suggestion, see if I can make that work.

I have set the manual switch as you suggested and have two sections. If I set them to manual, then they stay on regardless of whether the vehicle is inside, or outside the geofence.

Am I missing something obvious?

I added the program.zip folder to the github. You should be able to download it, unblock it, unzip it, and run it outside of any virus shut outs to see if it works for you. May can just download, unzip and go. Not sure how it with come out on your end.

https://github.com/KentStuff/Micropengps/blob/master/Program.zip

1 Like

It works as it is supposed to work. It paints until you stop it manually i.e. automation is missing. Now overlapping the area covered will not cause work to be interrupted. Hopefully this will solve your final problem.

Rebased the latest version 4.3.10 and made the MicrOpenGPS mods with the limited 7 sections and the 8 section as the geofence relay. Here is the link to it. I’ve ran it in the simulator a bit and it appears to work. You can click the module console and see the 10000111 byte when in bounds and 00000111 when out of bounds. Works in manual or auto.

https://github.com/KentStuff/MicrOpenGPS4.3.10

1 Like

It works perfectly! Pin 12 (in my setup) goes LOW as soon as it’s OOB and HIGH as soon as it’s back in the boundary.

I cannot thank you enough for your time. I will add this circuit to the vehicle and see if it all works. If it does, I will post some vids.

Brilliant, thanks!!

Even better. I tested the latest iteration of V4 last night and it’s a huge advance, runs very smoothly and has some excellent new features.

Thanks again.