-
Notifications
You must be signed in to change notification settings - Fork 1
Considerations
Parker Lusk edited this page Nov 19, 2016
·
3 revisions
Things we learned, thought about, and wished we had done differently.
- Max Current limit. This may prevent damaging the motors / RoboClaws
- We didn't limit voltage / current to the RoboClaws/Motors. The motors were spec'ed for 12v, but the batteries ran as high as 16v (we didn't run motors at full speed). We burned out two RoboClaw v3; the max current limiting may have helped.
- Don't let the robot drive up against the wall, this is how we burned out a RoboClaw.
- One team used an Observer to estimate states and tell the robots what kind of velocity they need in order to get to the desired point. We just used a PID controller (well, really just a 'P' controller). It would be cool to do a state-space / Observer-based controller. You can measure inertia by how it is related to the frequency of oscillation if you hang your robot from a string and watch it rotate back-and-forth.
- We implemented a LPF and a Kalman filter. Have a way to quickly tune your parameters without having to run the robots on the field. We had a script in our
tests/estimation
folder to help with this. - It would be cool to get the Kalman filter working. We have the code, we just didn't have the time.
- Visualizing the data (raw camera data vs estimated position / position / future position) was powerful.
- Take the time to read through the Gentle Intro to ROS book. It will be very worth it to try and understand it before building your system.
- We split everything up into modular services. This was nice for silo'ing functionality and being able to probe the connections between the nodes using the
Chicken McThuggets Command Center
. However, it would be interesting to implement the robot code in one Python node to compare speed/performance. We didn't really struggle with any, but there have been times when I wondered if making our nodes run at >100Hz would make motion better. I would also be curious to compare Python ROS vs C++ ROS. - We chose Python ROS for ease of testing and prototyping functionality. Those prototypes become actual code. Python is nice because of
numpy
,scipy
, andmatplotlib
; though similar libraries exist for C++. - Spend time drawing out the nodes and figuring out how they should effectively communicate. Use
rqt_graph
to help visualize this.
-
A*
>Dijkstra
for Robot Soccer (typically).A*
is much faster and is ideal in situations where the robot knows where you want to go. The heuristic pulls you toward your goal by minimizing euclidean distance (or other heuristic). WhereasDijkstra's
is good for exploring what's all around you if you don't know where you want to go.
- Get started early. There will be lots of problems and you will need lots of time to get it right.
- Try to spend all your money (i.e., don't be afraid of redoing something to make it better).
- Clean wiring prevents shorts and other crazy problems. That's why we went with vector boards at first, and then created PCBs from those.
- The First Order used SolidWorks to build their robot in assembly view. It was pretty nice. But SVGs, laser cutters, and acrylic win championships. 😉
- Think about using UDP instead of TCP (especially for the camera server stuff that your vision node subscribes to). That way, you can drop frames just fine and won't have too much latency. TCP buffers and wants you to have every detail, thus creating lag if you get behind.
- Use the Gazebo simulator.
- The
Command Center
helped immensely. Use it, or build something like it. Having a way to control the game (i.e., pressspacebar
to have the robots go back to their home positions) is super nice because you don't have to interact with the robots physically during competitions. It makes it look really clean at the final competition. - Use
bash
scripts and other tools to setup your environment correctly. That way, you can simply type in commands into the terminal to kick off big tasks for you. See thescripts/
directory for more ideas.