This is a great idea, however gps signals inside buildings / homes are not strong enough nor accurate enough. 2 ft of inaccuracy could be a big mess inside a home if the robot was large enough to do damage.

Hi, I got in scope outdoor using, that's why I need GPS, not any ips o similar stuff for indoor application. Thx

GPS support is fairly limited in the ARC. Pretty much just the one script command:

GPSStop( latitude, longitude, resolution ) Uses the attached GPS control and stops the Movement Panel when the coordinates are within the specified resolution for the latitude and longitude. Example: GPSStop( 54.01438, -110.4931, 0.0005).

There really isn't currently a "navigate to this waypoint" feature, or apparently even a variable with the position data to use in scripts (although I haven't tried connecting a GPS to see if it creates variables once connected, if so, they aren't documented).

Assuming DJ adds those features, the EZ-B will need to be within WiFi range of the computer running ARC or the SDK, or you will need to build a robot with an embedded computer. The EZ-B itself always needs to be connected via WiFi to a computer, iOS or Android device.

If you are looking at using the SDK however, there are plenty of GPS libraries available for .Net, so you could use one of those to get position information, then EZ-B commands to move towards the position. I would recommend getting the 4in1 orientation sensor so you also have compass position. A GPS can only tell what direction you are facing when you are moving at least 1km/hour, so using an orientation sensor to point in the right direction is important too.

Alan

Alan's got it. The combination of GPS and Compass is necessary for robot applications to use GPS correctly. The GPSStop() is exactly all that you need when combined with a Compass, such as the 4-in-1 Orientation Sensor.

For example, you're path will consist of points which GPSStop() will come in handy. Simply specify the coordinates to multiple GPSStop() and off you go.

As for navigation, that's a different topic all together. The challenge with the concept of a GPS WayPoint is that it lacks "how you navigate to get there". You see, in a car you are the navigator. This means as a human, you have the ability to stop at lights, drive around objects, turn onto streets, etc.. The method a robot would use to navigate is dependent on the robot's sensors and what you have determined as the navigation method for the robot.

If you have added sensors to your robot because you have already thought about navigation, then use those sensors to navigate the robot while GPSStop() is waiting. The only way to determine what direction a robot is moving is to use a compass module such as 4-in-1 Orientation Sensor

Unless everyone wants to work together and build the exact same robot, there is no "single" solution for GPS WayPoint because they all navigate differently. Start by experimenting with GPSStop() and determining direction with 4-in-1 Orientation Sensor.

DJ, the one additional thing we need I think is a $GPSPosition variable. You don't know which direction to go unless you know where you are, so we need to be able to read current position, not just know when we have reached it with GPSStop(). That was why I was recommending possibly using 3rd party libraries since Simon indicated he was using the SDK. On the other hand, Simon also said he is new here, so may not know about all the capabilities of using ARC without writing any code other than sometimes scripts...

Alan

I'll add that to the GPS Control.

Jeremie has an EZ-Bit GPS on his desk - not sure the status of us but i know he's been poking me to test it. That and a few others - like oled, capacitive touch and more. He's been busy!

Very cool.

Is the inverted pendulum going to be coming out soon? I have been waiting to place an order to include that so I don't need to pay shipping on a single $20 part. I am not in a huge rush because they are still repairing my basement from the flood/mold damage, but that should be done in a week or two, and I am going to have an awesome workshop to work on my robots when they are done.

(sorry for going off topic).

Alan

That inverted pendulum has been such a pain in the butt :). The chipset we chose for it had a bug in the compiler we use. The software company had finally fixed the bug 2 weeks ago. I will be working on it this week - it's a top priority, as well as the 8x8 rgb display and a few others. EZ-Robot simply needs more of me :D

Maybe i should be spending my time on a cloning machine!

Hi! So first thanks for your kindly reply. @Alan-> in regards the WIFI range you can use a 3G/LTE dongle to expose a WIFI network (to connect the EZ-Robot) and use a VPN to get connected over Internet. This will extend the range until you got 3G/LTE coverage. In regards GPS there's plenty of unexpensive UbloX devices embedding also magnetometer: you don't need movement to get where are you pointing (if you are calibrated of course).

@Dj-> I was looking for something integrated like a "mission planner" stuff inside a simple EIDE like ARC cause my potential end-user needs something really simple. To execute a mission waypoint plan on compatible deviced, normally I use MavLink protocol.

Thanks again. Ciao S.

@Simon_freeman,

It is really pretty simple to do the portion of path planning. For example, I have a product that gets the walking directions from Google Maps from your current location to another location (address that has been geocoded). These points are stored in a table. This table is used to identify what the current destination point in gps coords. There is a function that I have that will tell the robot which degree heading it should be going by taking the current location and calculating the direction it should head to get to the next point. This calculation happens once a second and is returned back to the robot, allowing the robot the ability to modify its route to get around obstacles and then get a good direction to head in again. When the robot gets close to the current destination point, the app marks this point as completed and then loads the next point as the destination location, which then calculates the direction the robot should be heading. This repeats until the robot has reached its final destination. This is all done using C# and the EZ-SDK.

Here are the issues you will face... The outside environment is not a flat or level place void of obstacles. Your sensors for detecting these obstacles are different than other peoples sensors. Your motors and motor drivers are different also. The diameter of your wheels and height of your robot has an affect on what you would deem easy to overcome vs someone else. If you use roads and sidewalks, that becomes easier but then you have to take into account people and vehicles. along with curbs and ramps to go across streets. If it is a field, the height of the grass that day may affect things, and you have to account for people, animals, fences and other things possibly. All of this programming is unique to your setup and the reason that there isn't a module that you can just drop in place.

For my solution, the mission planner is done through voice by saying which location you want to visit that is found on Yelp. From there, Google Maps is used to get the path to the location which is stored locally in a table. This is a solution that is very easy to use from an end user perspective. The rest of the stuff (actually getting to your destination and avoiding obstacles) is the part that each robot would have to be programmed differently on.

Simon, do you have much programming experience? The open plugin architecture will allow you to build a plugin for your needs. Otherwise, maybe sweet talk someone in the community to see if they will help you create one built with a google maps api backend :)

Wouldn't be too challenging - specifically if you have the requirements already outlined.

Hello all,

I'm new this community. I have the six hexapod and want to make him move to a bunch of GPS locations. I have a GPS module attached that works and gives me latitude and longitude. I have problem using the GPSStop command. I want to make the robot go to 5 different locations using the GPS and perform a task at each location. thanks in advance.

Can't answer your question but .... Are you using this outside? GPS is only accurate to about 10ft so sending your robot to waypoints locations indoors would not work very well at all...

How are you controlling the GPS at all? The GPS object was removed from ARC several releases ago. It looks like DJ missed deleting the GPSStop script command when he did that.

Alan

Thank you @Richard R, I have been using it outside, it is just a proof of concept I do not want precision. Thank you @Alan, I found a GPS plugin which I used and connected an independent GPS module, I obtained values. Hence I wanted to use this in a program to show waypoint control. Yes, the script help did not have the GPSStop function.

Omg so I cannot use GPS with the hexapod. What are my other options to make this happen.

Oh, I missed that there is a plug-in. If you have lat and lon in variables, than you can write scripts that wait for specific values, or better ranges of values, and then take action (stop, change direction, etc...). A little more complex than the old gpsstop() command, but shouldn't be too hard.

Alan