IDP software talk

Teams and Scheduling

One team managed to write 3000 lines, but you needn't write much code. It's up to you. The vacation Mars Lander exercise was supposed to be preparation for this task.
Manage Expections - In the first ever Mich competition, 8 teams (out of 12) got 0. Why 0? Because we didn't give negative points. In the first 2021 M1 competition, 4 teams got 0.
Feedback last year not infrequently mentioned difficulties with distributing the workload in a standard credit culture. The Software team (especially in the final week) can end up having to compensate for problems elsewhere. Plan accordingly.
Rapid Prototyping implies not waiting for the final chassis to appear before running your code. Use cardboard if necessary. Bolt 2 strips of metal together and slobber it with tape. Get the robot moving and turning as soon as possible.
GitLab (like you used in the 1A Lent Python course) is an option. There's now a Cambridge University offering - see https://gitlab.developers.cam.ac.uk/ which also has utilities as such The GitLab Issue Board (can be used as a Kanban or a Scrum board)

Testing

Testing isn't a contingency measure. It should be integrated into your programs and procedures. If 80% of your time is going to be spent testing and debugging, anything that facilitates testing is worth doing.

Investigate. Maybe you could begin as you did with Lego, investigating the capabilities of each device. Use realistic settings - for example, the ultra-sound and light sensors may be affected by people crowding around tables. The glossy black paint used on the tables isn't the same as the dull black paper you may be testing on.
Try to produce measurable outcomes. What's the robot's fastest speed? How many software loops can be run per second?
Develop a test suite. Don't assume that once your robot has passed a test, it won't fail in future. Can your robot do 4 90° turns and return to the start? If so, keep the test program and try it whenever chassis loading changes. Try it at the start of each session.
Test early. Design for easy testing. Test whether components are still alive! (quite often they get damaged)
Write test suites so that others can use without you being around. You shouldn't need to be present when mechanics test their pick-up mechanism. Provide easy ways for them to tweak parameters in the code if necessary.
Devise test procedures to deal with common problems. For example, suppose your robot starts failing because one motor has stopped. Is it a hardware, software or electronics problem? Try
- Plugging a battery into a motor directly
- Swapping the motors around to see if the same one stops
- Taking off all the electronics boards and trying your first motor test program again

Integration

Rapid Prototyping implies constant integration - don't leave all the integration to the end, on the assumption that it will be straightforward. Software tweaks can't fix everything.

Adding superstructure affects light conditions and balance.
Motor interference can affect sensors
Components may physically get in each other's way
Metal conducts! One team blew 3 Arduinos before realising that their metal chassis conducted
If you draw too much power from the Arduino (adding a servo, for example) the Arduino can brown out, causing mysterious symptoms.

Programming

Check that you can download and run a simple program from the development environment you want to use (maybe your laptop) to the Arduino you'll eventually be using (the one with WiFi). Teams sometimes find that downloading fails between certain laptops and Arduinos. The sooner you check this the better.
Roughly 2-4 teams use Python (using the Arduino as a slave). Number-crunching is better on a laptop. But you only need number-crunching if you're using the camera.
The online Ardino examples (especially Dr Crisp's examples on Moodle) are the places to start. The Ardino IDE (Integrated Development Environment)) on Linux is well behind the Windows version. The environment's slightly quirky. Code that wouldn't normally work compiles because the Arduino IDE does some magic behind the scenes - see
- What does the IDE change in my sketch
- Arduino Build Process
for details.
If there's more than one library available to support sensors, servos, etc, it may be worth investigating the options. For example, some libraries might filter out anomalous blips in ultra-sound readings. Note that the library for using servos is generic - its notion of a degree may not match reality.
The following documents may also be useful -
- Using Multiple files
- Interrupts

Navigation issues

Many options

Camera
Use the onboard IMU (Inertial Measurement Unit) with a 3-axis accelerometer, a 3-axis gyroscope
Record commands to motors - so you can re-run in reverse?
Use Optical encoders
Use right-angles and known navigational points (walls, corners, etc)
Line-following - In real life (warehouses, etc) line-following is used when possible. My line-following page has a few tips collected from the WWW, but you might well find better resources if you search for yourself. There's useful Line following information on the Moodle page too. Note that a robot that follows a line well going forward may fail when reversing.

Programming tips

Don't trust a single reading - a spike may be an anomaly. Maybe take the median of the last few readings? Or use a moving average?
Never get stuck - in a loop, or against a wall. For example, suppose your robot has to keep going until it gets within "10" units from a wall. Doing
```
while distance>10:
   distance=sensor_reading()
```
is risky - suppose the distance is always more than 10? In the first year, your Python loops often counted how many times they were excuting, like this, so that you couldn't get stuck.
```
count=0
while distance>10 and count<10000:
   distance=sensor_reading()
   count=count+1
if count==10000:
   # Never got close. Time for plan B
```
Or you could timeout after a prescribed time.
Don't generate unnecessary traffic. Suppose you're trying to follow a line. You might have C++ code like this
```
while (x=readsensors()) {
   if (x==TOO_FAR_LEFT) {
      rightmotor(40);
      leftmotor(50);
   }
   else if (x==TOO_FAR_RIGHT) {
      rightmotor(50);
      leftmotor(40);
   }
   else {
      rightmotor(40);
      leftmotor(40);
   }    
}
```
The problem with this is that if the loop is run a 100 times a second, and the robot stays on the line, the motors are being unnecessarily told a 100 times a second to go at 40. As well as filling the wifi bandwidth, you risk overworking the arduino boards. You need only send commands to the motors when their speed needs to change. This isn't hard to do. For example, if rightmotor is written like this -
```
int old_rightmotor_speed=0;
...
void rightmotor(int newspeed) {
  if (newspeed==old_rightmotor_speed)
     return;
  else {
     // send a command that sets the right motor speed to the new speed, then ...
     old_rightmotor_speed=newspeed;
  }
}
```
- then the motor is only sent commands when necessary, which can reduce network traffic by orders of magnitude.

Camera

CAMERAS ARE NOT AVAILABLE DURING MICH 2023

Cameras on different tables may be different models and have greatly different reponse times. Note that

You can take a still at the start, stills on demand, or use video (see a video), but check Frames/sec rate. The fastest connection to the cameras is using the EIETL computers.
Teams use openCV (or simpleCV). Note that a short, simple-looking program can involve heavy CPU load.
One year the winning team investigated the use of the camera then rejected it. In 2020 L2 the top 3 teams used the camera. In 2020 L1 3 of the 4 bottom teams used the camera.

Wifi and Bluetooth

Not a necessity. Useful for debugging
Start with simple examples - for WiFi see the Wifi section of the Arduino examples. Beware of security issues - you don't want other teams taking over your robot. Have a look at the remoteIP() function of client, etc.
If you're using UDP, remember that by design it's not reliable (one team found that the computer-to-arduino route was much more reliable than the other direction. 3 signals/sec might be the highest reliable rate).

Hot-spot contention seems to have graver effects than contention on the CUED WiFi network. Hot-spot contention is worst at competition time ...

See the IDP Wifi page for details.

For Bluetooth, see the Bluetooth information on the moodle page.

General points

Change one thing at a time
Assume the worst. E.g. If you write a program that's going to turn right at the second junction, don't assume that it will detect the first junction.
Use classical standard solutions
Redundancy is good! If using a single sensor is unreliable, use 3? The fallback option of dead reckoning + walls for navigation is available (blind people feel their way along walls).
Keep the main loop short (the more times/second you read sensors, the better). Keep interrupt handler routines short (while in a handler, interrupts are ignored)
Navigation is crucial. The rest of the project fails if navigation falls. Once it works, make sure it keeps working.
PID control for linetracking/wall tracking is probably overkill - students tend to spend much time tuning PID parameters often with limited success.
Be alert for subteam decisions that affect other subteams
Identify critical resources - availability of tables; chassis (make 2?)

M2 2021 issues

Remember that the behaviour of the robot on the slope will change as the robot gets heavier.

Department of Engineering

IT Services