Hide and Seek Robots - Request for Comments

I uploaded a new video of a short game of hide and seek. @robotbuilder this one is for you!

That's pretty cool - and fun! 🙂

@thrandell

Thanks for the demo.  I will have to reread the thread to remind myself what is going on.

Wacko thought (humour): Put a husky lens on it, and it can bring food to the cat. 😉

@binaryrhyme ,My cat would probably try to eat it!...lol  He's a feral cat, lives outdoors, eats squirrels, rats, birds, and most anything he can catch...lol.. I only have to feed him once a day, in the morning, that way when we travel, my neighbor only has to check on him once or twice a week and make use he has water to drink, and occasionally feed him some treats. 

Finally got my HuskyLens working, It's great..although the programming is going to take a while to learn all the syntax, and how the command structure works..but I did find this link to the API:

https://github.com/HuskyLens/HUSKYLENSArduino/blob/master/HUSKYLENS%20Arduino%20API.md

Has a lot of useful information there..I've been playing around with it for a couple of days now, and I'm now looking to find that post from @oracid where he used in in line tracking mode on a tank robot so I can analyze the code..

Regards,

LouisR

@inst-tech Yeh, I'm intrigued. I'll have to give the documentation a read. Thanks for the link.

What impresses me is there is no plug in solution like a HuskyLens. Rather it is the inventive solutions that use sensor driven behaviours that result in goal outcomes.

As for feral cats they are a menace in Australia destroying our native species.

Noooooo, did I just see that 😲 , a robot project that gets to reach its project goal.  Most attempts (though with some heartening exceptions) seems to end up prey to the 'curse of the Robot' and seem to wither on their path to fulfilment.  

I've also fallen prey to the Robot curse, and there my bot sits as I type, its wheels dangling from its test cradle (whoops I must test that the battery has been kept charged).  I feebly give the excuse that its an outdoor bot and its a bit cold outside.

@dronebot-workshop whats been happening with your latest bots?  Has the Robot curse struck.  Its gone eerily silent on that front.

Ho-hum, I must try to do better in 2022,  good motivation @thrandell, and thanks for the video.

@byron 

I've also fallen prey to the Robot curse, and there my bot sits as I type, its wheels dangling from its test cradle ...

Similar problem.  I finally got around to testing counting encoder pulses per second to detect a collision and it worked. Took all of one hour to figure out some preliminary code. I have thought about it for years. 

@thrandell has been a motivator.

Posted by: @robotbuilder

I finally got around to testing counting encoder pulses per second to detect a collision and it worked.

Counting encoder pulses per second to detect a collision I think could indicate you are at the final 'fail safe' thoughts as I presume other actions would be taken to advert a collision prior to the prang.  So maybe you are almost there. 😀 

When it comes to counting pulses, its something I will be throwing in to my bots design. I'm thinking of using a separate board like a rpi pico just to keep up with the counting and passing summarised count info on demand to the main controller board.  Or maybe use a counter chip, but this seems a bit more complicated to one, like me, who is not sufficiently knowledgeable in circuit design.  In my case motor or wheel encoders will be counted to see how the bot may be biased. I'd be interested to hear if you have any thoughts on delegating the counting from the main controller board to another.

There you go, you've been a motivator too.  Like you I have had something I've been mentally chewing on for far too long (auto navigation the bot with GPS and Google Maps references) and I fished out the GPS sensors and have started find (or make) a suitable waterproof box to commence some experiments. 😎 

If @dronebot-workshop shows up with some GPS-RTK videos then I may well have to re-design, but I hesitate to get the rather expensive sensors until I'm convinced they would be worth the investment.

@byron Think about it this way, the wheels are producing pulses at a rate of some number per second, that number is unknown to me but I would guess from 10's to hundreds. The compute power of the board you are using is probably millions of ops per second. Does that sound like it needs help? BTW, transferring data and control to another board is waaaaay more than counting the pulses.

Posted by: @zander

The compute power of the board you are using is probably millions of ops per second

The video link below shows a small microprocessor being overwhelmed by counting motor pluses.

Although my bot control computer would be something like a raspberry pi, this may not be the best at counting with interrupts.  Together with all the rest of the sensor information being processed by the control board, GPS, heading, magnetometer, lidar, distance sensors, etc., then constantly calculating new a new compass bearings, sending telemetry, streaming camera data, and receiving instructions via wifi from a base computer not on the bot, and probably lots of other stuff too, then I do fear I my well find I do not have sufficient computing power to correctly capture each encoder pulse.  

As I would not be interested in the individual encoder pulses, but I may, on demand, like to read the current speed, or find the current cumulative difference between two different motor rotary encoders when both motors have been driven with the same PMW rate.  I'm thinking this may well be a good case for linking a dedicated board to do the pulse counting and keeping running totals etc. that could be sent via the likes of i2c or SPI comms as and when requested.   

At the moment this is just some high level design speculation that I'm chewing on, which may yet involve yet more even more dedicated microprocessors for the poor old bot to use.  So all and any input is welcome and thanks for you good observations and input. 👍 

@byron Without seeing the 'counting' code it's hard to determine why a MHz microprocessor is having difficulty. I was a computer performance expert and at one time held the world transaction record so I am fairly confident the code is at fault, the iron is likely capable of counting in its sleep. Adding the overhead of interfacing a Pico and retrieving the data will always be more expensive than natively doing it. I am curious however to find out how your project goes, keep us informed.

@byron 

Counting encoder pulses per second to detect a collision I think could indicate you are at the final 'fail safe' thoughts as I presume other actions would be taken to advert a collision prior to the prang.  So maybe you are almost there.  

Physical contact need not be a prang. Yes ideally you "see" the obstacle to avoid actual contact however actual contact is needed to manipulate an object.  If a robot has a sense of touch like us it could recognize an object and its orientation just by holding it even just touching part of it.

I think the @thrandell robots tag each other by physical contact.

Posted by: @robotbuilder

Physical contact need not be a prang

Hide and seek bots would probably be designed to physically tag with a quick nudge, but I was thinking, probably incorrectly, you were referring to your own bot.  And even then you may well be designing it to nudge walls and chair legs etc as it navigates about the place, so I must agree that not every nudge is a prang.  Anyway I'm looking forward to seeing how your prang bot progresses  (whoops lets call it a nudge bot). Motivation @robotbuilder,  motivation, keep the motivation.