Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Commenting out leads to reflash to stock fw #1

Open
Andoramb opened this issue Sep 10, 2019 · 5 comments
Open

Commenting out leads to reflash to stock fw #1

Andoramb opened this issue Sep 10, 2019 · 5 comments

Comments

@Andoramb
Copy link

Hi, how cool is this xD, I was just looking for this, thanks!

However, if I follow the description:

In /opt/rockrobo/cleaner/conf/ruby_chassis.cfg comment out the last two drivers, writelog and ruby_support.
Uncommenting those drivers (especially the writelog) causes several reboots and finally the robot flashes itself back to stock firmware :-/

  1. I tried to add provides ["log:2"] - instead of 0 and keep the previous writelog driver, but still causes a freeze.
  2. I also tried to change the location to /mnt/data/bumper.log to read out the file, and see how the bumper is logged.

ps.: it is also possible to use the script with cmus instead of sox:
ex. "cmus-remote -p" -> this way if you have a playlist, you can play sound clips randomly 💃

@Andoramb
Copy link
Author

Another thing that I observed:

create a new writelog driver, that outputs file to: log_directory "/run/shm/derp"
But then still read /dev/shm/PLAYER_fprintf.log from the script? (is that the same as log_directory "./logs"?)

@chk1
Copy link
Owner

chk1 commented Sep 11, 2019

To be honest I only tested it shortly, mine didn't reflash itself after several restarts although I might check what my robo is up to later (haven't started it in a few weeks). But I'm not running the latest firmware either..

create a new writelog driver, that outputs file to: log_directory "/run/shm/derp"
But then still read /dev/shm/PLAYER_fprintf.log from the script? (is that the same as log_directory "./logs"?)

Yeah that's something I didn't quite figure out, the output file is ignored for some reason and sensor output is written to PLAYER_fprintf.log

@Andoramb
Copy link
Author

Exactly! I managed to make it work with PLAYER_fprintf.log but it's a bit slow.

I found that you can also write driver based on Alsa, for example:

driver
(
  name "alsa"
  provides ["audio:0"]
  samples ["sample1.wav" "sample2.wav" "sample3.wav"]
  mixerfilters ["master" "pcm" "capture"]
)

And that is fine. but how to connect with
requires ["bumper:0"] - and based on a value (1), play the audio file?

Funny :)

@Ikfes
Copy link

Ikfes commented Aug 23, 2023

Hey, did you ever get this to work? xD

I intend to attempt this later on this weekend.

Which model works the best?

@chk1
Copy link
Owner

chk1 commented Aug 25, 2023

Sorry I can probably not help, I haven't run it again. I was using the first generation Xiaomi/Rockrobo vacuum at the time (the same model as in the 34C3 talk about rooting vacuums), I don't know if this still runs on newer firmwares since haven't updated/rooted my vacuum since 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants