Time for another progress update. I finished making the GUI for the config tab for the Compass/10DOF imu.

Added features for calibration, corrections and sorts. It also works, which is quite important. So far communication works fine through the arduino. However I did notice that the response time increases if one of the sensors isn't connected to the arduino.

On this note I've completed all my short term goals: Full control over the Kangaroo:

• Setting the speed of either motor.
• Getting the speed.
• Setting the travel distance.
• Getting the traveled distance. Completed the communication with the arduino:
• To read out all distance sensors.
• To read out the compass heading. Added some extra features that came with the 10DOF IMU:
• Pitch.
• Roll.
• Altitude (relative ofcourse, due to it reading the air pressure.)
• Temperture (also relative due to the IMU heating up after using it for a while).

So overall good stuff. Next part of the project will be making the actual navigation part. My idea was to use a "tangent bug" algorithm to do the route planning. I have yet to get idea on how thats going to work. Reading papers about it only confuses me furter, so I found this diagram, which seems to portray what I want to achieve:

It seems to be the logical path to follow, so to be continued.

Great work! I'm impressed

Another week, another achievement. Last week I started working on the mainform, adding it's first features required for navigation. I made a panel which will be used to display and plot a route for the robot to follow. By clicking on various places inside the panel it will generate waypoints and connect these by lines. It has no other function that to show the user the order and planned route. In reality it would only need the x/y coordinates which are stored in a list. The first waypoint will be the start, the second and third, etc. will be the destination.

I also added a panel which offers the user the ability to select waypoints and see it's coordinates inside the panel. The coordinates are based on a graph where the middle of the panel is x=0/y=0 and every pixel counts as 1cm or 1 inch depending on the values given by the distance sensors. Ofcourse I took it into account that sometimes a larger field might be required, so I added a scaling feature to it in the config.

I have had some issues getting this to work. My biggest issue was storing the previous line drawn... The new one would remove the old one >.<. In the end I found out that my approach was wrong and I followed a different one which did work out and was way, way easier.

Next on my lists are more features for the waypoints. Removing and adding waypoints. Displaying something that looks like a robot and displays real time information. Displaying the object resembling the robot with a heading relative to the north inside the panel and possibly sensor distances.

For the sensors I'm thinking half shaped circles growing in size the further the are. relative to a 30 degree angle from the robot. As most ping sensors have a 30 degree spread. So these circles will be projected inside the panel relative to the position of the robot, sort of making a map. Very low resolution ofcourse.

So far I'm getting closer and closer to the navigation part.

"Small" update on this project: I've been working on and off on this part of my robot project. So far it's a great learning experiance. Just whish I had more time. Anyways, I've made the first start of the object avoidance part of this plugin and it's working which is fantastic. It will now, based on sensor readings stear or reverse away from objects.

It's still quite slow, but it's a start.

My next goal will be to speed it up, get faster response time and add compass data so it'll stear around and object and will continue on it's route.

This is looking really good. I look forward to watching your progress.

Alan

That's great. Writing a plugin for this is an awesome idea. Very impressive and it must be a lot of work. I really wish I knew how to write the type of code needed to make one. Sounds like I need to add this to my bucket list.

Ya, not having enough time for things we like to do really does suck. I understand. It's one of my main gripes in life. However, it does help me to appreciate the time I do have and if this is my biggest problem in life I guess I'm doing pretty good.

Nice work so far and I'm enjoying watching your build. I love the way you've worked through each step and problem. Thanks for sharing your progress. Please keep it coming. It's very inspiring.

So after careful consideration and lots of testing, I've decided to make a major change to this project.

As it's currently configured, for the project you basically have the EZ-B as main controller, which controls:

• The kangaroo x2
• An Arduino which controls 5 pings sensors & 10DOF IMU
• 2 Servo's for steering

But I've ran in to a few problems and noticed that I cannot achieve faster response times between, the Arduino to the EZ-B to pc where the distance measurement data is processed, after which a reaction is made and send back to the EZ-b, e.g. an object is in the way and it should steer away.

Now the problem is that the distance sensors don't read far enough distances that I can plan a head and avoid objects in time. It's also my goal to make my robot fast which requires an even larger measuring distance en furter a head planning or faster reads from the sensors.

To Solve this problem I've deciced that the cheapest option is to stick with my current sensors and increase the read out speed. Due to the communication to the place where the data is being processed being to slow and quite far away so the solution I've come up with is to decrease the "distance" between reading out the sensors and the place where the data is processed. So I've decided to move that part to the arduino reading out the sensors. So all controls and navigation regarding will be processed and executed by the arduino so the whole loop gets significantly reduced in length. Which should result in way way faster response times.

So what does this mean? Well I'm going to rewrite a large portion if not most of my plugin and arduino code. Most of the code is based around settings, testing and controlling the individual components, i.e. kangaroo, serial ports, servo's. All of that will be moved to the arduino. The same will happen for the actual object avoidance part of the code, which so far supprisingly enough is only like 10-20 lines code.

Where does the EZ-B come in now? The EZ-B will still be important, as it will tell the arduino what to do. At first it will give a heading and a distance to traverse, with plans for gps on the arduino. So the EZ-B will send GPS coördinates.

So for now I'm waiting for a shield for my arduino mega 2560, so I can switch out the arduino nano I'm currently using. I've already rewriten a large portion of the code for the arduino, drive controls for the kangaroo, servo's, ping sensors and the 10DOF IMU. I've also tested the first few parts with good results. Once I've switched out the arduino and rewired my robot I can test more features of the code after which I'll start reworking the plugin.

The plugin will still have features where one can test the individual functions and ofcourse plot routes and start/stop it.

So yea, lots to do and much to think about.

If anyone would find it usefull, I can post my current plugin so parts of the code can be used for other plugins or C# programs.

Why dont you use the ping sensors directly in the EZB. I have my robot navigating with 3 ping sensors and they respond instantly. Why use arduino for this?