From: Paul O. <new...@ki...> - 2007-09-28 09:43:42
|
Finally PJIIT has bought 10 roombas for me (European version with APS batteries and two virtual walls). I've prepared TTL->RS232C converter and connected one of them to PC. I've configured Player server taken from CVS and using playerv I was able to drive it to the docking station. The LED diode on docking station shows that the robot is recharging, but the Power LED diode on the robot didn't start to blink red (which means that robot is actually recharging). I was instantly reading Power interface using playerv and after about 15mins it was sure that it still consumes battery power and not recharging (60.1% -> 59.8%). It is quite sad for me, since as soon as I put small foxboard PC on every roomba, I want all my roombas to be completly autonomous. Is it any way (i.e. using opaque interface) to force it start recharging? Cheers, Paul |
From: Brian G. <br...@ge...> - 2007-09-28 15:57:05
|
On Sep 28, 2007, at 2:43 AM, Paul Osmialowski wrote: > Finally PJIIT has bought 10 roombas for me (European version with APS > batteries and two virtual walls). I've prepared TTL->RS232C > converter and > connected one of them to PC. I've configured Player server taken > from CVS > and using playerv I was able to drive it to the docking station. > The LED > diode on docking station shows that the robot is recharging, but > the Power > LED diode on the robot didn't start to blink red (which means that > robot > is actually recharging). I was instantly reading Power interface using > playerv and after about 15mins it was sure that it still consumes > battery > power and not recharging (60.1% -> 59.8%). It is quite sad for me, > since > as soon as I put small foxboard PC on every roomba, I want all my > roombas > to be completly autonomous. Is it any way (i.e. using opaque > interface) to > force it start recharging? I have never tried to recharge the Roomba while under computer control. Perhaps it won't recharge in certain modes. I would suggest researching the Roomba SCI API to see what needs to be done to make it charge. Hopefully there's a simple way to modify the driver so that it charges whenever docked, without any client-side work (patches accepted, as usual). brian. |
From: Paul O. <new...@ki...> - 2007-09-28 18:31:25
|
On Fri, 28 Sep 2007, Brian Gerkey wrote: > > On Sep 28, 2007, at 2:43 AM, Paul Osmialowski wrote: > >> Finally PJIIT has bought 10 roombas for me (European version with APS >> batteries and two virtual walls). I've prepared TTL->RS232C >> converter and >> connected one of them to PC. I've configured Player server taken >> from CVS >> and using playerv I was able to drive it to the docking station. >> The LED >> diode on docking station shows that the robot is recharging, but >> the Power >> LED diode on the robot didn't start to blink red (which means that >> robot >> is actually recharging). I was instantly reading Power interface using >> playerv and after about 15mins it was sure that it still consumes >> battery >> power and not recharging (60.1% -> 59.8%). It is quite sad for me, >> since >> as soon as I put small foxboard PC on every roomba, I want all my >> roombas >> to be completly autonomous. Is it any way (i.e. using opaque >> interface) to >> force it start recharging? > > I have never tried to recharge the Roomba while under computer > control. Perhaps it won't recharge in certain modes. I would > suggest researching the Roomba SCI API to see what needs to be done > to make it charge. Hopefully there's a simple way to modify the > driver so that it charges whenever docked, without any client-side > work (patches accepted, as usual). > > brian. Hi Brian, I've quickly looked at SCI API and there are three things that make it possibe: 1. first byte of sensors packet subset 3 tells the charging state. If it is different than zero, it means that one of recharging actions is taking place. 2. Command code 143 (Force-Seeking-Dock) makes roomba searching the base 3. Command code 133 (Power) puts roomba into sleep mode. I'm not sure about it yet, but I guess it can force roomba to recharge. Then setting RTS line to 0 for 500ms wakes it up. Months ago I've prepared little deamon called lowpower for my P2DX which was just a Player client that was reading power interface and if the voltage went down below defined threshold for longer than defined lenght of time it caused onboard PC to shutdown (just to protect the mainboard and Linux filesystem). My idea is to write something like that for roomba: the daemon after discovering that the voltage is too low would kill Player server, then it would connect to the serial port directly (using termios) and call Force-Seeking-Dock command. Then it would monitor "charging state" and when it is non-zero it would put roomba into sleep mode and freeze itself for about 3 hours, then it would wake up roomba and restart the Player server. Whole idea sounds easy to implement, no need to patch anything, the only thing to do is to add missing piece of software. I'm not sure I'll find enough time next week to make it work, but I'll try to do so as soon as possible. The problem is that I'm not sure that recharging subsystem in roomba works that way. The very first step is to write some piece of C code (using termios.h) that would monitor "charging state" in diffrent cases (for example, what would happend if we put fully recharged roomba on the docking station, and other situations). Quite boring job... At first I was thinking about adding new configuration requests to the Power interface that would make things described above possible without killing Player server. Then I realised that it would be quite dangerous to allow other Player clients to connect to it and drive roomba off-the-base during the recharging, or to disturb while seeking for the docking station. Cheers, Paul |
From: Paul O. <new...@ki...> - 2007-10-01 16:39:22
|
> I've quickly looked at SCI API and there are three things that make it > possibe: > 1. first byte of sensors packet subset 3 tells the charging state. If it > is different than zero, it means that one of recharging actions is taking > place. > 2. Command code 143 (Force-Seeking-Dock) makes roomba searching the base > 3. Command code 133 (Power) puts roomba into sleep mode. I'm not sure > about it yet, but I guess it can force roomba to recharge. Then setting > RTS line to 0 for 500ms wakes it up. > Months ago I've prepared little deamon called lowpower for my P2DX which > was just a Player client that was reading power interface and if the > voltage went down below defined threshold for longer than defined lenght > of time it caused onboard PC to shutdown (just to protect the mainboard > and Linux filesystem). My idea is to write something like that for roomba: > the daemon after discovering that the voltage is too low would kill Player > server, then it would connect to the serial port directly (using termios) > and call Force-Seeking-Dock command. Then it would monitor "charging > state" and when it is non-zero it would put roomba into sleep mode and > freeze itself for about 3 hours, then it would wake up roomba and restart > the Player server. > Whole idea sounds easy to implement, no need to patch anything, the only > thing to do is to add missing piece of software. I'm not sure I'll find > enough time next week to make it work, but I'll try to do so as soon as > possible. The problem is that I'm not sure that recharging subsystem in > roomba works that way. The very first step is to write some piece of C > code (using termios.h) that would monitor "charging state" in diffrent > cases (for example, what would happend if we put fully recharged roomba on > the docking station, and other situations). Quite boring job... > I've found the time to make some tests today. My idea is quite correct, it is possible to do it that way. Unfortuantely, there's a problem when I have 10 docking stations (each for one robot) and the robot forced to go home cannot decide which one to choose; finally it stops in the middle between them and blink two button leds (I don't know what this state is called). So basically, my idea is good whenever there's only one docking station in the reach. Cheers, Paul |
From: Brian G. <br...@ge...> - 2007-10-03 01:02:05
|
hi Paul, Is there any way to incorporate this behavior into the roomba driver itself? That would be easier for most people to use than an external daemon. brian. On Oct 1, 2007, at 9:12 AM, Paul Osmialowski wrote: > > >> I've quickly looked at SCI API and there are three things that >> make it >> possibe: >> 1. first byte of sensors packet subset 3 tells the charging state. >> If it >> is different than zero, it means that one of recharging actions is >> taking >> place. >> 2. Command code 143 (Force-Seeking-Dock) makes roomba searching >> the base >> 3. Command code 133 (Power) puts roomba into sleep mode. I'm not sure >> about it yet, but I guess it can force roomba to recharge. Then >> setting >> RTS line to 0 for 500ms wakes it up. >> Months ago I've prepared little deamon called lowpower for my P2DX >> which >> was just a Player client that was reading power interface and if the >> voltage went down below defined threshold for longer than defined >> lenght >> of time it caused onboard PC to shutdown (just to protect the >> mainboard >> and Linux filesystem). My idea is to write something like that for >> roomba: >> the daemon after discovering that the voltage is too low would >> kill Player >> server, then it would connect to the serial port directly (using >> termios) >> and call Force-Seeking-Dock command. Then it would monitor "charging >> state" and when it is non-zero it would put roomba into sleep mode >> and >> freeze itself for about 3 hours, then it would wake up roomba and >> restart >> the Player server. >> Whole idea sounds easy to implement, no need to patch anything, >> the only >> thing to do is to add missing piece of software. I'm not sure I'll >> find >> enough time next week to make it work, but I'll try to do so as >> soon as >> possible. The problem is that I'm not sure that recharging >> subsystem in >> roomba works that way. The very first step is to write some piece >> of C >> code (using termios.h) that would monitor "charging state" in >> diffrent >> cases (for example, what would happend if we put fully recharged >> roomba on >> the docking station, and other situations). Quite boring job... >> > I've found the time to make some tests today. My idea is quite > correct, it > is possible to do it that way. Unfortuantely, there's a problem when I > have 10 docking stations (each for one robot) and the robot forced > to go home cannot decide which one to choose; finally it stops in the > middle between them and blink two button leds (I don't know what this > state is called). So basically, my idea is good whenever there's > only one > docking station in the reach. > Cheers, > Paul > > ---------------------------------------------------------------------- > --- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Paul O. <new...@ki...> - 2007-10-03 07:21:06
|
On Tue, 2 Oct 2007, Brian Gerkey wrote: > hi Paul, > > Is there any way to incorporate this behavior into the roomba driver > itself? That would be easier for most people to use than an external > daemon. > > brian. Brian, It should affect somehow whole roomba driver and I guess it is possible to do that. Before start forced docking, Roomba should be switched to one of cleaning modes for a few seconds (Clean, Spot or Max, I was setting it for 4 seconds, if this period is too short cleaning cycle may be still initializing and docking command is ignored). During this cleaning initialization and during home base seeking all position commands should be ignored. I guess Roomba driver can be modified that way. My proposal is: 1. Add new configuration option to roomba driver: voltage threshold (real value which defaults to 0.0); if voltage is below the threshold, home seeking mode is started (as described below); if the threshold value is 0.0 no threshold checking is done 2. Whenever voltage goes below the non-zero threshold: - some integer variable (initialized with 0) is incremented (whenever this variable value is non-zero, all position command sent by any subscribed client are ignored!) - clean mode command is sent to Roomba; current time should be stored in some time_t variable; Roomba driver is going back to its main loop. - in the main loop, whenever some integer variable value mentioned above is 1, current time is compared with some time_t variable value (also mentioned above) - if the difference is greater than 4 seconds, home seeking command is sent to Roomba and the value of some integer variable mentioned above is incremented; then back to the main loop - in the main loop, whenever some integer variable value mentioned above is 2, charge state of Roomba is checked; if it is non-zero, some integer variable value mentioned above should be incremented again; then back to the main loop ## This place differs from my previous experience: Whenever I dock Roomba just by driving it to the home base (using playerv) it can't start to recharge until I press Power button manually. However when I force it to seek home by sending home-seek command, when it finally approach home base it starts to recharge by itself and the charge state received is 2) ## - in the main loop, whenever some integer variable value mentioned above is 3, charge state of Roomba is checked; if it is zero, some integer variable mentioned above should be reset to zero; also RTS line may be set to 0 for 500ms to make sure Roomba is not sleeping and is able to receive commands (also init commands may be sent again, it should not hurt Roomba's OS). We may also try to drive it off the docking station when it is fully recharged (just by turning on cleaning cycle for about 10 seconds), however roomba should be placed in docking station when it is not used, so I guess it would be better to leave it there. We're still waiting for our ordered foxboards from Acme systems. Until then I'm driving roomba just by using serial cable which is not safe at all, so I couldn't make many tests with home-seeking command. If you wish I can modify Roomba driver as described above soon, but I guess not before foxboards are here. Cheers, Paul > > On Oct 1, 2007, at 9:12 AM, Paul Osmialowski wrote: > >> >> >>> I've quickly looked at SCI API and there are three things that >>> make it >>> possibe: >>> 1. first byte of sensors packet subset 3 tells the charging state. >>> If it >>> is different than zero, it means that one of recharging actions is >>> taking >>> place. >>> 2. Command code 143 (Force-Seeking-Dock) makes roomba searching >>> the base >>> 3. Command code 133 (Power) puts roomba into sleep mode. I'm not sure >>> about it yet, but I guess it can force roomba to recharge. Then >>> setting >>> RTS line to 0 for 500ms wakes it up. >>> Months ago I've prepared little deamon called lowpower for my P2DX >>> which >>> was just a Player client that was reading power interface and if the >>> voltage went down below defined threshold for longer than defined >>> lenght >>> of time it caused onboard PC to shutdown (just to protect the >>> mainboard >>> and Linux filesystem). My idea is to write something like that for >>> roomba: >>> the daemon after discovering that the voltage is too low would >>> kill Player >>> server, then it would connect to the serial port directly (using >>> termios) >>> and call Force-Seeking-Dock command. Then it would monitor "charging >>> state" and when it is non-zero it would put roomba into sleep mode >>> and >>> freeze itself for about 3 hours, then it would wake up roomba and >>> restart >>> the Player server. >>> Whole idea sounds easy to implement, no need to patch anything, >>> the only >>> thing to do is to add missing piece of software. I'm not sure I'll >>> find >>> enough time next week to make it work, but I'll try to do so as >>> soon as >>> possible. The problem is that I'm not sure that recharging >>> subsystem in >>> roomba works that way. The very first step is to write some piece >>> of C >>> code (using termios.h) that would monitor "charging state" in >>> diffrent >>> cases (for example, what would happend if we put fully recharged >>> roomba on >>> the docking station, and other situations). Quite boring job... >>> >> I've found the time to make some tests today. My idea is quite >> correct, it >> is possible to do it that way. Unfortuantely, there's a problem when I >> have 10 docking stations (each for one robot) and the robot forced >> to go home cannot decide which one to choose; finally it stops in the >> middle between them and blink two button leds (I don't know what this >> state is called). So basically, my idea is good whenever there's >> only one >> docking station in the reach. >> Cheers, >> Paul >> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Paul O. <new...@ki...> - 2007-10-05 12:42:46
|
I've prepared new version of roomba driver that behaves as described in my previous message. It is totally untested, since now I have no means to test it, it will wait a week or so. Before I've added new features to roomba_driver.cc I had to add missing roomba_forcedock function into roomba_comms.c (roomba_comms.h). This code is based on Player CVS snapshot taken 04th of October 2007. It compiles fine and runs with such a configuration file: driver ( name "roomba" provides ["position2d:0" "power:0" "bumper:0" "ir:0" "opaque:0"] port "/dev/ttyS0" safe 1 battery_threshold 90.0 ) Cheers, Paul > > On Tue, 2 Oct 2007, Brian Gerkey wrote: > >> hi Paul, >> >> Is there any way to incorporate this behavior into the roomba driver >> itself? That would be easier for most people to use than an external >> daemon. >> >> brian. > Brian, > > It should affect somehow whole roomba driver and I guess it is possible > to do that. Before start forced docking, Roomba should be switched to one > of cleaning modes for a few seconds (Clean, Spot or Max, I was setting it > for 4 seconds, if this period is too short cleaning cycle may be still > initializing and docking command is ignored). During this cleaning > initialization and during home base seeking all position commands should > be ignored. I guess Roomba driver can be modified that way. My proposal > is: > 1. Add new configuration option to roomba driver: voltage threshold > (real value which defaults to 0.0); if voltage is below the threshold, > home seeking mode is started (as described below); if the threshold value > is 0.0 no threshold checking is done > 2. Whenever voltage goes below the non-zero threshold: > - some integer variable (initialized with 0) is incremented (whenever this > variable value is non-zero, all position command sent by any subscribed > client are ignored!) > - clean mode command is sent to Roomba; current time should be stored in > some time_t variable; Roomba driver is going back to its main loop. > - in the main loop, whenever some integer variable value mentioned above > is 1, current time is compared with some time_t variable value (also > mentioned above) - if the difference is greater than 4 seconds, home > seeking command is sent to Roomba and the value of some integer variable > mentioned above is incremented; then back to the main loop > - in the main loop, whenever some integer variable value mentioned above > is 2, charge state of Roomba is checked; if it is non-zero, some integer > variable value mentioned above should be incremented again; then back to > the main loop > ## > This place differs from my previous experience: Whenever I dock Roomba > just by driving it to the home base (using playerv) it can't start to > recharge until I press Power button manually. However when I force it to > seek home by sending home-seek command, when it finally approach home base > it starts to recharge by itself and the charge state received is 2) > ## > - in the main loop, whenever some integer variable value mentioned above > is 3, charge state of Roomba is checked; if it is zero, some integer > variable mentioned above should be reset to zero; also RTS line may be set > to 0 for 500ms to make sure Roomba is not sleeping and is able to receive > commands (also init commands may be sent again, it should not hurt > Roomba's OS). > > We may also try to drive it off the docking station when it is fully > recharged (just by turning on cleaning cycle for about 10 seconds), > however roomba should be placed in docking station when it is not used, so > I guess it would be better to leave it there. > > We're still waiting for our ordered foxboards from Acme systems. Until > then I'm driving roomba just by using serial cable which is not safe at > all, so I couldn't make many tests with home-seeking command. If you wish > I can modify Roomba driver as described above soon, but I guess not before > foxboards are here. > > Cheers, > Paul > >> On Oct 1, 2007, at 9:12 AM, Paul Osmialowski wrote: >> >>> >>>> I've quickly looked at SCI API and there are three things that >>>> make it >>>> possibe: >>>> 1. first byte of sensors packet subset 3 tells the charging state. >>>> If it >>>> is different than zero, it means that one of recharging actions is >>>> taking >>>> place. >>>> 2. Command code 143 (Force-Seeking-Dock) makes roomba searching >>>> the base >>>> 3. Command code 133 (Power) puts roomba into sleep mode. I'm not sure >>>> about it yet, but I guess it can force roomba to recharge. Then >>>> setting >>>> RTS line to 0 for 500ms wakes it up. >>>> Months ago I've prepared little deamon called lowpower for my P2DX >>>> which >>>> was just a Player client that was reading power interface and if the >>>> voltage went down below defined threshold for longer than defined >>>> lenght >>>> of time it caused onboard PC to shutdown (just to protect the >>>> mainboard >>>> and Linux filesystem). My idea is to write something like that for >>>> roomba: >>>> the daemon after discovering that the voltage is too low would >>>> kill Player >>>> server, then it would connect to the serial port directly (using >>>> termios) >>>> and call Force-Seeking-Dock command. Then it would monitor "charging >>>> state" and when it is non-zero it would put roomba into sleep mode >>>> and >>>> freeze itself for about 3 hours, then it would wake up roomba and >>>> restart >>>> the Player server. >>>> Whole idea sounds easy to implement, no need to patch anything, >>>> the only >>>> thing to do is to add missing piece of software. I'm not sure I'll >>>> find >>>> enough time next week to make it work, but I'll try to do so as >>>> soon as >>>> possible. The problem is that I'm not sure that recharging >>>> subsystem in >>>> roomba works that way. The very first step is to write some piece >>>> of C >>>> code (using termios.h) that would monitor "charging state" in >>>> diffrent >>>> cases (for example, what would happend if we put fully recharged >>>> roomba on >>>> the docking station, and other situations). Quite boring job... >>>> >>> I've found the time to make some tests today. My idea is quite >>> correct, it >>> is possible to do it that way. Unfortuantely, there's a problem when I >>> have 10 docking stations (each for one robot) and the robot forced >>> to go home cannot decide which one to choose; finally it stops in the >>> middle between them and blink two button leds (I don't know what this >>> state is called). So basically, my idea is good whenever there's >>> only one >>> docking station in the reach. >>> Cheers, >>> Paul >>> >>> ---------------------------------------------------------------------- >>> --- >>> This SF.net email is sponsored by: Microsoft >>> Defy all challenges. Microsoft(R) Visual Studio 2005. >>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >>> _______________________________________________ >>> Playerstage-users mailing list >>> Pla...@li... >>> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Playerstage-users mailing list >> Pla...@li... >> https://lists.sourceforge.net/lists/listinfo/playerstage-users >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users |
From: Chad G. <ch...@mg...> - 2007-09-28 18:06:31
|
I've been working with the iRobot Create. And I've noticed that it doesn't like the player driver connected to it while its charging. It plays the "connect" song but it sounds all muffled and then it locks up. I also think you have to take it out of command mode for it to charge correctly. Which seems odd since there is charging data available through the serial API. If you can make use of the on/off pin that is on the DB25 connector, that should be sure way of getting it into "charging" mode and then waking it up later to check the status of the charge. -Chad On 9/28/07, Brian Gerkey <br...@ge...> wrote: > > On Sep 28, 2007, at 2:43 AM, Paul Osmialowski wrote: > > > Finally PJIIT has bought 10 roombas for me (European version with APS > > batteries and two virtual walls). I've prepared TTL->RS232C > > converter and > > connected one of them to PC. I've configured Player server taken > > from CVS > > and using playerv I was able to drive it to the docking station. > > The LED > > diode on docking station shows that the robot is recharging, but > > the Power > > LED diode on the robot didn't start to blink red (which means that > > robot > > is actually recharging). I was instantly reading Power interface using > > playerv and after about 15mins it was sure that it still consumes > > battery > > power and not recharging (60.1% -> 59.8%). It is quite sad for me, > > since > > as soon as I put small foxboard PC on every roomba, I want all my > > roombas > > to be completly autonomous. Is it any way (i.e. using opaque > > interface) to > > force it start recharging? > > I have never tried to recharge the Roomba while under computer > control. Perhaps it won't recharge in certain modes. I would > suggest researching the Roomba SCI API to see what needs to be done > to make it charge. Hopefully there's a simple way to modify the > driver so that it charges whenever docked, without any client-side > work (patches accepted, as usual). > > brian. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Playerstage-users mailing list > Pla...@li... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > |
From: Paul O. <new...@ki...> - 2007-09-28 18:34:25
|
> If you can make use of the on/off pin that is on the DB25 connector, > that should be sure way of getting it into "charging" mode and then > waking it up later to check the status of the charge. > > -Chad I can use that and I guess I'll do that (details in my reply for Brian post). Cheers, Paul |