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

2.5s for tilt_emergency_millis might be too low #50

Open
alexvaut opened this issue Aug 7, 2023 · 5 comments
Open

2.5s for tilt_emergency_millis might be too low #50

alexvaut opened this issue Aug 7, 2023 · 5 comments

Comments

@alexvaut
Copy link

alexvaut commented Aug 7, 2023

TILT_EMERGENCY_MILLIS value of 2.5s is too high. In some cases, the ground is not flat and the robot is moving very slowly there. We need to allow users to setup their own value.

Implementation:
The only place I found where the firmware receives information is through ll_heartbeat structure where emergency flag can be reset. So I'm thinking to add a new field called tilt_emergency_millis, set in in mower_comms by reading an env var. The firmware will read and set it when it receives the heart beat. While I'm at it, I will probably set lift_emergency_millis as well. What do you think ?

@ClemensElflein
Copy link
Owner

yes, setting it through ROS would be nice

for the implementation I'd prefer a "config" message type to send these values. The reason is that we can extend it with more configuration later on and then don't get huge heartbeat messages.

My suggestion would be:

  • status message has a "configured" flag to tell ROS if configuration is needed
  • if ROS detects "configured == false" it sends the config message
  • configured keeps true as long as heartbeats are received
  • as soon as heartbeat stops, low level enters emergency and sets "configured = false" forcing ROS to reconfigure on next startup (user might have changed values)

@alexvaut
Copy link
Author

alexvaut commented Aug 8, 2023

@ClemensElflein agreed ! I will work on it as soon as I have some time. I need to figure out how to test it properly and quickly without relying on the robot... I'm a real newbie on ROS.

@ClemensElflein
Copy link
Owner

@alexvaut that's fairly easy as soon as you are able to compile the ROS workspace on your dev PC (if you have issues with it, ask. It should be pretty straight forward).

Basically once you are able to build the workspace, you can start roscore in a terminal and then run and debug the comms node standalone and pass the serial interface as command line parameter. It behaves like any other c++ project then.

If you have any questions, tagging me on Discord might be better suited for getting quick replies. I usually check my emails once per day max.

@alexvaut
Copy link
Author

alexvaut commented Aug 8, 2023

ok got it, I was trying to figure it out with ros simulation UI. Any plan to add unit tests ? :-) Or at least any unit test framework recommandation for ROS ? I really like the ROS model, each node should have its own test suite.

On a more complex subject, I would like to work in obstacle avoidance, my lawn has some tricky bumpy places and I need a recovery mechanism when the mower is stuck.

@ClemensElflein
Copy link
Owner

I see, there is no real simulation UI yet. There's the simulation mode which simulates a robot and you can have a look at the position and orientation using RVIZ. The buttons are controlled via shell script.

Test suite is a good point. I don't know about ROS, but I have successfully used googletest in the past. A quick search also shows that it's recommended to use it for ros: http://wiki.ros.org/Quality/Tutorials/UnitTesting

On the Discord at least two people have mentioned that they'd like to work on obstacle avoidance, if you are interested you can check with them in the open-mower-software channel. User PaddyCube was one of them, the other I can't remember. Maybe there's some progress.

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

2 participants