Programs

PICAXE_logo.png

PICAXE-28X1_Proposed_Connections.png (445246Bytes)
Extended_Look_V1.5.bas (3626Bytes)
Simple_Left_Right_V1.5.bas (2813Bytes)

Recently I wrote two programs for a PICAXE-28 microcontroller. Currently I do not have a robot but I am looking for UK suppliers. The first program is based on the Start Here program, whereas the second is an idea of my own which elaborates on my simpler program.

Please note that at the moment values like the danger level (currently 70), servo delays, turn delays and high/low commands are in fact blind guesses as I don't yet have a robot to test them on. Please also note that the programs assume that the left motor is connected at pins 4 and 5, that the right motor is connected at pins 6 and 7, and that there are two LEDs connected at pins 0, 1, 2 and 3.

Simple_Left_Right:

V1.5:

  • Main loop is now a Do While statement.
  • Bigger if statement for improved decision making.
  • The program now assumes that the LEDs are hooked up to an output pin each and the ground pin, reducing the number of 
  • required pins.
  • Halved the ServoDelay for efficiency.
  • Split the code up into subroutines for efficiency and also to make the code easier to read.

V1.4:

  • Added a servo position reset towards the end of the program.
  • Slightly extended the ServoDelay.

V1.3:

  • Altered when LEDs are switched on to improve bug-testing.

V1.2:

  • Added symbols for pins.

V1.1:

  • Added support for down-facing IR sensor. This includes the turn 180° feature.
  • Added support for LEDs.

V1.0:

  • Looks left and records the distance.
  • Looks right and records the distance.
  • Works out the greatest distance.
  • Turns and travels in that direction.

Extended_Look:

V1.5:

  • Main loop is now a Do While statement.
  • Bigger if statement for improved decision making.
  • The program now assumes that the LEDs are hooked up to an output pin each and the ground pin, reducing the number of required pins.
  • Split the code up into subroutines for efficiency and also to make the code easier to read.

V1.4:

  • Altered when LEDs are switched on to improve bug-testing.
  • Removed accidental Return commands.

V1.3:

  • Added symbols for pins.

V1.2:

  • Added support for down-facing IR sensor. This includes the turn 180° feature.
  • Added support for LEDs.

V1.1 (Is actually just called "Extended_Look_Optimised"):

  • Looks approximately 90° left and records the distance.
  • Looks approximately 45° left  and records the distance.
  • Looks approximately 5° left  and records the distance.
  • Looks approximately 5° right  and records the distance.
  • Looks approximately 45° right  and records the distance.
  • Looks approximately 90° right and records the distance.
  • Works out the greatest distance.
  • Turns and travels in that direction.

The first one - in theory - is fast, but because it only looks in two directions it isn't very accurate. The second one - again in theory - is slower, but because it "sees" more it can make a better informed decision.

Update: 19:37 GMT, 29th April 2012:

Attached is a picture of the planned connections that are used in the programs. I have also removed the old programs and will only be attaching the latest one from now on to avoid confusion. If you would like to view an older version then please don't hesitate to ask. P.S. Appologies for the onslaught of updates lately. I haven't been on here for over a year and I'm trying to get to grips with all of the features again.

Update: 21:14 GMT, 2nd May 2012:

Today I opened a new post. There I will keep you updated on the hardware development of my robot. The software side of things will stay here for now but may eventually move to my robot post as I develop a more suitable program for it. You can access my new post here.

Update: 20:48 GMT, 9th May 2012:

Sorry I haven't updated in a while. I've spent an extra hour or two testing as best I can my programs. I'm still waiting for my second package so my robot still has no eyes. Soon I will try and test some motors so I can get them sorted in my programs as well. I've uploaded another image which shows the big difference between the two programs, and my proposed connections picture has also been updated. Yes, I know they don't match the pins in the programs. I'll fix those when I get everything I need to finish my robot.

Potential champion

Well it will be interesting to see how close you got to a working code without any hardware. Congratulations on making a start even without the hardware. Not many people try that. While it remains to be seen if they work on the hardware, I can think of a certain billionare and his mate writing programs for hardware they didn’t have (mits altair). In the end their programs did work, which is amazing when you think about it. For me it usually takes a number of iterations before it works the way I want even when I have the hardware in front of me.

btw there is a simulator in the picaxe ide to run code I believe.

Thank you. :slight_smile: I’m currently

Thank you. :slight_smile: I’m currently learning programming at school (Visual Basic specifically) and have been trying out various other languages for a few years. However, PICAXE is not one of them and really all I did was look at the sample Start Here program I found here and work from there. I will be uploading my code when I have worked on it some more. It’s almost finished.

Obviously, I can’t get everything right without having a robot to test it on. Especially delays. I have tried the simulator but as my code can’t react to the environment as I have no sensors or inputs, it isn’t of much use to me. I can go through the code just by reading it.

Tweaking obstacle avoiding

Tweaking obstacle avoiding code is great fun, but can be somewhat frustrating at times.  You find what works for one type of situation is totally useless in another.  I have a feeling your code as it is will get stuck in corners a lot #;¬)

Take a look at the tracked robot I’ve just posted : https://www.robotshop.com/letsmakerobots/node/32434.  I was looking for a compact and rugged chassis for a robot and the Chris the Carpenter’s Tiny Tank fitted the bill. Shipping to the UK took just under a week.  

Thanks for the advice. I

Thanks for the advice. I have changed my code - it is now V1.1. That chassis looks really good and I can see myself using something like that in the future. Your robot is pretty cool too. :wink:

**You’ll never know . . . **

You’ll never know how good your code is until you’ve got it trundling around the room #;¬)

Haha, that’s very true, and

Haha, that’s very true, and it’s also the reason I want to get my parts as quickly as possible. Hopefully I’ll have them within two weeks, but I haven’t properly looked into delivery times and dates yet.

I only looked at the simple left right program.

As programming advice, I would suggest you make symbols for all of the pins you are using.
Ex:

Symbol Motor1A 4
Symbol Motor1B 5
Symbol Motor2A 6
Symbol Motor2B 7

I would have shown examples for your other pins, but, I don’t know what sensors you have them connected to, and, Sensor1 isn’t exactly descriptive when it comes to variable names. The motor variable names are more difficult, so, Motor1A, etc. is about as good as it gets. Yes, it is more typing in the short term, but, if you ever change things around, you don’t have to search through your program to get all the pins changed. You change it in one place and you are done. 

Thanks for the advice. Both

Thanks for the advice. Both sensors are IR. One is front-facing but is attached to a servo, and the other points forwards but at an angle. I’ll change the programs and get them posted when I have a moment.

One other bit

rather than writing High LM_Pos : Low LM_Neg : High RM_Pos : Low RM_Neg all the time when you want the robot to move forward, try writing a subroutine called forward. Like:

forward:
   High LM_Pos
   Low LM_Neg
   High RM_Pos
   Low RM_Neg
return

And call it like:

gosub forward

The benefits to doing this are the similar to the benefits for making Symbols. First, if the code doesn’t work like you want you make a change in one place, not several. Second, when you read the code it makes more sense (ie. if there is nothing in front of me go forward). No more guessing what High LM_Pos : Low LM_Neg : High RM_Pos : Low RM_Neg will do.

One other thing and this is purely from a standpoint of structured programming than readability. Instead of main:, goto main loop that is very common. You may consider:

main:
   do
   'main program loop
   loop while 1
end

The above is the same as main:, goto main, but, it is structured. If that doesn’t work, you could change the while 1 to while 1 = 1

Ah, ok. I see what you mean

Ah, ok. I see what you mean now. I’ll update and upload the programs maybe tomorrow. However, I’m a little confused as to what you mean by “structured”. Afterall, they do the same thing. Just for the record…

  • LM_Pos is the left motor’s positive pin (when going forwards).
  • LM_Neg is the left motor’s negative pin (when going forwards).
  • The other two are the same but are for the right motor, not the left.

Re: structured programming

If you study more of programming, you will hear/learn about spaghetti programming and structured programming.

Spaghetti programming : I was going to write something here and then decided that I am sure someone has written more and better. So, I will let you read their work. :slight_smile:

Structured programming : See above. :smiley:

Ah yes, I’ve heard of those

Ah yes, I’ve heard of those before. It just didn’t click when you mentioned them. From my knowledge of programming I can’t really see how changing that specific GoTo to a Do While is going to make a difference in this case. However, thank you for your advice. :slight_smile:

GOTO and DO WHILE.

In your program there’s no difference functionally, but GOTOs are disliked because they can lead to code which is very hard to follow both while debugging and if you come back to a program after some time, or if someone else has to maintain it. 

The problem is that a GOTO can go to a label anywhere in the program.  OK with a small program but the destination could be several screens away in a larger one.  If you see a WHILE in a program you know that it must match with a DO somewhere above it.  If the program is properly indented you can immediately see the DO as it will be indented the same amount.  Here’s an example of indenting from one of my programs.  You can immediately see the program flow.  GOTOs can easily obfuscate this.

        if state = 14 then
              if mrng > ract2 then
                    state = 0
              else
                    if l2rng > r2rng then
                        lspd = 10
                        rspd = 30
                    else
                        lspd = 30
                        rspd = 10
                    end if
              end if
        end if   

I understand what you mean.

I understand what you mean. GoTo is a command I rarely use as it does indeed lead to messy - and buggy - programming. Thank you for your help.

I took another look at your Simple program.

Houston, we have a problem.

Symbol Head = 0
Symbol RotatingIR = 1
Symbol FixedIR = 2

Symbol G_Pos = 0
Symbol G_Neg = 1
Symbol R_Pos = 2
Symbol R_Neg = 3

I am guessing all 7 of those are meant to denote pin numbers. I believe you need to make some adjustments. :slight_smile:

Aaaaaaahhh, I don’t know

Aaaaaaahhh, I don’t know what to do! I thought the analogue and I/O pins had the same numbers and the program just interpreted which one to read from/input/output. :frowning: I don’t know what to change them to. Would a picture help?

Aaaaaaahhh, I don’t know

Sorry, n00b error. Posted twice by accident. :stuck_out_tongue:

From what I can see

The analog pins are called out as A.0 through A.3, C.2 through C.7, and B.0 through B.5. I am guessing you are aiming at ADC 1 and ADC 2, so, you are after A.1 and A.2. The other pins you call out could be called out as B.x or C.x, with x being a number between 0 and 7.

Thanks so much! I’ll look

Thanks so much! I’ll look into that properly when I finish my robot. Until then, I might as well keep them as they are.