Forum Replies Created
ScratchCrumble 0.4 can now control the sparkles 🙂
If you can’t wait for native support – 4Tronix have produced a Servo Crumb
SimonAugust 26, 2015 at 7:18 am in reply to: Proximity and PIR Crumb sensors seem temperamental #2587
Ye -same problem with Proximity Crumb when I tried last term. I think 4Tronix wer egoign to make them a bit less sensitive for future batches. All IR sensors have the same problem but since these are normally sitting up on a desk – they are subject to a lot of ambient light.
An old trick with these sort of sensors is to get a small black rubber tube and place over sensor so that they become much more directional but I’ve not tried that yet with these ones but that technique has proved effective on robots with IR sensors.
Re PIR sensors – ALL PIR seem to behave randomly (due to the rate of change of signal principle that they work on)
They are designed to work at a distance so you have to program them on trust – mount them in position – move well away – then approach and see what happens. They detect lateral movement much more than to and from
What the situation is that the Crumble is obviously a commercial piece of kit and the software that it runs isn’t opensource.
Joseph has let me incorporate some python libs into my project so I can talk to the Crumble and at the moment I’m “hiding” these by only distributing an .exe.
I believe/think/hope that eventually these libs will be opened up but that’s a matter for Joseph
Yep – the Crumble outputs can drive plain LEDs
Version 0.3 – changed inputs to CrumbleA/B/C/D (outputs still just A/B/C/D) prob going to play around further
Thanks very much for all your efforts and feedback
I think I’ll have a play around with sensor naming to minimise possible confusion
em – I’m very confused by your description of sensor values
Using latest test script
my screen looks like this
4 sensor values A,B,C and D that respond to each leg
Just tried it out back at the school where is was failing and its run for an hour with no events so hopefully its fixed but I need confirmation from others 🙂
Well overnight – no crashes or dropouts on my dev machine running the exe 🙂
Ok – I had a thought that it might be clashing between threads so I’ve added some locks to the I/O routines and it lasted up to 4700 on my setup here without any errors (but of course I may have just been lucky)
Anyway – its back to the old packaging system for V0.2.1
Try it and see what happens please
OK this is now test script to record events
and export of record list which shows about 4/5 events
OK ran same Scratch routine but running ScratchCrumble.py direct from my Pycharm IDE and it lasted till 1500 secs before exceeding the 100 count.
I’m thinking that could just be an accumulation of 100 blips rather than a fail at 1500 sec – I’ll need to write a better Scratch logger to see if that’s true
Nah – just leaving it alone and it goes off-piste!
Lets try using this as test routine – out of 4 runs – maximum time it lasted was 80 secs
mm – just tried it on one of my schools on the w2k8 server (as thats the machine I sit at) and it did perculier things
Starts off ok with D connected to A -leave it a few minutes – fine
But very shortly after connecting B to D as well, it starts thinking A is LO and then just stops responding
I think I’ve have to do some native Python tests (without Scratch) just to make sure the basics are working