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

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