Surely a PICAXE could be shoehorned in somewhere

Buzby

Senior Member
It's only got one motor, so you would need some clever mechanical solution if you wanted to steer.
 

eclectic

Moderator
Thanks.
Looks like a "developable" project.

Are there any more suggestions for interesting kits from the same site?

I'm looking for indoor projects for the Winter.

Say $100 - $200 total for the moment.

e
 

oracacle

Senior Member
buy a 3D printer, unlimited projects right there. The sort of kits are great for kids, but i suspect you already have a parts collection of things like switches, motors and LEDs. There are plenty of sites to get models from, print them, apply picaxe and off you go
examples:
EEZYbotARM MK2 by daGHIZmo - Thingiverse
Otto DIY build your own robot by cparrapa - Thingiverse
Fully 3D-Printed Rubik's Cube Solving Robot by otvinta3d - Thingiverse
Arduino car with Remote by hoffmanjon - Thingiverse

You can also make fully cutomised enclosures for you projects as well.
Oh and the printer itslef may become a project, just for for fair warning
 

matchbox

Senior Member
In so many projects like this on BG. You see the Ardu IDE library code.. And never .Bas. I believe this is why.

IMO Picaxe's biggest limitation has become its old hardware. Not .Basic code format.
Plus lacking a task scheduler, makes Picaxe unappealing in many cases.. when compared to the opposition.
 
Last edited:

AllyCat

Senior Member
Hi,
.... plenty of sites to get models from, print them, apply picaxe and off you go. examples:
Fully 3D-Printed Rubik's Cube Solving Robot by otvinta3d - Thingiverse
That's an impressive demonstration, but it did take 70 hours to print, used a whole reel of filament, and still needs 8 servos, a Raspberry Pi, a camera, and additional hardware, etc.. I also watched another video from a College Student using an Arduino, who admitted his final hardware cost was 277 Pounds and I believe 4 months of development time :( . Of course the "Speed World Record" has reached silly levels (much less than 1 second to fully solve physically) and needs a "special" cube (to tolerate the mechanical forces), but what about a "minimalistic" design using a PICaxe? There is also merit in being able to actually follow (in real time) the solution process.

I've not examined the solution algorithms in sufficient detail to say if a PICaxe definitely could calculate a procedure within an acceptable time scale, but the basic sequences are typically just lists of 10 - 20 operations (e.g. grip face A and rotate B) which could be stored in a "lookup" of (say) 20 bytes (in Table/EEPROM). Similarly, the current "status" of the cube can be stored in 6 * 8 = 48 bytes of RAM, and any "change" (e.g. rotation) updated by the program (i.e. copying up to 48 bytes) at least as quickly as the actual mechanical operation. The basic processes are almost at the "bit level", so don't need complex mathematical routines or Floating Point calculations, etc. with which a PICaxe can struggle. I believe the record-breaking machines calculate the soution in around 0.01 second, so I'd be happy for the PIcaxe to take 100k times longer. ;)

First, I've been considering the "mechanics" and particularly using Meccano (since I still have some in the loft), to find that I'm not alone, with:

and
http://meccanokinematics.net/meccano-rubiks-shrine/

Two very different approaches, but I like the elegant simplicity of the 3D printed method above (with 8 servos). In principle, only 6 "motors" are required (each driving an axle at the centre of one face) but that requires a "modified" cube and each face needs to be turned by at least 270 degrees, implying a Stepper motor rather than a Servo. But here, I think Servos are much more appropriate, each requiring only one (PICaxe) pin, with no additional "driver" hardware. Also, the Servos' power supply current can be monitored (in a group) to detect if any Servo fails to reach its target position (i.e. if the cube jams). The printed machine doesn't appear to mechanically "grip" the cube, so presumably there must be significant friction to hold the cube (when the fingers under the base of the cube are retracted). Therefore, a modification I would make is to move all the "hands" in a horizontal plane (perhaps each pair of servos on a "sledge"), so that it's easier for there always to be at least one "finger" supporting the cube underneath.

Most Rubik Machines seem to use a camera (or nothing), which would certainly be a struggle for a PICaxe, but the minimal solution could be a simple "Colour" sensor such as the low-cost TCS3472 module. Perhaps three (one each for Centre, Edge and Corner squares) but that chip has only one I2C address so would need to be "enabled" (for reading) by switching its power supply on and off. Thus, a true minimal solution is just one sensor, above (or below) the centre square of the cube. Reading all the Edge squares can be achieved by giving each "grip" (in/out) Servo an extra position: The "normal" position would be with all fingers touching the cube, then moving Backwards would release the cube, or moving Forwards would push the cube so that an edge square is under the sensor. In principle, the cube only needs to be read at the start (to store its orientation into RAM) and I'd consider a minute or two (recording the 48 squares) to be a reasonable target. Ideally, I'd use 9g servos, maybe that's too optimistic, but perhaps possible if using a good quality "smooth" cube?

Obviously the processor can't be my favourite 08M2 (although 2 or 3 sharing tasks might be a possibility) so I'd start with a 20M2 (which may be replaced by a 20X2 for greater speed), or a 14M2 might have sufficient pins. Two of the eight possible (Port B) servo-capable pins are needed for the I2C bus (I'll ignore bit-banging the I2C), but {H}PWM pins probably can be used to generate additional servo pulses (or use bit-banging on a few pins). If more Table storage is required, a serial EEPROM can be added to the I2C bus, but otherwise I don't see the need for any other hardware except for a (6v) Power Supply and a lower voltage rail for the PICaxe.

To be honest, I doubt if I'll actually build this project (I already have far too many on the back burner), the "fun" is mainly in "problem solving" the design. ;)

Cheers, Alan.
 

Buzby

Senior Member
I started a Rubiks robot, back in 2014. ( Was it really that long ago ? )

The mechanics were prototyped with Lego, and worked quite well. The camera was going to be a simple colour-recognition chip, but I didn't get as far as building this part.

My plan was to get the code working first, then add the hardware. I found an algorithm, tested it extensively by hand, then started turning it into code.

The code was a very labourious step-by-step interpretation of the algorithm, so it took a lot of code space. It needed more than one #slot, and that was my big setback.

The simulator can't handle #Slots, so every time I needed to change slots I had to dump the 'Cube Map' to the serial screen, copy with cntrl-A, close the current slot project, open the next slot project, paste the text with Cntrl-V, then 'massage' it into the start of the code to fill the map again.

This was too much of a hindrance to smooth code development, so I gave up. I did try running the code so far on a real Picaxe ( 28X2 @32MHz ) and it was plenty fast enough to solve a cube in seconds, much faster than the Lego hardware could handle.

There have been lots of 'what we'd like to see in Picaxe', and one of mine would be an option to use the memory space as one big Slot, or stay with multiple little ones as we have now.

I could of course code the engine on a different platform, but then it wouldn't be a Picaxe solving a Rubiks Cube, would it ?

Cheers,

Buzby
 

Attachments

oracacle

Senior Member
The idea was to picaxe-ify the projects, the models are there, how you drive them is down to you.

One of the barriers to doing things is not having the models. You can pick up a reasonable printer for about £120 and give yourself access to as many or as few as you like, either pre designed or something completely new.
The unfortunate fact about project costs is it often has to deal with the mistakes, imagine someone else making those mistakes, the actual cost to you could be less.
 

erco

Senior Member
I shoehorn Picaxes in robot toys all the time. Good fun!



 
Last edited:

AllyCat

Senior Member
Hi,

I was tempted by the OP Kit (for the Grandchildren), it's actually cheaper from the Banggood UK Warehouse than shipped from China! But apart from a few plastic gear wheels and one motor, it doesn't appear to contain many "useful" components, compared with Lego or Meccano, etc. Also, November in the UK is not a good time to try to harvest solar energy and I would be concerned about the alternative "50 Watt Halogen (mains?) Lamp", particularly for the "boat" models. But at least there is a downloadable User Manual (in Chinese only?), for which Google Translate does quite a useful job. :)
The simulator can't handle #Slots, ......so I gave up. I did try running the code so far on a real Picaxe ( 28X2 @32MHz ) and it was plenty fast enough to solve a cube in seconds, much faster than the Lego hardware could handle.
There have been lots of 'what we'd like to see in Picaxe', and one of mine would be an option to use the memory space as one big Slot, or stay with multiple little ones as we have now.
I think one issue is that a larger address range can be included only by extending the "Opcode" (token) data widths, which would reduce the overall maximum program size and speed of ALL chips, certainly not an Editor/Compiler option. An extra binary digit is included in the X2 v M2 chips, which is compensated by running the chips at a higher clock speed. And considerable PICaxe (re)development work would be required for the benefit of relatively few users.

It's disappointing if 3 x 4k bytes of Program space is needed for the Rubik code; I had hoped to use a single M2 slot for the core calculation, with the other bank for optically scanning the cube at the start, and UI / diagnostics, etc.. Perhaps speed can be traded against program size? The "procedures" appear to be around 20 steps each, whilst I believe I learned (>40 years ago and now forgotten) a method which used nearer to 10 steps per iteration. I've not looked in great detail at the code (attached above) and doubt if it all could be compacted 6-fold, but here are a few suggestions:

The diagnostics SERTXD strings are perhaps too much of a "Luxury", maybe use a subroutine with just a one-byte "reference" code number (and a paper crib sheet)? They appear to be consuming 1000 of the 4000 bytes.
Normally I recommend the ON .. GOTO {GOSUB} as offering the most efficient branching structure, but even the following could be "improved" a little:
Code:
DoMove:
  epointer = MoveNum
  Do
    Read epointer, RotNum
;    If RotNum > 0 then          ; ** Not required
        On RotNum Gosub x0_XX, x1_Rc, x2_Ra, x3_Fc, x4_Fa, x5_Uc, x6_Ua,_
                           x7_Lc, x8_La, x9_Bc, x10_Ba, x11_Dc, x12_Da
;    Endif
    Inc epointer
  Loop Until RotNum = 0          ; Conditional part may be unnecessary
x0_XX:              ; Or at an "Exception" trap/exit
  Return
I believe the following can be reduced considerably, assuming that the Lookup/Table space can be made available, perhaps saving around 500 bytes for 6 faces.
Code:
x3_Fc:    ' Front face clockwise    (and 5 others)
    Moved = 1
    Get 12, TempByte1
    Get 11, Tempbyte2
    Get 10, V : Put 12 , V 
    Get 13, V : Put 11 , V 
    Get 16, V : Put 10 , V 
    Get 17, V : Put 13 , V
    Get 18, V : Put 16 , V
    Get 15, V : Put 17 , V
    Put 18, TempByte1
    Put 15, TempByte2
    ' Edges
    Get 27, TempByte1
    Get 26, TempByte2
    Get 25, TempByte3
    Get 39, V : Put 27 , V 
    Get 42, V : Put 26 , V 
    Get 45, V : Put 25 , V 
    Get 46, V : Put 39 , V 
    Get 47, V : Put 42 , V
    Get 48, V : Put 45 , V 
    Get 34, V : Put 46 , V     
    Get 31, V : Put 47 , V 
    Get 28, V : Put 48 , V         
    Put 34, TempByte1
    Put 31, TempByte2 
    Put 28, TempByte3     
Return
Might be replaced by:
Code:
Symbol TempByte1 = 201    ; Or as available
Symbol TempByte2 = 202
Symbol TempByte3 = 203
Symbol X3FC = 0    ; Or start address of table
Table X3FC , (12,201 , 11,202 , 10,12 , 13,11 , 16,10 , 17,13 , 18,16 , 15,17 , 201,18 , 202,15)          ; Source,Dest pairs    
' then Edges
Table (27,201 , 26,202 , 25,203 , 39,27 , 42,26 , 45,25 , 46,39 , 47,42 , 48,45 , 34,46 , 31,47 , 28,48 , 201,34 , 202,31 , 203,28 , 0)
x3_Fc:
    w1 = X3FC
RotateFace:        ; Basic Subroutine
    Moved = 1
  Do
     ReadTable w1, b4 , b5
     If b4 = 0 then exit                 ; or Return
     Get b4 , V : Put b5 , V
     w1 = w1 + 2
  Loop   
  Return
EDIT: Or to save Table space (and using @{b}ptr ) :
Code:
Table X3FC , (12,10,16,18, 201 ,15,11,13,17, 201 , 28,25,45,48, 201 ,31,26,42,47, 201 ,34,27,39,46, 201, 0)    
x3_Fc:
ptr = 201         ; Temporary register
  Do
     ReadTable w1, b4
     Get b4 , @ptr
     Inc w1
     ptr = b4
  Loop Until b4 = 0
M2s have 512 bytes of Table memory (per Slot), but the table data could be pulled from an external I2C EEPROM if necessary.

Cheers, Alan.
 
Last edited:

matchbox

Senior Member
There have been lots of 'what we'd like to see in Picaxe', and one of mine would be an option to use the memory space as one big Slot, or stay with multiple little ones as we have now.
100% agree.
A little off topic.. But I wonder why RevEd didn't just go with 16K in one slot on the X2? And 4K on the M2's.
 

steliosm

Senior Member
IMO Picaxe's biggest limitation has become its old hardware. Not .Basic code format.
Why do you think PicAxe is old hardware? Could it be the lack of USB and/or WiFi/BT hardware on the chip? You can use co-processors for USB, WiFi and BT actually, so I don't really think this is a limitation.
 

hippy

Technical Support
Staff member
A little off topic.. But I wonder why RevEd didn't just go with 16K in one slot on the X2? And 4K on the M2's.
The issue there is, the more memory one has, the more bits are required to encode 'jump' instructions internally. That means code generated for larger memory takes up more space than code generated for smaller memories. You get more memory but your code uses more memory. It is probably a 'win' overall, but often not as great as one might expect.

It is quite tricky finding an ideal balance. I recall that's also why PICAXE have slots rather than one larger monolithic program space. Plus, having fixed 2K slots, means any code which fits in a slot on one PICAXE will fit into another slot on another PICAXE.
 

Buzby

Senior Member
Hi hippy, nice to see you back !

The main problem is not the #Slots in the 'real' Picaxe, it's the fact that the PE Simulator can't simulate them. This makes simulating a multi-slot programme very difficult, sometimes actually impossible.

One of the benefits we were told PE 6 was going to have was the ability for RevEd to add features and fixes into PE much more easily, due to the more modern structure of the code platform. Simulating #Slots would seem to be a basic feature that PE should have anyway.

In the revision history I can't see a single feature which has been added in response to a user request, although there are plenty fixes for real faults.

The features/fixes I requested are all simple to add, ( retentive break conditions, alternative terminal app, control character behaviour, etc ), but there no sign of them in PE.

Regarding the 'one big slot' option, I've mentioned before that the compiler could 're-write' the interpreter at download time, to optimise it by omitting unused functions. It could also change the interpreter to use 'long' pointers needed if the mem space is to used as one slot.

However, methinks this would be much more work than it's worth to RevEd, it's easier to fix the simulator.

Cheers,

Buzby
 

matchbox

Senior Member
It is quite tricky finding an ideal balance. I recall that's also why PICAXE have slots rather than one larger monolithic program space. Plus, having fixed 2K slots, means any code which fits in a slot on one PICAXE will fit into another slot on another PICAXE.
Thank you for the explanation. And its great to see you back.(y)

Why do you think PicAxe is old hardware? Could it be the lack of USB and/or WiFi/BT hardware on the chip? You can use co-processors for USB, WiFi and BT actually, so I don't really think this is a limitation.
Without going too deep into things. The PIC18 is lacking for its package size. By present silicon standards
As you stated. There are functions that would be nice to have integrated, as many new processors do. Back in 2011, it was a hardware/software balance, as Hippy spoke of.
If the same Picaxe bootstrap could be added to newer hardware with more memory. And functionality was upgraded to suit.... I for one, would be willing to spend more for new Picaxe chips to support the upgrade.

There are many thousands of libraries for other code formats. That make it rather easy to get almost any sensor and output working. By just interfacing them.
But I really like .BAS. Because I find it easier to write my own applications from scratch. Although that doesn't mean that other people will take same view as we do.
 
Last edited:

steliosm

Senior Member
Yes, there are thousands of libraries to interface e.g. arduino to various sensors, devices. This is because the arduino community is building, testing, trying and showing the results in forums and videos. We don't do that. We build things mainly for our own usage. We support the community by answering questions but only a handful of member are actually documenting their projects or even get into the trouble to make a video. The more projects out there the more ideas people will generate and will try to implement. If you look through the search results for arduino and picaxe related projects it looks like the arduino is able to do pretty much anything and picaxe is only able to turn leds on and off and sound a piezzo.

Can we change that?
 

matchbox

Senior Member
This is because the arduino community is building, testing, trying and showing the results in forums and videos. We don't do that. We build things mainly for our own usage. We support the community by answering questions but only a handful of member are actually documenting their projects or even get into the trouble to make a video.

Can we change that?
I do get your meaning.
I'm not a Youtube creator. But have thought about posting a few of my projects online. So as to show people what Picaxe can do.
But.. I'm not a real, look what I have done, type person. And my coding style rather abstract, and not orthodox, as the better codes here.
Plus, I have looked through all the finished projects on this forum. And notice that most of the ones I have posted. Haven't had much interest. So I assume that would likely reflect the view of much of the Youtube audience as well.

The biggest interest group on this forum, seems to surround robotics. Which I've not done any project on.
 

erco

Senior Member
Yes, there are thousands of libraries to interface e.g. arduino to various sensors, devices. This is because the arduino community is building, testing, trying and showing the results in forums and videos. We don't do that.

Can we change that?
I do it most every week, and yes sometimes it feels like I'm the only one. Picaxe is my only tool:

If Your Only Tool Is a Hammer Then Every Problem Looks Like a Nail
 
Last edited:

steliosm

Senior Member
@matchbox I believe most people in this forum are aiming for functional circuits with Picaxe and not just toys/gimmicks. They build circuits that will help them get jobs done.
@erco It does seem you are the only one who creates content on youtube for Picaxe at the moment. I use my personal site to upload content, but not all projects end up there and not all projects are completed :)
 

The bear

Senior Member
My Picaxe projects have all been to make life easier around the home. Prior to Picaxe I used Cmos 4000 series I.C's
Struggled with the programming, but really enjoying it. Thanks to the forum for all the help.
 

papaof2

Senior Member
@matchbox I believe most people in this forum are aiming for functional circuits with Picaxe and not just toys/gimmicks. They build circuits that will help them get jobs done.
@erco It does seem you are the only one who creates content on youtube for Picaxe at the moment. I use my personal site to upload content, but not all projects end up there and not all projects are completed :)
Functional - exactly. Robots and moving toys get attention. Industrial/commercial workhorses do not, such as an 08 using a DS18B20 to know when to turn the fan in an A/V cabinet on/off. Nothing pretty, fancy or "Gee Whiz!" but it's been running 15 years - and it's about time to replace the fan - again ;-)
I don't think a video of the LED flashing each time the 08 does a READTEMP and the fan spinning or not spinning would get many views :-(
 

erco

Senior Member
If you showed your code and described the application in the video, I'd watch! You gotta start somewhere.
 

hippy

Technical Support
Staff member
I don't think a video of the LED flashing each time the 08 does a READTEMP and the fan spinning or not spinning would get many views :-(
I'm not so sure. If published as an 'absolute beginner guide', showing how easy it is to code for such a simple but useful project, it might just encourage someone to have a go themselves.

The challenge has always been to get people hooked into electronics or programming, as a hobby or a career. Anything which can get them over the initial 'it's too complicated, it's all mumbo-jumbo, I couldn't do it, it's too expensive, and I wouldn't even know where to start', hurdles has to be worth it.

When I got my Philips Electronic Engineer kit from a school jumble sale, it was holding my hand over an LDR and having the light bulb come on which gave me my "wow" moment and carved out my destiny. So nothing is ever too simple or boring in my view. Even now I will look to see how one would do the simplest of things with the new kid on the block to get a feel for how easy it is likely to be to do anything more complicated.
 

steliosm

Senior Member
@papaod2 a blog post or even better a video to show how to build this project it really makes sense. People watching it might even realize that they need to build one for their own needs. I do get to watch a few YouTube videos on electronics. They give me ideas a out future projects, enhancements or even things I really need to make (e.g. a fume extractor).
 

erco

Senior Member
WRT getting people interested in the hobby, my own experience is that people gravitate to the simplest things. No one has any interest in how their cell phone works, but try showing them a simple item that makes them think "even I could to THAT". I purposely build quick things from found items where ever possible, wooden rulers, popsicle sticks, dollar toys, etc. When I have a table full of robots at a Maker Faire, the show stealer is always the stupid $5 line following robots I have orbiting the table. Because the chassis is a PCB with all 12 components visible, people constantly stop to see how they work.

 

hippy

Technical Support
Staff member
When I have a table full of robots at a Maker Faire, the show stealer is always the stupid $5 line following robots I have orbiting the table. Because the chassis is a PCB with all 12 components visible, people constantly stop to see how they work.
I suppose that's human nature. We all expect a thing jammed full of chips and costing a fortune to be able to do a lot and expect it to be jammed full of chips and cost a lot because that's what needed to do what it does. At the other end there are the things which are pretty much nothing at all which seem to be punching above their weight and it intrigues us, makes us wonder how, what the magic is which isn't immediately obvious.
 
Top